Is Pos Working?

Discussion in 'Tickets' started by Dyrk, Feb 9, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. jack.liver

    jack.liver New Member

    Feb 1, 2016
    20
    4
    Male
    after the vote was casted how many confirmations are needed to spend the amount again in tickets ?
     
  2. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    405
    218
    Male
    That is the big question currently. I have a vote from 4124 that has yet to show correctly. My ALL balance will show the vote stake returned on the next block. My LOCK total and SPENDABLE are not updating. I should have bought more stakes and seen more sstx going through. I have not yet after 4 votes. Not even the 2dcr stake price that shows returned is being used yet.
     
  3. blackdragon

    blackdragon New Member

    Dec 28, 2015
    19
    9
    Male
    Roughly how long has it been taking for people's tickets to be selected? I have over 100 mature tickets as listed by --wallet gettickets false, but so far none have been selected.
     
  4. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    405
    218
    Male
    Its all luck adjusted by your # of tickets. I have about 215 stake tix and have voted only 4 times so far.
     
    blackdragon likes this.
  5. blackdragon

    blackdragon New Member

    Dec 28, 2015
    19
    9
    Male
    I understand that much - I just would have expected at least one vote by now.
     
  6. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    405
    218
    Male
    It appears you are just unlucky then to my understanding... hehe
     
  7. ClokworkGremlin

    ClokworkGremlin Sr. Member

    Jan 10, 2016
    535
    381
    Male
    Whatever I want.
    #47 ClokworkGremlin, Feb 22, 2016
    Last edited: Feb 22, 2016
    Likewise. Based on my locked balance, I've had 3 votes succeed and 1 get rejected(most recent vote was 1 hour ago), but the rewards and returns from those only appear if I use "getbalance all."

    [edit]Apparently the time for the reward to return is 256 blocks(about 21 hours). Since my first vote was on block 4208 and the chain's currently at 4294, that answers that.

    I went ahead and turned off ticket purchasing for the moment, so I should be able to track the rewards when they start showing up.
     
  8. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    405
    218
    Male
    Wow based on that 256 block conf it is going to take quite the stake to get more than a few dcr rewards here and there.
    That said I have my first vote from 4124 that should clear on 4380. Still a ways to go.
     
  9. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    Has anyone setup redundant wallets to ensure PoS votes will be cast in the event of a failure? I created multiple wallets during testnet and they became out of sync because each one was generating transactions. Right now I am thinking about bringing a redundant wallet online but setting the balance to maintain astronomically high so it does not purchase any tickets.
     
  10. Fsig

    Fsig Member
    Developer

    Dec 28, 2015
    71
    77
    Male
    Australia
    Pos Miner Portal you can setup my interface to make life easier.
     
  11. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    I've got two wallets doing the voting, but only one is buying tickets. So far they both voted on the same transactions. I've only had 1 vote since I set up the second wallet though. I've gone for one on AWS free trial, and one on a netbook. I'll check to see if the the new tickets appear on the other device later, they hadn't when I checked earlier. I might need to delete and re-create the wallet on the non-buying one?
     
    David likes this.
  12. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    @Kandiru I got my second (backup) wallet up on my Raspberry Pi 2 board.. this one will only be doing voting and should never generate any transactions. I have been called to vote only once since I got the Pi2 up.. both wallet instances showed a successful vote submission. I manually purchased a ticket from my primary wallet instance and it took about 30 mins (~4-5 blocks) for it to show up on my Pi2 wallet.

    I'm not sure how the ticket list is sorted, but it's definitely not sorted chronologically. New tickets don't appear at the top or bottom of the gettickets output. When you're looking for new tickets in your ticket list, be sure to include immature tickets, and use a search output modifier like this:
    (I'd only put the first few characters of your ticket hash below, to reduce the possibility of errors in the command)

    Windows:
    Code:
    dcrctl --wallet gettickets true | findstr yourtickethash
    Linux
    Code:
    ./dcrctl --wallet gettickets true | grep yourtickethash
    Also, the balances between my two wallet instances were off for a bit but seemed the backup wallet (the one that did not initiate the ticket purchase transaction) seemed to sync up several blocks later.
     
    sambiohazard likes this.
  13. rohit pawar

    rohit pawar Member
    Advocate (Reddit)

    Dec 26, 2015
    166
    87
    Male
    India
    #53 rohit pawar, Feb 22, 2016
    Last edited: Feb 22, 2016
    Using 2 wallets with same seed is not recommended . This may lead to problem like missing fund , tickets hashes missing . ill suggest you to create a new wallet and use it as a hot wallet which will only used for vote .
     
  14. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    There is one exception to this, and that's for voting hot wallets that have no funds of their own. If the wallet is only doing voting and not buying tickets or creating any other transactions, it's safe. You can use this fact to set up multiple hot wallets in different locations to ensure your votes always get onto the network in case one wallet fails somewhere.
     
    jy-p, David and drunkenmugsy like this.
  15. David

    David Sr. Member

    Jan 22, 2016
    364
    207
    Male
    USA
    @rohit pawar, @ceejep is right. During testnet I experienced what you are saying ONLY because I had multiple wallets creating transactions. As long as your secondary or tertiary wallets are not creating transactions (buying tickets, receiving funds, sending funds, etc), you should be fine to use multiple wallets to serve as a redundancy for PoS voting.
     
  16. Halestorm

    Halestorm Jr. Member

    Jan 22, 2016
    83
    32
    Male
    Data Center
    Texas, USA
    I set up a new wallet with a new seed on a VPS to be my voting wallet. My main wallet at home is started with --ticketaddress=[address of second wallet]. I buy tickets from my main wallet and the VPS wallet is watching for and votes whenever my tickets are called. The funds are then delivered to my main wallet once they mature, I buy more tickets and the cycle continues. If my computer at home has to reboot/goes down/gets disconnected/dog pisses on it/whatever the only issue I'll have is not being able to buy new tickets until I get it back up again.
     
    David likes this.
  17. Dyrk

    Dyrk Sr. Member
    Developer

    Jan 7, 2016
    518
    376
    Male
    Wonderland
    Do we see "Vote" transactions that voted exactly for this specific block in the block explorer (or for the previous one)?
    For example this block:
    https://mainnet.decred.org/block/00000000000022cfe62b3bcf1653a64dd6cdabd1a0412fb38db773343ba0dfac
    Block reward is only 13.10224717 DCR and Voters = 3.
    So I assume that those 3 "Vote" transactions voted exactly for this block (not previous, where reward was 17.4696629 DCR, so 4 / 5 votes), and PoW-miner lost 40% of his reward.

    So my questions are:

    1. Why this happened, there was only 3 / 5 votes, when the poolsize is > 33.000 tickets. Did miner was so unlucky that 2 voters wallets were offline and missed their votes? (if yes, it seems to be super unfair for PoW-guy, network should try to find other voters who are online).

    2. How can we track which transactions votes "yes" and which "no"?
    I tried to investigate some random vote transactions, but answer is not so obvious to me, because there are a lot ambiguous fields:
    https://mainnet.decred.org/api/tx/90fd866e37bed5a8ea8b0790db44f67981f0cc011811296abc3cb9a7a7f4c05d

    So basically I want to see which tickets voted for the block, what was the vote for each ticket (yes or no), and why there were less than 5 votes for the specific block if pool is very big.

    @ceejep can you please help me to find some answers?
     
    jy-p and drunkenmugsy like this.
  18. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    1) See https://forum.decred.org/threads/po...our-wallet-running-24x7.744/page-4#post-11254

    It's unfair to both PoW and PoS miners, but there must be consequences for not voting and not including votes or the system will be meaningless. The two voters lose their subsidy with the miner. It seems like a number of pools have poor network connectivity or are incorrectly polling getwork. PoW miners are highly incentivized to include their work and maintain high network connectivity. To view votes coming into the network, use '-d MINR=debug' on the daemon. You will see it is rare to have a block with only 3/5 votes (approximately 1% of the time). Most blocks have 5 votes cast.

    Have a look at some output from my daemon.
    Code:
    16:24:49 2016-02-23 [INF] BMGR: Processed 1 block in the last 1m18.01s (4 transactions, height 4597, 2016-02-23 16:24:43 -0500 EST)
    16:24:50 2016-02-23 [DBG] MINR: Accepted vote 9808a82543d516937939b65b4a741810c0b93ca5bececa226c813bd812713c35 for block hash 0000000000003f2e95f59063cb2194f429bf0b18794805865248b1b09623857c (height 4597), voting true on the transaction tree
    16:24:50 2016-02-23 [DBG] MINR: Accepted vote 463d90acfba02c9fde37b521cfe100628bf8697335c2ac899ccfe15142643585 for block hash 0000000000003f2e95f59063cb2194f429bf0b18794805865248b1b09623857c (height 4597), voting true on the transaction tree
    16:24:50 2016-02-23 [DBG] MINR: Accepted vote 4aaa1c260ae8ac6ec564b7a7d42eb182a82edf0b98cc6647d53242a90493abf9 for block hash 0000000000003f2e95f59063cb2194f429bf0b18794805865248b1b09623857c (height 4597), voting true on the transaction tree
    16:24:51 2016-02-23 [DBG] MINR: Accepted vote ae65bbe0f348457f17b111abae63746e575d68abe7dc296229f55260798a7adb for block hash 0000000000003f2e95f59063cb2194f429bf0b18794805865248b1b09623857c (height 4597), voting true on the transaction tree
    16:24:53 2016-02-23 [DBG] MINR: Accepted vote b2870b1c7db19f6f1cda65daa8e87254fd43e123b26f281715c19e556c2f03d2 for block hash 0000000000003f2e95f59063cb2194f429bf0b18794805865248b1b09623857c (height 4597), voting true on the transaction tree
    16:24:58 2016-02-23 [DBG] MINR: Accepted vote fe424307a654d2607466ff88e4c90d1ffa8c44dc6b1813d35b9bb0e14b9d4cf9 for block hash 00000000000039d1b8507de53d3a4697414e4893d2b2b923c9d3a024a0dfd7d7 (height 4598), voting true on the transaction tree
    16:24:59 2016-02-23 [DBG] MINR: Accepted vote 8aeb5849cae2ae4d29e344fa5ec954eb9b169add76f1ae0ace0b0c53db7c598f for block hash 00000000000039d1b8507de53d3a4697414e4893d2b2b923c9d3a024a0dfd7d7 (height 4598), voting true on the transaction tree
    16:24:59 2016-02-23 [DBG] MINR: Accepted vote 7c56d133b24eae5048c43d8280dc0caf35d2bbf1687b5e0321d82e72a4727d60 for block hash 00000000000039d1b8507de53d3a4697414e4893d2b2b923c9d3a024a0dfd7d7 (height 4598), voting true on the transaction tree
    16:24:59 2016-02-23 [DBG] MINR: Accepted vote 6fb121720cf87b7a8fc5247264859248729d2297cf2fc0fc59a68261dbc4c2bf for block hash 00000000000039d1b8507de53d3a4697414e4893d2b2b923c9d3a024a0dfd7d7 (height 4598), voting true on the transaction tree
    16:25:03 2016-02-23 [DBG] MINR: Accepted vote 6260eb1b311ce790526de6d1581e7f356c61650741f7a7122e88fafc68028e60 for block hash 00000000000039d1b8507de53d3a4697414e4893d2b2b923c9d3a024a0dfd7d7 (height 4598), voting true on the transaction tree
    16:26:27 2016-02-23 [INF] BMGR: Processed 2 blocks in the last 1m37.59s (2 transactions, height 4599, 2016-02-23 16:26:24 -0500 EST)
    16:26:27 2016-02-23 [DBG] MINR: Accepted vote 72150de25a603fa2b345bf6416986d7becf895108b8a5656996c638556a6385c for block hash 0000000000002b1040f45391c913fba6c418a98f24c36606e3d286eceba66853 (height 4599), voting true on the transaction tree
    16:26:28 2016-02-23 [DBG] MINR: Accepted vote 343363635e4e1171467137c7d223306af1a34284aa6419f60ba867561069704e for block hash 0000000000002b1040f45391c913fba6c418a98f24c36606e3d286eceba66853 (height 4599), voting true on the transaction tree
    16:26:28 2016-02-23 [DBG] MINR: Accepted vote adf3e375ea448e0d69f85d55ac8f58f83a34e356b241ae65263c53560c615de2 for block hash 0000000000002b1040f45391c913fba6c418a98f24c36606e3d286eceba66853 (height 4599), voting true on the transaction tree
    16:26:29 2016-02-23 [DBG] MINR: Accepted vote 111fad74d39bf2e14423d6f06a58217c389f8768c76c91cf1c8c3aed72fff5c4 for block hash 0000000000002b1040f45391c913fba6c418a98f24c36606e3d286eceba66853 (height 4599), voting true on the transaction tree
    16:26:29 2016-02-23 [DBG] MINR: Accepted vote 5b44fe1be24778f52d358bfdee85b1264a40455ba9f692424fac3135600dfbd5 for block hash 0000000000002b1040f45391c913fba6c418a98f24c36606e3d286eceba66853 (height 4599), voting true on the transaction tree
    16:29:41 2016-02-23 [INF] BMGR: Processed 1 block in the last 3m14.39s (1 transaction, height 4600, 2016-02-23 16:28:41 -0500 EST)
    16:29:41 2016-02-23 [DBG] MINR: Accepted vote 6196f1dc41b78120a8dbc36358c6382bff1ec500d7539587ae7d4596841d8bd9 for block hash 0000000000000148a05ee6fb8ffc0e271544f1fd5a628d5a19ee69ccdd500551 (height 4600), voting true on the transaction tree
    16:29:41 2016-02-23 [DBG] MINR: Accepted vote e6d6af49350d9bfd7d3185b021e3739752e1cf319ae757f25cfb0e681c48fa87 for block hash 0000000000000148a05ee6fb8ffc0e271544f1fd5a628d5a19ee69ccdd500551 (height 4600), voting true on the transaction tree
    16:29:41 2016-02-23 [DBG] MINR: Accepted vote 47fc2abc27b0a2e2483d69f35cb9a2450d9fc7cda6aff67ebdac4d859c1fd78e for block hash 0000000000000148a05ee6fb8ffc0e271544f1fd5a628d5a19ee69ccdd500551 (height 4600), voting true on the transaction tree
    16:29:42 2016-02-23 [DBG] MINR: Accepted vote 29ccdc6d79da729c847ff1a22ddc9da4f1603726acc4417a46ca0943b8064ece for block hash 0000000000000148a05ee6fb8ffc0e271544f1fd5a628d5a19ee69ccdd500551 (height 4600), voting true on the transaction tree
    16:29:42 2016-02-23 [DBG] MINR: Accepted vote 5f6db7bdc4aab59974750cd17953a711885dec5f2706eff197efe82eb22e12a8 for block hash 0000000000000148a05ee6fb8ffc0e271544f1fd5a628d5a19ee69ccdd500551 (height 4600), voting true on the transaction tree
    16:34:07 2016-02-23 [INF] BMGR: Processed 1 block in the last 4m25.49s (8 transactions, height 4601, 2016-02-23 16:34:07 -0500 EST)
    16:34:07 2016-02-23 [DBG] MINR: Accepted vote 6e271895fca16d0dabe1221e16328583b39d2191bd64fb6631a8baacc2811039 for block hash 00000000000000efe38a92672b5fb98a9f2cf959f14be0d058e09c720bc3a495 (height 4601), voting true on the transaction tree
    16:34:07 2016-02-23 [DBG] MINR: Accepted vote 60cec9a34ec1226895fa68169197e637acf7c3c904fca24172e56863271eb50d for block hash 00000000000000efe38a92672b5fb98a9f2cf959f14be0d058e09c720bc3a495 (height 4601), voting true on the transaction tree
    16:34:07 2016-02-23 [DBG] MINR: Accepted vote a7301a8f4d4002d2e5411c2f6ba6d6e22d785798458dec163ad1ee295be7d9f0 for block hash 00000000000000efe38a92672b5fb98a9f2cf959f14be0d058e09c720bc3a495 (height 4601), voting true on the transaction tree
    16:34:07 2016-02-23 [DBG] MINR: Accepted vote 6f1c9b378df0ccb9761e7668ff61bdfff111736d1978dfd40361dcd8d3f2bc3a for block hash 00000000000000efe38a92672b5fb98a9f2cf959f14be0d058e09c720bc3a495 (height 4601), voting true on the transaction tree
    16:34:11 2016-02-23 [DBG] MINR: Accepted vote 4bea253e5edf393ed33822be90b3b9c058aaa4e7005aa0173c998baace8abede for block hash 00000000000000efe38a92672b5fb98a9f2cf959f14be0d058e09c720bc3a495 (height 4601), voting true on the transaction tree
    The voters themselves are voting aggressively.

    For an example of the variability, see the block reward at coinmine.pl:
    https://www2.coinmine.pl/dcr/index.php?page=statistics&action=blocks

    Versus suprnova:
    https://dcr.suprnova.cc/index.php?page=statistics&action=blocks

    2) vout 1 OP_RETURN push script is the voteBits encoded as a little endian uint16_t.
    Code:
    {"value":"0.00000000","n":1,"version":0,"scriptPubKey":{"asm":"OP_RETURN 0100","hex":"6a020100","type":"nulldata"}}
    As you can see, this vote is casting 0x0001 or simply 1.
     
    jy-p and Dyrk like this.
  19. Kandiru

    Kandiru Member

    Feb 21, 2016
    206
    87
    Wow, coinmine seems to be losing a lot of subsidy by not including votes as often as suprnova. Should people stop using that pool? Hopefully they'll notice they aren't getting as much reward from that pool as they would elsewhere?
     
  20. Dyrk

    Dyrk Sr. Member
    Developer

    Jan 7, 2016
    518
    376
    Male
    Wonderland
    #60 Dyrk, Feb 24, 2016
    Last edited: Feb 24, 2016
    Thank you, @ceejep

    I also noticed that right now "dcrctl missedtickets" contain 147 tickets.
    But from 4095 to 4815 blocks there were 323 missed tickets.
    So does this mean, that if user run "dcrctl rebroadcastmissed" all his missed tickets will be removed from "missedtickets" output?
    Is there any other cases, when these tickets can disappear from "missedtickets" output?

    PS. by the way, you say that it's ~ 1% when block has 3 / 5 votes. But here is what I have calculated (starting from 4096 till 4842):
    - 10.32% blocks have 3 / 5 votes
    - 22.65% blocks have 4 / 5 votes
    - 8.65% of requested tickets missed their vote (323 / 3730).
     

Share This Page