Decred Ticket Buying: Newbie Guide The following is a layman's guide to purchasing Decred tickets. I will start by explaining the ticket buying process, and then delve into some important details. Ticket Buying: Background Put simply, a Decred ticket gives the ticket holder the chance to cast a vote on a Decred block and receive a small DCR denominated reward for doing so with high probability. Voting on Decred blocks is rewarded with DCR to incentivize investors to actively participate in the network's governance. Investors can vote to signal support for well-liked community proposals that are critical to the Decred network's continued functioning and development. In addition, investors can vote to strip rogue Proof of Work miners of block rewards, making it costly for miners to oppose the will of investors. Each vote cast is rewarded with 6% of the DCR block reward. With each block added to the blockchain, DCR holders are given the opportunity to bid on 20 distinct voting tickets, which represent 20 opportunities to vote on a Decred block in the near future. These tickets are made available to bidders directly on the blockchain in an open auction format. Decred tickets are essentially lottery tickets in that each ticket will only cast a vote if it is lucky enough to be randomly drawn by the network. A ticket may never get drawn, however, and it will automatically expire after roughly five months if it is not drawn by then. In Decred parlance, tickets not drawn within this ~five month time period are known as expired or missed tickets. On average, each ticket you purchase will be drawn within 30 days of the purchase, but because there will likely always be more tickets vying for being drawn than there are tickets drawn, there is no guarantee that a ticket purchased in isolation will translate into a voting opportunity. Finally, note that purchasing a ticket does not cause you to exchange any DCR for a ticket. Instead, if your ticket bid succeeds, a quantity of DCR in the amount of the ticket price will be temporarily locked away in your wallet where it will be inaccessible to you until which time the ticket is either drawn or revoked. With each Decred block 20 tickets go up for sale to bidders, while 5 tickets are drawn from the ticket pool. Ticket Buying: Simplified Version Here's a simplified version of the Decred ticket lifecycle from start to finish: Step 1: Placing the Ticket Bid To place your bid on a ticket, your wallet software will broadcast a special type of transaction to the Decred network, essentially telling the network "Hey: I have a bid of 100 DCR for 1 ticket". This is step one, and it's easily handled from the Decred wallet software. Step 2: Including the Ticket Bid in a Block Step two is to wait for the Decred miners to include your transaction in a block, like any other blockchain transaction. Step 3: Winning the Auction Step three, once your transaction is included in a block, your bid enters into the pool of other ticket bids. If your bid beats the other bidders for any of the 20 tickets auctioned off with each new block, you get a ticket. Step 4: Awaiting Ticket Maturity Step four, now that you've beaten other bidders, you have a ticket. However, your ticket must idle for roughly 24 hours before it enters the pool of tickets that are capable of being drawn for voting on blocks. During this waiting period, your ticket is considered an immature ticket in Decred parlance. After 24 hours, your immature ticket becomes a mature ticket. Only mature tickets are up for being randomly selected to vote. Step 5: Casting Your Vote Step five, your mature ticket is randomly selected to vote on a block. At this point, if you're signed up for a Decred stakepool, your ticket will automatically cast a vote unattended, and you will be rewarded for your vote. Ticket Buying: Detailed Version As you'd expect from any auction format, bidding on tickets in the auction does not guarantee that you successfully win the ticket in the auction. There are two main components that go into successfully winning ticket auctions: Component A. The Going Ticket Price The ticket price matters greatly and is the primary component that determines whether you can buy a ticket and how many tickets you can buy. If you have 100 DCR and the ticket price is 25 DCR, you can buy 4 tickets. If you have 100 DCR and the ticket price is 50 DCR, you can buy 2 tickets. The higher the ticket price, the fewer tickets you can afford to bid on. Every 12 hours or thereabouts, the ticket price is dynamically adjusted so as to target 40,960 mature tickets in total are active on the network. Component B. Your ticketfee In Decred ticket auctions, the ticketfee essentially is your bid. Basically, your ticketfee commits you to pay a Decred PoW miner an amount of DCR should the miner award you the ticket as opposed to awarding it to competing bidders. Generally speaking, the more DCR you offer to PoW miners to award you the ticket (in the form of the ticketfee), the more likely you are to win the ticket. It's best to give careful consideration to the ticketfee. Low balling your ticketfee in a competitive auction will very likely cause PoW miners to ignore your bid. With your bid ignored, at the end of the auction, you'll be out the original Decred miners fee it cost you to get your bid recorded in the first place with nothing to show for it. OTOH, if you go with an excessively high ticketfee, you will pay Decred PoW miners far more than you should be paying. While high ticketfees are more likely to win ticket auctions, those high ticketfees will eat away at your profit margin; in extreme cases they can even cost you a not insignificant amount of DCR (see: cautionary section below). Miscellaneous Tips/Warnings Caution: It Is Possible To Lose Real Money From Decred Ticket Staking First, the technical way you can lose money is as follows: if you were to set your ticketfee to an extremely high value, such as 5.0, your wallet would commit to paying a Decred PoW miner 5.0 DCR per kB should that miner accept your bid. If your ticket was configured to use a stakepool, your bid transaction size could be 0.539 kB: that's 5.0 * 0.539 = 2.695 DCR you would lose to the PoW miner who awards you the ticket. This ticket, purchased at a cost of 2.695 DCR plus or minus some, would likely earn no more than 1.6 DCR, resulting in a significant loss. At the current date of 2017-04-24, for this type of negative outcome to be possible, you would need to run a dcrwallet instance with the unsafe allowhighfees setting activated. Of course, as the DCR subsidy steadily drops over time, so too could the safe transaction fee threshold. As well, you will be paying an unconditional miners fee for your ticket bids to make it onto the Decred blockchain in the first place. Though the miners fee is typically a small amount of money, you could overpay this fee if you weren't careful, and this fee would be irretrievably lost on every bid transaction, including in cases where the bid itself fails. The second kind of way to lose money is on an untimely market pullback. The DCR exchange rate could fall precipitously, imagine if during this time your DCR was unspendable, and that the price never fully recovered. You might have strongly preferred to hedge/exit your DCR position rather than stake. Last but not least, there is the risk hackers steal your DCR while your private keys are exposed during auctions. Tip: Minimize Your ticketfee You can raise your average ROI on winning tickets purchased at a given price level by lowering your average ticketfee paid at that price level. In competitive auctions, you can get a feel for what the proper ticketfee is by monitoring the auction for successful bids and taking note of the lowest winning ticketfee. Tip: Expire Your Bids One strategy you can use for successfully bidding on tickets is to take tiny stabs at auctions by bidding on a small number of tickets and making sure to expire your bid a short time out in the future. This allows you to quickly adapt your bids to changing auction conditions. While it's possible to expire your bids further out in the future such as at the end of an auction, this strategy is easily exploitable by other ticket buyers, who can take note of your ticketfee and set their ticketfee to your ticketfee + 0.0001, shutting you out of the auction. Tip/Caution: Keep a Journal of Your Ticket Purchases for Tax Season When purchasing Decred tickets, consider keeping a journal of all ticket purchases so that you may estimate your income from ticket buying. From there you can estimate your tax burden. Such a journal would become vital for US-based ticket buyers if the IRS were to classify Decred ticket winnings as gambling income, in which case the IRS compels you to keep detailed electronic logs of your income generating activities. Just in case, here is some recommended reading about professional gambler status. Here is what my journal looks like: Code: [timestamp] setticketfee ticketfee dcrctl purchaseticket fromaccount spendlimit minconf ticketaddress numtickets pooladdress poolfees expiry [2017-03-17T09:47] setticketfee 0.01 dcrctl purchaseticket default 55 1 DsbQUBmkG4uUKK6Av5dGa84Hzt6sQC3EA6R 7 DsdTcFyRnjkrJkLJzKgdQR8ckqU2G8SnXge 5 116389 [2017-03-17T09:52] setticketfee 0.015 dcrctl purchaseticket default 55 1 DsbQUBmkG4uUKK6Av5dGa84Hzt6sQC3EA6R 3 DsdTcFyRnjkrJkLJzKgdQR8ckqU2G8SnXge 5 116390 It's easy to keep this journal as you buy tickets, and with it, you can make use of Decred network averages to calculate your expected earnings. For example, you can take the average likelihood of a ticket being selected within 1, 2 or 6 months, and use that number to derive the expected number of tickets drawn over the respective time period. From the number of expected tickets drawn, you can calculate the expected payout of your ticket purchases by multiplying the number of expected tickets drawn by the expected block reward subsidy per ticket less the ticketfee and stakepool fee. For example: Code: my TicketlogActions $actions .= new; my TicketlogEntry:D @entry = Ticketlog.parsefile('data/log.txt', :$actions).made; # constants are from @SatoshiLite spreadsheet constant $ticket-payout = 1.60; constant $kilobytes-per-transaction = 0.539; say [+] @entry.grep(*.date-time.year == 2016).grep(*.date-time.month < 12).map({ my Rat:D $transaction-fee = .ticket-fee * $kilobytes-per-transaction; my Rat:D $ticket-payout-net = ($ticket-payout * (1 - (.stakepool-fee / 100))) - $transaction-fee; my Rat:D $tickets-payout-net = $ticket-payout-net * .ticket-quantity; }); FAQ I intend to add an FAQ over time for frequently asked questions from investors and ticket buyers.
How exactly do you lose money if you're bids are being beaten out? Is it because the fee is lost or...?
Yep, even if you don't successfully purchase a ticket, you're still out the transaction fee. A lot of the tickets bought near the bottom of a price cycle have fees as high as 1.0DCR, which nearly guarantees that the purchase will go through, but also cuts the profit from a successful ticket buy to 0.5dcr. And that's assuming the ticket doesn't somehow fail to vote.
Interesting, is there any documentation on what prices / fees have lead to successful purchases? Feel like the newbie will just be flying a bit blind. I think im understanding the supply and demand causality a bit better. Is this right?: - if ticket price is low for a set of blocks - demand is higher because the risk of ticket expiration comes at a lower cost. - when demand is high, the accompanying fee for a successful ticket purchase will also be higher. - if the ticket price is high, there is less competition and they can be bought with lower fees therefore, but the risk of loss on an expired ticket is higher.
You get back the original ticket purchase price if it expires. You simply don't get the additional reward in that case. The only risk of loss you incur when staking is the original transaction fee you pay to the PoW miners to get them to include the ticket purchase in a block. EDIT: Please note when I'm talking about a loss there I mean it in the literal sense of your balance going down. There are, of course, other opportunity costs associated with having coins locked since you can't sell them or otherwise transact with them, but that is conceptually similar to putting your money into more traditional vehicles such as CDs.
Ahh thanks Dave, so the only difference between buying a ticket at 100 DCR + fee and 50 DCR + fee is that in the case of 100, you're tying up more funds for a similar block reward. The rationale for the fluctuating price is still a point of uncertainty for me. What would be the difference if the ticket price always stayed the same? Wouldn't it just be a fee vs block reward competition at that point?
Correct. The primary goal of the ticket price is to maintain a target ticket pool size. That is the most important thing because all of the yields, expiration percentage, average win time, etc are all dependent on the pool size. That is to say in order for you to be able to make intelligent decisions about your staking activity, those values have to be quantifiable and predictable. Without maintaining a mostly consistent pool size close to the target, that simply would not be the case. See above and consider what would happen with a fixed ticket price size and more coins being available with every mined block.
Cool, i get it. Just to restate, the fluctuation alogorithm is set to make it such that the relative advantage / disadvantage of buying a ticket at a certain price maintains the target ticket pool size. Thereby stabilizing the yield, expiration %, avg win time. So that we can know what to expect in PoS. yay. Thanks. You guys be smart peoples. Appreciated. Is there any "real" world analogy for this kind of participation?
Wow. So people who aim to buy tickets at 35-45 DCR set their transaction fee as high as 1.0 DCR? Is it the one you set with 'setticketfee' (not 'settxfee')? Does it mean if I don't set so high fee I will fail to buy a ticket, or just I'll have to wait longer and hope for less desperade ticket buyers?
'settickefee' is the correct command. Note that the fee is per/kb and a ticket transaction is about half (for pool) or a third (solo) of that so a ticket with a fee of 1.0 will in reality only cost 0.3 or 0.5DCR. Still expensive, but not so bad. This is why the first vote after v1.0 will be to change the price algorithm to hopefully stop these swings.
Yes, sort of: Code: #!/bin/bash LENGTH=${1:-20} dcrctl --wallet getrawmempool true tickets \ | jq '.[]|.fee/.size*1000' \ | sort -n \ | tail -n $LENGTH Save the above snippet from @Kandiru as `mempool.sh`, then `chmod +x mempool.sh`, then run `./mempool.sh 20` to see the top 20 bids in the mempool. There is currently no existing GUI for real time updates of the mempool plus color-coded tracking of your own bids.
www.posmaster.info. Check the bar chart tab at the bottom of the first page. It shows all ticket prices in the mem pool. It's updated every minute, but you'll need to refresh to get the changes.
ticket-newbie here, so pls bear with me... one thing remains unclear to me (manual ticket-buying): say my wallet has 3 accounts 'default' with addr 'Ds1...', 'funds' with addr 'Ds2...' and 'voting' with addr 'Ds3...'. i submit the pubkeyaddr of address 'Ds3...' in my PoS-Pool-Account to generate the redeem-script that i then need to import into my wallet. afterwards i want to run dcrctl --wallet purchaseticket <accountname> <spendlimit> [...] to bid/buy a ticket. now my questions are: 1. which accountname do i have to specify with this? does this need to be 'voting' in my example or can this be any of my wallets accounts (funds or default)? 2. am i correctly assuming that whatever account i need to specify, this accounts balance needs to match/exceed the spendlimit? Does the accounts address holding the balance need to be the one that one submits its pubkeyaddr to the pool during setup? Or in other words, if the balance of 'voting' is 0 in my wallet and i used an address of the voting account to generate the redeem-script but i have sufficient funds on an address in 'funds', can i buy tickets? thanks for helping me to learn, cheers, anti
It depends. If your other thread is any indication, you entered the pooladdress incorrectly. Without the proper pooladdress, your ticket can't pay your stakepool a sufficient fee, and your stakepool knows it. Consequently, when your ticket gets called for a vote, your stakepool will not cooperate by voting on your behalf. If you do nothing else, you'll get back the DCR principal locked for the ticket purchase just like normal after your ticket is called to vote, but your ticket won't cast a vote and you won't receive part of the block subsidy. The silver lining here is you don't need the stakepool's cooperation in order to cast a vote on your own ticket. Depending on the amount of DCR you stand to gain from properly voting, you may find it worthwhile to setup and run your own voting-only Decred wallet on a remote server which listens for your ticket to get called and then casts a vote on your behalf without the stakepool's help. However, this won't be a realistic option for you unless the ticketaddress to which voting rights are assigned belongs to a voting-only account in your Decred wallet. If you didn't take the time to create a voting-only account for use with the stakepool in the first place, you're probably out of luck. In my experience, it's expected for roughly 1% of all tickets to miss their vote due to the ticket expiring and other factors. In those cases, you lose the txfee and ticketfee that went into acquiring the ticket, which is all that will happen to your ticket here by default. Unless you're very technically inclined and the DCR subsidy at risk is very large, you may just want to write this whole thing off as an inexpensive lesson.
Specify either "default" or "funds". This is where the funds for purchasing tickets come from. You did the right thing by submitting a pubkeyaddr from a voting-only account. The funds for purchasing tickets can and should come from other accounts. This preserves the option to set up an unlocked voting-only wallet on a remote server as a backup in case your stakepool goes down.
Thanks for your clarification; seems somewhat easy once one knows it but until then remains mysterious, especially after reading several posts where people have used weird addresses while trying to get their first PoS-mining-steps right... While I generally get the idea I wonder how having a backup server with the voting-only-wallet works when the pools address has been specified as having the voting right for the ticket upon ticket-purchase? Is there a mechanism that checks the original (=my) address in case the specified voting address (=the pools) of a ticket is unavailable?
When you use a stakepool to purchase a ticket, your wallet software will specify both a ticketaddress and a pooladdress for that ticket. The ticketaddress is a 1-of-2 multisig address to which your ticket's voting rights are assigned. The ticketaddress holds no spendable DCR funds; its only job is to cast a vote. Your stakepool gets one private key to this 1-of-2 ticketaddress while your voting-only wallet gets the other private key. Consequently, either you or your stakepool can cast a vote when your ticket gets called. Your voting-only account will try to cast a vote when your ticket gets called, which happens regardless of what your stakepool does. IIUC, your voting-only account races against your stakepool to cast the vote.