Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

How does new revert protection detect pool support?

Discussion in 'Mining' started by Steve Sokolowski, Jun 2, 2019.

  1. Steve Sokolowski

    Steve Sokolowski New Member

    Joined:
    Feb 19, 2017
    Messages:
    17
    Likes Received:
    21
    Trophy Points:
    3
    I've been talking with Phillipp Engelhorn about the upcoming Dash upgrade over the past week, but he is serving as an intermediary to the developers and I thought it would be more efficient to post messages directly here rather than force him to constantly relay E-Mails.

    I sent him the following code, which I must have written as a result of talking with udjin months ago:

    Code:
    if coinbase_payload:
                tx_version = 3
                tx_type = 5
                self.nVersion = tx_version + (tx_type << 16)  #For Dash, from https://github.com/UNOMP/node-merged-pool/pull/17/commits/8134bbb3d954724b0437758042a0c8d4bf92e1bc, may need to generalize this to other coins in the future
            else:
                self.nVersion = 1
    
    I don't recall where these constants originated from, but the comment indicates they may have come from reviewing some open source pool software.

    I was told by Phillipp that the constants should remain the same for the new fork of Dash. If that is true, then how does the network detect that the upgrade is ready to occur? Does the updated daemon change something in the blocks submitted to it from submitblock() before publishing them? Is there some soft of message sent over the network apart from the blocks that is handled automatically by the updated daemon, and therefore all that need to be done is to upgrade?

    Even after reading all the documentation, the most challenging part is that there is nowhere that makes it clear what signals this upgrade if these constants don't change.
     
  2. thephez

    thephez Member
    Dash Core Team

    Joined:
    Jan 23, 2016
    Messages:
    113
    Likes Received:
    49
    Trophy Points:
    78
    As with the previous update, this change will be activated via the standard BIP-9 process. The signaling bit in the block version is bit 4 this time (i.e. blocks signaling support are using 0x20000010 for block version).

    The section of code you posted is related to the Coinbase special transaction defined by DIP-4. The new version of Dash Core (0.14.x) will update the special transaction payload version from 1 to 2. Version 2 of the special tx payload adds the `merkleRootQuorums` field as indicated in the linked document.

    You can check the progress by running `getblockchaininfo`. The (perhaps confusingly named) item to check is "dip0008"

    Code:
        "dip0008": {
          "status": "started",
          "bit": 4,
          "period": 4032,
          "threshold": 3226,
          "windowStart": 1080576,
          "windowBlocks": 1689,
          "windowProgress": 0.5235585864848109,
          "startTime": 1557878400,
          "timeout": 1589500800,
          "since": 1072512
        },
     
  3. thephez

    thephez Member
    Dash Core Team

    Joined:
    Jan 23, 2016
    Messages:
    113
    Likes Received:
    49
    Trophy Points:
    78
  4. Steve Sokolowski

    Steve Sokolowski New Member

    Joined:
    Feb 19, 2017
    Messages:
    17
    Likes Received:
    21
    Trophy Points:
    3
    The way I understand it now, then, is that I can simply change this tx_version constant to 4, and leave everything else the same, and upgrade to the latest version of Dash? As far as I can tell, all the other changes depend on the behavior of masternodes, right, and the daemon will handle determining the best chain automatically with its new rules?
     
  5. thephez

    thephez Member
    Dash Core Team

    Joined:
    Jan 23, 2016
    Messages:
    113
    Likes Received:
    49
    Trophy Points:
    78
    No, the tx_version isn't changing. Only the payload version will change. Special txs have both:
    1. The "normal" tx version - which is currently 3 and will not change with this release
    2. The extra_payload version - which is changing from 1 to 2 as described in DIP-4 linked to above
    The "4" I mentioned was related to the the specific bit in the block version that is set to signal support. I think simply updating to the new version of Dash Core handles that per the conditions describe in the release notes linked to above.
     
  6. codablock

    codablock Member
    Core Developer

    Joined:
    Mar 29, 2017
    Messages:
    98
    Likes Received:
    149
    Trophy Points:
    83
    To add to what @thephez already wrote: There is no need to change anything in mining pool software in this release. The changes to the coinbase are internal and reflected in the coinbase_payload from the block template. So, as long as you just take that field 1:1 (which seems to be the case), there is no need for action here.

    The signalling is happening through a BIP9 bit, as already explained by thephez. This also means that there is no need for action as long as you use the result of getblocktemplate unmodified (which also seems to be the case for you).
     
  7. Steve Sokolowski

    Steve Sokolowski New Member

    Joined:
    Feb 19, 2017
    Messages:
    17
    Likes Received:
    21
    Trophy Points:
    3
    OK, great. I looked at the code and realized I didn't post all of it. I looked back to the time when I last posted to the Dash forums, and found that in the same commit I had also added code to append the coinbase_payload to the coinbase transaction. Since I was told above that no changes are necessary to the tx_version or anything I posted here, then nothing needs to be done except to upgrade to the latest version of Dash.

    I will ask the employee responsible for doing that to upgrade on Saturday afternoon, when he returns from vacation. Thanks for everyone's help! Dash's support is always the best of any coin!
     
    • Like Like x 1