Mining - Too Few Voters - Shall I Be Worried?

Discussion in 'Proof-of-work Mining' started by root, Mar 13, 2016.

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

    root Member

    Feb 3, 2016
    381
    76
    Hi all,
    lines below were found in my daemon log ... shall I be worried somehow ?
    ( Too few voters found )

    Also - I see over 18 DCR mined here ,
    but only over 14 mined here .
    Isn't it strange ?

    ========
    12:49:31 2016-03-13 [DBG] CHAN: Block 0000000000001af287a2f03abafc904b0e257f32629726b9e0322caf561a0072 (height 9997) connected to the main chain, validating the previous block
    12:49:31 2016-03-13 [DBG] CHAN: Accepted block 0000000000001af287a2f03abafc904b0e257f32629726b9e0322caf561a0072
    12:49:31 2016-03-13 [TRC] TXMP: Removing transaction 45eb8d2f093d083f13987e4cce5622361140b38e9ae2601c458522e205b0ffdf
    12:49:31 2016-03-13 [TRC] TXMP: Removing transaction 7587698c16ebde4c2c3a1034dd3f82eb4d182677c08de9828abf90f48095d62a
    12:49:31 2016-03-13 [INF] RPCS: Block submitted via getwork accepted: 0000000000001af287a2f03abafc904b0e257f32629726b9e0322caf561a0072
    12:49:31 2016-03-13 [DBG] MINR: Too few voters found on any HEAD block, recycling a parent block to mine on
    12:49:31 2016-03-13 [TRC] SCRP: stepping (past input scripts 2:0 2:xxxx)
    12:49:31 2016-03-13 [TRC] SCRP:
    12:49:31 2016-03-13 [TRC] SCRP: stepping (past input scripts 2:0 2:xxxx)
    =========
    17:04:01 2016-03-05 [TRC] TXMP: Removing transaction a4b84019de56b53d2a611d3ada28938fad2b836a4a7c325c0800cb9934bc4cc1
    17:04:01 2016-03-05 [TRC] TXMP: Removing orphan transaction a4b84019de56b53d2a611d3ada28938fad2b836a4a7c325c0800cb9934bc4cc1
    17:04:01 2016-03-05 [DBG] CHAN: Block 0000000000002bfb2c97a5bcb54cfa32d91692f5ba0b25b8b10b5e1f8ed1d8b7 (height 7732) connected to the main chain, validating the previous block
    17:04:01 2016-03-05 [DBG] CHAN: Accepted block 0000000000002bfb2c97a5bcb54cfa32d91692f5ba0b25b8b10b5e1f8ed1d8b7
    17:04:01 2016-03-05 [INF] RPCS: Block submitted via getwork accepted: 0000000000002bfb2c97a5bcb54cfa32d91692f5ba0b25b8b10b5e1f8ed1d8b7
    17:04:01 2016-03-05 [DBG] MINR: Too few voters found on any HEAD block, recycling a parent block to mine on
    17:04:01 2016-03-05 [DBG] RPCS: Received command <notifyreceived> from 127.0.0.1:43584
    17:04:01 2016-03-05 [TRC] PEER: 199.191.58.113:9108 (outbound): sending to outHandler
    17:04:01 2016-03-05 [TRC] PEER: 199.191.58.113:9108 (outbound): sent to outHandler
    17:04:01 2016-03-05 [TRC] PEER: 199.191.58.113:9108 (outbound): received from queuehandler
    17:04:01 2016-03-05 [DBG] PEER: Sending inv (block 0000000000002bfb2c97a5bcb54cfa32d91692f5ba0b25b8b10b5e1f8ed1d8b7) to 199.191.58.113:9108 (outbound)
    ========
     
  2. Enjei

    Enjei New Member

    Feb 8, 2016
    26
    7
    Male
    If someone's ticket is selected and their wallet is offline, they miss their vote; in turn the miner who found the block is not rewarded as much, (60% with 3 votes, 80% with 4 votes, 100% with 5).

    It can also happen when a block is found very quickly after the previous block, and the miner has high latency (he dosen't have the opportunity to include the broadcasted votes in the block before submitting).

    Afaik, this is all normal.
     
  3. eshriek

    eshriek New Member

    Jan 16, 2016
    45
    12
    Male
    Whoa, that really sucks for the PoW miner.

    Are there any suggestions for when PoS voting is not likely to happen? I.e., I was offline for about 2 minutes updating to .0.0.7. Do I just hope and pray that my tickets don't come up as that time?
     
  4. SG-O

    SG-O Member
    Developer

    Jan 13, 2016
    104
    86
    Male
    Software Dev
    Milky Way
    On my PoS mining rig (Dual Core ARM board) updating takes about an hour, that sucks!
     
  5. Ayush

    Ayush Full Member
    Advocate (Facebook)

    Jan 9, 2016
    512
    100
    Male
    .
    .
    Using stake pools helps greatly.
     
  6. root

    root Member

    Feb 3, 2016
    381
    76
    To rephrase my problem - question :
    (1) What is the problem with mining reward being once over 18 and once over 14 DCR (see above) ?
    (2) What is the probability that while i have found only 2 blocks in 40 days, all of them will have less votes ?
    (3) Do they really have less votes or is it just some strange message related to other block or is it a software bug / error (see log above) ?
     
  7. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    (1) Depends on your network connectivity. Try adding more nodes and making sure the nodes are on the latest version. Ping them and drop nodes with high ping.
    (2) Depends on your network connectivity.
    (3) The debug message "Too few voters found on any HEAD block, recycling a parent block to mine on" refers to the normal mode of the mining algorithm, which mines off the parent block if there aren't enough voters to mine on the tip block. It does this so that you don't sit around and wait and do nothing if no votes ever come in.
     
  8. root

    root Member

    Feb 3, 2016
    381
    76
    Thank you for answers, but they bring new questions, sorry ;)

    I have a fiber network (EU), pings 25 ms FRA, 45 ms DUB, 120 ms JFK.
    I had 8 peers, some old dcrds and some nearly 200ms ping, just used
    getpeerinfo | grep -E "(addr|pingtime|subver)" and node disconnect to clean them up.
    (1a) So why the mining reward is only over 14 DCR (see above) ?
    (1b) Are there any rules or 'good practice' regarding maximum pings, minumum versions, minimum number of peers, etc ?
    (2a) With the information above - would you consider my network connection "bad" or "the reason" ? Running Linux x64, Intel i5/16GB.
    (3a) So I would consider it "just some strange message related to other block" - not mine I just have mined. Is that so ?

    Thank you for your time,
    you are doing great job !
     
  9. ceejep

    ceejep Sr. Member
    Developer

    Dec 14, 2015
    192
    220
    Your block was missing votes. Either you failed to see them on the network (bad peers, old version) or the voter failed to vote (you got unlucky).

    Not as of yet, but for PoW/PoS miners you should use your best judgement because your subsidy relies on it. e.g. connect to the lowest latency peers with permanence.

    That should be fine, that's similar to my node. I don't mine PoW or PoS, but blocks and votes come in quickly for me.

    Yeah, it's a debug message indicating that the code is functioning how it's supposed to.

    Thanks!
     
    root likes this.

Share This Page