Understanding Of Proof-of-stake

Ultimately I would expect there to be a way to perform buying a ticket through a GUI, however at launch I'm fairly certain it will only be possible via the command line and dcrwallet daemon at launch. As far as I know the copay-based GUI wallet won't be able to handle staking at launch, but one of the devs working on that would have to confirm.

You can use the CLI and dcrctl utility you can get a list of outstanding tickets via the gettickets RPC and expired tickets via the missedtickets RPC. However, there is no GUI way to do these things. Obviously that would be ideal and something the community can help with.

Your wallet (or once stake pools are out there, the pool) needs to be online when a ticket is selected in order to receive a winning ticket notification. The wallet (or pool) will then vote according to how it's configured to vote.

This has been answered in detail already. Please read the entire thread.

This has already been answered in the thread as well. Purchasing a ticket only locks the coins, it doesn't consume them. When you vote, you unlock the original coins and receive a reward. In other words if you purchase a ticket for X DCR and the reward is Y DCR, you end up with X+Y DCR.

A vetoed block still exists, it's just the normal transaction tree and PoW/dev subsidy in it is invalidated. So, it does not cause a chain reorganization. Miners still follow the chain with the most PoW as normal. Miners can tell their block was vetoed by examining the vote transactions broadcast to the network for the previous block once that block has been broadcast for something more real-time, or by looking at the voting bits in the header of the next block.

 

As far as I know, there won't be any code in place to actually set policies like that at launch. I mention them because the system is designed to allow such things to happen. As more development takes place, I would imagine stake pools will form with their own set of policies and users can choose which pool(s) to join and how to allocate their staking according to their preferences.

 

Yes, every lottery is independent. A ticket's probability of being selected each block is always based on the number of tickets in the ticket pool at the time of the lottery. There is no bias based on age. That is why it's possible your ticket may never win, even though statistically the average win time is 28 days. It's also why the expiration time is 40960 blocks (~4.7 months) so that there is around a 99% chance the ticket will be selected before expiring.

There is no limit to the number of tickets for sale. Each participant that wants to purchase a ticket submits an sstx (stake submission transaction) to the network. As you noted, only 20 of that type of transaction can be mined into the stake transaction tree for each block which effectively limits the number of tickets that can be purchased per block to 20. An sstx, like all transactions, can have a fee associated with it. So if there is high demand for ticket purchase, you might want to pay a higher transaction fee so the miners prefer yours over others.

As previously mentioned, the ticket price is dynamically adjusted based on demand, so if there is persistent high demand for tickets, the price will rise which will in turn cause fewer tickets to be purchased which in turn causes the price to fall which results in more demand and the cycle continues. The result is a ticket market where the price to reward ratio reaches an equilibrium.

 

There will be some details about building a stake pool released soon. I would expect that will be a good starting point for those interested.

 

Yes. I did explain it earlier, but I'll clarify here a bit since more details about the block header have been released. There is a minimum amount of decred it takes to purchase a ticket (put in reserve) for a block.

Looking at the block header specification, you can see the SBits field (stake difficultly target, aka ticket price) that determines this. That value is adjusted every 144 blocks (12 hours on average) based on the number of currently active stake tickets (the PoolSize field) and number of new tickets purchased per block (sum of the FreshStake fields) across the retarget interval.

 

You can manually set the --votebits parameter on dcrwallet. So to vote no, you'd set it to 0. However, that will vote no to all blocks. It's only really just the infrastructure that is in place currently. Obviously there will need to be better ability to tweak policy, preferably through a GUI and that will certainly come with time. The most important thing at the current time is having the infrastructure in place and working properly.

As far as the stake reward, there is not an easy way to do it right now. There is an open issue (https://github.com/decred/dcrwallet/issues/6) for a new RPC to do that though.

In the mean time, you basically have to issue a getrawtransaction <votehash> 1 and look at the vout values to find it. So for your particular case here:

Code:

$ dcrctl getrawtransaction 23b04fe1cb1c8b335781ca979d37e43043b08e1af4c97151fa041d3fec45807c 1 | grep value
  "value": 0,
  "value": 0,
  "value": 7.93480071,   <---- This is what you got back

Now if we look at your original stake ticket purchase:

Code:

$  dcrctl --wallet getrawtransaction 1e8edbbebc01c2a8a3264de7826dd4f772094c5bcdedcad941fb452778171134 1 | grep value
  "value": 6.4496522,   <---- The original ticket purchase price
  "value": 0,
  "value": 29.0537158,

We can see that your balance went up by 7.93480071 - 6.4496522 = 1.48514851 DCR.

 

@Blizzy Yes, the wallet has to be unlocked in order to sign transactions.