Separate names with a comma.
Discussion in 'Questions' started by Dyrk, Jan 13, 2016.
I have stake mining enabled. How do I see the "balance" that is being used for tickets?
Also, is there any "possibility" that stake coins could be lost?
If my internet goes down when I won some DCR, will my staked coins be re-used for the next block, even if I didn't get the reward?
dcrctl --wallet getbalance * 0 all
will show you the total of your funds including those tied up in a SSTx (ticket purchase).
List all of your tickets with gettickets 1 and use gettransaction <tx hash> to see details of each ticket purchase. Checking votes and subsidy (directly) with RPC calls is not yet implemented.
dcrctl --wallet getbalance * 0 all
Is it possible to stop staking to transfer the decreds back to wallet instantly?
No, once you bought the ticket to stake, the only way it will become unlocked is if you stake successfully or it hits the maximum, which is about 142 days, I believe.
Another word.. you'll miss the pump if your coins are locked in staking? j/king
Sorry for the length of this, but I have a few more questions regarding the interesting economics of PoS:
1. Apparently, when making a 'buy ticket' transaction, in addition to locking funds, one also pays a fixed transaction fee of (at least) 0.05 DCR. Do I understand correctly that if I am unlucky and my ticket expires without voting, I will, in the end, have lost those 0.05 DCR? (However, the probability for this is <1%?)
2. If my wallet is unreachable or locked for a while when my tickets may be selected by miners, does that mean I'm proportionally increasing the risk to end up with expired tickets, thus increasing my chances to lose 0.05 DCR per ticket?
3. Right now voting on mainnet is on 'hold' up until block 4096, with people buying tickets. Does this mean there will be a significantly higher risk for these tickets to expire than the 1% probability quoted during normal operation?
4. The 'Solo stake mining' wiki page says the wallet must be online, unlocked and dcrd connected to the Decred network for voting to take place. Are these all requirements? If I run my wallet on a machine behind a NAT/firewall, do I need to open any forwarding ports for the voting request to reach me? Can I somehow test if my machine is reachable for voting? (I.e., run the actions of a miner that would want to get my vote.)
5. Early on in this thread, davecgh suggests the reward for voting should be at least 1.8 DCR. (30% of 30 DCR = 9 DCR shared among max 5 voters.) However, later in the thread there is an example from the testnet where the reward turned out to only be 1.48514851 DCR. Why was that reward less than 1.8 DCR?
Finally, a comment: if I understand the dynamics of the PoS setup, in normal operation one stands to earn an average of ca ~ (1.5-0.05)/28 ~= 0.05 DCR/ticket/day. If I'm thinking correctly about this, the market equilibrium ticket price X will then end up where the interest of a loan for X would be 0.05 DCR/day. At an interest level of ~ 5%, that corresponds to ticket prices at ~ 372 DCR/ticket. That seems high. Participation in solo voting or a voting pool requires at least one ticket, so if this calculation is correct, a lot of people will end up with no voting influence because they cannot afford even a single ticket...
2) If your wallet is offline or locked when your tickets are selected, you lose out on the rewards and your ticket is removed from the pool immediately. There are no "redos".
3) No, the expiration time doesn't start until a ticket is actually mined into a block. The tickets are just sitting in the memory pool until they can be included in blocks starting with block 4096.
4) You don't need to be reachable. Voting is deterministic on a per-block basis. That is to say your wallet will know if your ticket is selected based on the current block and then a "vote transaction" (ssgen transaction) is broadcast to the network, just like other transactions.
5) The first example was a hypothetical based on a fake subsidy. It's 6% of whatever the subsidy of the block in which the vote is included (not the original ticket purchase, but the vote itself). The subsidy in Decred changes much more frequently and less abruptly in Decred (every 6144 blocks).
In regards to your final comment, the math superficially looks correct (obviously actual win times greatly vary, but that is the average, so it should work out) , however I don't believe your conclusion about no voting influence is accurate since stake pools that offer reward splitting will no doubt form in response.
Number 2 is sad and should be changed, unless I'm missing something fundamental.
My stupid internet goes out once in a while, so that ticket I spent is wasted and DCR returned to me minus the transaction fee? Then another ticket is automatically purchased because I have enabled staking.
Not trying to game the system, but I keep my network and wallet up and staking, but couldn't the logic be changed to:
Wallet offline/locked at that moment the reward is attempted, then the ticket goes back to the que while someone else wins, ticket stays until the expiration max time limit?
That really can't reasonably work. How does the rest of the network know your wallet is offline and/or locked and so another vote should take its place? Keep in mind the consensus rules have to be able to determine a vote's validity in a decentralized and completely independent manner (and forever more since it becomes part of the block chain's history). If it weren't that way, all a miner would have to do is put their own votes in there instead and the entire system would be defeated since majority PoS voters could no longer veto blocks. Why would miners ever include a PoS vote that goes against one of their own blocks (thereby costing them money) when they could instead simply ignore your vote and replace it with their own or another more favorable one (hey, he was offline, not my fault!!!!)?
EDIT: This is why I recommend participating in stake pools which have redundant and geo-distributed systems.
I think this makes sense now, thank you. I'll just have to put my PoS wallet on a server rather on my desktop.
372dcr stake difficulty is an interesting number. There would have to be roughly 3.04Mdcr in existence and EVERY dcr in existence staked for that to happen? At block 4096 there should only be 1.72Mdcr in existence. With every dcr staked, 210 would be stake difficulty. While this is possible as there isnt really a large outlet for dcr purchases requiring a liquid pool of dcr yet. I dont think it is likely to happen for a while. As long as my math is correct... hehe
@davecgh, many thanks for your dedication to answering questions in this thread.
But, is it possible to contribute to a stake pool if one cannot even afford a single ticket? I thought the mechanism was to buy a ticket with the voting rights assigned to an address controlled by the pool?
Oh! Thanks! I think I start to understand the protocol now. Is something like this fairly accurate?:
Step 1. A miner adds a block to the blockchain. This deterministically settles which 5 mature tickets get to vote on it using some form of seeded PRNG (?)
Step 2. My online wallet see that I get to vote, and issues an ssgen transaction with my vote on that block.
Step 3. Miners pick up my vote + votes from the other 4 holders of the winning tickets from the network, and enters them into the block they are working on. They need at least 3 votes, so they can actually ignore 2 votes of their choice if they want, but are punished for it (their reward is scaled down.)
Step 4. As the next block enters the blockchain, it includes my vote and reward.
(Sorry if this is wrong / confused / and/or available in documentation somewhere, I've tried to read what I could find, but never saw a breakdown like this.)
This raises three further questions (sorry):
1. What happens if none (or < 3) of the selected voters manage to issue their ssgen?
2. Do I pay a transaction fee also for the ssgen transaction? (i.e., does the voting wallet have to have some unlocked funds?)
3. Do I understand correctly that it is up to miners to decide how long to wait for the ssgens to show up? I.e., miners are likely to start working as soon as they have 3, and add others when/if they come in?
With the initial stake pool that is true, however the underlying tech does allow multiple inputs as well as multiple recipient address commitments. So, it is entirely possibly for pools to be developed which could handle the matching for you thereby allowing smaller stakeholders to participate (and they'd probably charge a small fee for their services).
Yes, that is almost exactly correct. The only caveat here, which I will explain in more detail below when answering your other questions, is miners are not working on a new block until 3+ votes show up.
1. Votes are always determined by the current tip. Miners do not start mining for a new block until at least 3+ of the selected voters issue their ssgen transactions. So, if a found block does not manage to get the selected votes, the block is simply orphaned by the next block another miner finds.
For a more concrete example, assume the current chain tip is at block 5000. The voters determined by block 5000 have already submitted their votes, so miners are chugging away looking for block 5001. Now, a miner finds a solution for block 5001 and submits it to the network. All of the daemons (and hence wallets) will see that 5001 just showed up. However, the miners do not immediately start mining off of 5001. Instead they continue mining off of 5000 until 3+ votes for block 5001 show up. At that point they all switch and start mining off of 5001. If those 3+ votes never show up, another candidate block 5001 will be found by the other miners still working on block 5000 who will submit their (different) solution for block 5001 to the network. Since each of these new candidate blocks for 5001 have a different hash, different tickets are selected.
2. No, ssgen transactions do not impose a fee (unlike the original ticket purchase transactions which are competing for limited space in each block). They are effectively like PoW coinbase transactions in this regard.
3. This is explained by #1.