• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

How does new revert protection detect pool support?

Status
Not open for further replies.

Steve Sokolowski

New member
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.
 
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
    },
 
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.

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?
 
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.
 
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).
 
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!
 
Status
Not open for further replies.
Back
Top