Include masternodeProTxHash in CTxLockVote #2484
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
+1 for proto bump :) |
|
Hmm, while adding the proto bump I realized that this won't help actually, as signatures would be invalid when sent to non-upgraded nodes. I'll make the field dependent on spork15 activation now. |
7c97df7 to
b8eeb01
Compare
|
Updated the PR so that it uses spork15 to determine if the field should be included or not |
thephez
added a commit
to dash-docs/dash-docs
that referenced
this pull request
Dec 13, 2018
masternodeProTxHash (dashpay/dash#2484) quorumModifierHash (dashpay/dash#2505)
thephez
added a commit
to dash-docs/dash-docs
that referenced
this pull request
Dec 26, 2018
* Content - RPC - Update quick reference * RPC - Update getblockchaininfo to show BIP-9 progress Related to dashpay/dash#2435 * RPC - Update gobject prepare with new params Use-IS (dashpay/dash#2452) Use specific UTXO for fee (dashpay/dash#2482) * RPC - Update mode name * RPC - Update protx default mode dashpay/dash#2513 * Content - Add spork 17 * Content - Special transactions Add info for Quorum commitment Remove messages not in 13.0 (SubTx) * P2P - Add new txlvote fields masternodeProTxHash (dashpay/dash#2484) quorumModifierHash (dashpay/dash#2505) * RPC - Update protx list Make all options follow the same parameter format (dashpay/dash#2559) * Content - version bump 0.13.0.0 bumped to 70213 (dashpay/dash#2557) * Guide - PrivateSend dstx message limit Up to 5 simultaneous dstxs per MN allowed (dashpay/dash#2552) * RPC - Update getblock Add missing versionHex field (dashpay/dash@e7d9ffa) Change to use verbosity syntax (dashpay/dash#2506 and bitcoin/bitcoin#8704) * P2P - Add qfcommit message (no hexdump example) DIP6 quorum final commitment (dashpay/dash#2477) * P2P - qfcommit typo Change description of llmqType field * P2P - Special tx payload size clarification * Guide - Update MN payment description Related to dashpay/dash#2258 * Guide - fix broken link * Guide - Update some example txs Change to hashes on the chain following the 12.3.4 reset * P2P - Add QcTx hexdump * P2P - DIP4 message updates Add SML entry Update hexdump to include new fields Add getmnlistd and mnlistdiff to cross ref * P2P - minor DIP3-related comments
CryptoCentric
pushed a commit
to absolute-community/absolute
that referenced
this pull request
Jun 29, 2020
* Introduce proTxHash to CActiveMasternodeInfo * Include masternodeProTxHash in CTxLockVote
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently SPV nodes have no chance to figure out which MN signed a lock vote. This is because only the collateralOutpoint of the MN is included in the vote, which is not part of the DIP4 coinbase commitment and also not in the p2p messages.
This PR adds the proTxHash of the DIP3 MN to the vote, which should allow SPV clients to verify lock votes against the deterministic MN list.
Currently, the added field depends on proto version
70212, which will cause some propagation issues on testnet until enough nodes have upgraded, simply because all nodes are already at70212. To avoid this, we could add a proto bump for this change. @UdjinM6 what do you think?