V14.0.1 #24
Merged
V14.0.1 #24
Conversation
This file contains 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
…category (dashpay#2792) * Add missing log categories to help message and combined "dash" category * Sort alphabetically
…2790) * Sort evo/* source files in Makefile.am * Keep track of proRegTxHash in CConnman::masternodeQuorumNodes map We will later need the proRegTxHash * Fix serialization of std::tuple with const rvalue elements Having serialization and deserialization in the same specialized template results in compilation failures due to the "if(for_read)" branch. * Implement MNAUTH message This allows masternodes to authenticate themself. * Protect fresh incoming connections for a second from eviction Give fresh connections some time to do the VERSION/VERACK handshake and an optional MNAUTH when it's a masternode. When an MNAUTH happened, the incoming connection is then forever protected against eviction. If a timeout of 1 second occurs or the first message after VERACK is not MNAUTH, the node is not protected anymore and becomes eligable for eviction. * Avoid connecting to masternodes if an incoming connection is from the same one Now that incoming connections from MNs authenticate them self, we can avoid connecting to the same MNs through intra-quorum connections. * Apply review suggestions
No real reason to ignore this message. It might become useful in the future.
…UTH peers (dashpay#2798) * Pass CNode* to IsMasternodeQuorumNode and let it also check verifiedProRegTxHash This makes IsMasternodeQuorumNode return true on incoming peer connections as well. * Let GetMasternodeQuorumNodes also take verifiedProRegTxHash into account This makes it return NodeIds for incoming peer connections as well. * Remove AddParticipatingNode and the need for it This was needed in the past when we were unable to identify incoming connections from other quorum members. Now that we have MNAUTH, we can easily identify all connected members. * Don't track interestedIn quorums in CSigSharesNodeState anymore Same as with the previous commit, we're now able to easily identify which nodes to announce sig shares to. * Remove unused CConnman::GetMasternodeQuorumAddresses
…ashpay#2799) * Use llmq-sig log category for CSigSharesManager * Use llmq-dkg log category for DKG related logging
* Prepare Dash-related stuff before starting ThreadImport * Ensure activeMasternodeManager is not null in ThreadImport when DIP3 is active and we are running in masternode mode
Replace it with regular "governance" category limited LogPrint-s where it makes sense.
* fix typo * align `=`s * fix warniing
…ashpay#2804) * Reset local/static cache in LogAcceptCategory when categories change Without this, it is always required to first set debug to 0, wait a few seconds (until LogAcceptCategory is called by all affected threads) and then call "debug somecategory". Otherwise "ptrCategory" never gets updated. This PR also stores a cache counter locally and globally and updates "ptrCategory" when the counters do not match. * Lock cs_args in LogAcceptCategory
* Fix potential deadlock in LoadWallet() ``` POTENTIAL DEADLOCK DETECTED Previous lock order was: (1) cs_main wallet/wallet.cpp:3881 (2) cs_wallet wallet/wallet.cpp:3881 Current lock order is: (2) pwallet->cs_wallet wallet/walletdb.cpp:589 (1) cs_main wallet/wallet.cpp:1252 ``` * Add comment in CWallet::MarkConflicted re new cs_main lock in CWalletDB::LoadWallet()
* Fix qt tests and run them when compiling with DDEBUG_LOCKORDER flag * Drop "NO_QT=1"
Ignoring the same issue for legacy IS because it's going to be removed later.
* Update "debug" rpc help text * add missing "qt" category * add a note about non-matching categories
- Move "confirmations" to match actual RPC output order
* Drop all kind of invalid votes from all types of gobjects Currently we only do so for proposal "funding" votes which looks incomplete. * Apply review suggestions
On testnet it's quite usual to have multiple MNs on the same IP. Now that we have LLMQs and DKGs which require deterministic intra quorum connections, we must allow them to connect to each other even if the IPs are shared very often.
* Keep the most recent gobject vote only We don't need to store full vote data for old votes - we never relay them to other nodes anyway. Still keep old hashes to avoid re-requesting data etc. * add comment * Drop getvotes rpc * Compare vote signals, do not compare hashes Also add comments
Use a pointer instead of a static variable, start/stop together with other llmq modules.
…c7d2dbfe2f9) (dashpay#2821) * Update immer library to current master (0a718d2d76bab6ebdcf43de943bd6c7d2dbfe2f9) * Temporary fix for alignof(std::max_align_t) on MinGW 32bit builds See arximboldi/immer#78
* sp: s/signReqeust/signRequest/g * sp: s/documenation/documentation/
[v0.14.0.x] Backport pending PRs from develop into v14
…#3203) * Bump version to 0.14.0.4 * Run gen-manpages.sh to update versions * Prepare release notes for 0.14.0.4 * Add first draft of "Notable Changes" * Handle review comments
… set on a peer (dashpay#3225) c4af738 Fix ignoring tx data requests when fPauseSend is set on a peer (Matt Corallo) Pull request description: This resolves a bug introduced in 66aa1d5 where, if when responding to a series of transaction requests in a getdata we hit the send buffer limit and set fPauseSend, we will skip one transaction per call to ProcessGetData. Bug found by Cory Fields (@theuni). Probably worth slipping into 0.16 :/. Tree-SHA512: a9313cef8ac6da31eb099c9925c8401a638220cf7bc9b7b7b83151ecae4b02630f2db45ef6668302b9bb0f38571afbd764993427f1ec9e4d74d9a3be6647d299
…/start_masternodes (dashpay#3221) * Tests: Connect to the control node only in start_masternodes Masternodes should take care of intra-quorum connections themselves * Reconnect non-masternodes back to the control node
But slightly modified so that they work with wait_until which does not assert in v0.14.0.x
…hpay#3219) * Implement re-signing of InstantSend inputs when TXs come in via blocks * Use GetAdjustedTime instead of GetTimeMillis in CSigSharesManager This allows use of mocktime in tests. * Expose verifiedProRegTxHash in getpeerinfo and implement wait_for_mnauth * Allow to wait for IS and CL to NOT happen * Bump timeout for wait_for_instantlock * Implement tests for retroactive signing of IS and CLs * Add wait_for_tx function to DashTestFramework * Add -whitelist=127.0.0.1 to node0 * Use node3 for isolated block generation * Don't test for non-receival of TXs on node4/node5
Mostly related to wait_until not asserting in 0.14.0.x
[v0.14.0.x] Backport pending PRs
* Bump version to 0.14.0.5 * Copy 0.14.0.4 release notes and prepare 0.14.0.5 release notes * Run gen-manpages.sh
…cksHandler despite node restarts (dashpay#3230)
…ashpay#3229) * Update release notes with notable changes and changelog * Add dashpay#3230 to changelog
Notable changes DIP0004 - Coinbase Payload v2 Coinbase Payload v2 introduces new field merkleRootQuorums which represents the merkle root of all the hashes of the final quorum commitments of all active LLMQ sets. This allows SPV clients to verify active LLMQ sets and use this information to further verify ChainLocks and LLMQ-based InstantSend messages. Coinbase Payload v2 relies on DIP0008 (bit 4) activation. DIP0008 - ChainLocks This version introduces ChainLocks, a technology for near-instant confirmation of blocks and finding near-instant consensus on the longest valid/accepted chain. ChainLocks leverages LLMQ Signing Requests/Sessions to accomplish this. ChainLocks relies on DIP0008 (bit 4) activation and SPORK_19_CHAINLOCKS_ENABLED spork. DIP0010 - LLMQ-based InstantSend InstantSend is a feature to allow instant confirmations of payments. It works by locking transaction inputs through masternode quorums. It has been present in Absolute for a few years and been proven to work. Nevertheless, there are some limits which could theoretically be removed in the old system but doing so would have created risks in terms of scalability and security. We introduce LLMQ-based InstantSend which is designed to be much more scalable without sacrificing security and which allows all transactions to be treated as InstantSend transactions. The old system differentiated transactions as InstantSend transactions by using the P2P message “ix” instead of “tx”. Since this distinction is not required in the new system, the P2P message “ix” will be removed after DIP0008 deployment (for now, transactions sent via "ix" message will be relayed further via "tx" message). Network Legacy messages mnw, mnwb, mnget, mnb, mnp, dseg, mnv, qdcommit and their corresponding inventory types (7, 10, 14, 15, 19, 22) are no longer suported. Message version is extended with a 256 bit field - a challenge sent to a masternode. Masternode which received such a challenge must reply with new p2p message mnauth directly after verack. This mnauth message must include a signed challenge that was previously sent via version. Mining Due to changes in coinbase payload this version requires for miners to signal their readiness via BIP9-like mechanism - by setting bit 4 of the block version to 1. Note that if your mining software simply uses coinbase_payload field from getblocktemplate RPC and doesn't construct coinbase payload manually then there should be no changes to your mining software required. We however encourage pools and solo-miners to check their software compatibility on testnet to ensure flawless migration. PrivateSend The wallet will try to create and consume denoms a bit more accurately now. It will also only create a limited number of inputs for each denominated amount to prevent bloating itself with mostly the smallest denoms. You can control this number of inputs via new -privatesenddenoms cmd-line option (default is 300). InstantSend Legacy InstantSend is going to be superseded by the newly implemented LLMQ-based one once DIP0008 (bit 4) is active and SPORK_20_INSTANTSEND_LLMQ_BASED spork is ON. Sporks There are two new sporks introduced in this version - SPORK_19_CHAINLOCKS_ENABLED and SPORK_20_INSTANTSEND_LLMQ_BASED. SPORK_17_QUORUM_DKG_ENABLED was introduced in v0.13 but was kept OFF. It will be turned on once 80% masternodes are upgraded to v0.14 which will enable DKG and DKG-based PoSe. QR codes Wallet can now show QR codes for addresses in the address book, receiving addresses and addresses identified in transactions list (right click -> "Show QR-code"). RPC, ZMQ and command-line changes This release introduced various changes to these subsystems, please see detailed release notes for more info.
Notable changes DIP0004 - Coinbase Payload v2 Coinbase Payload v2 introduces new field merkleRootQuorums which represents the merkle root of all the hashes of the final quorum commitments of all active LLMQ sets. This allows SPV clients to verify active LLMQ sets and use this information to further verify ChainLocks and LLMQ-based InstantSend messages. Coinbase Payload v2 relies on DIP0008 (bit 4) activation. DIP0008 - ChainLocks This version introduces ChainLocks, a technology for near-instant confirmation of blocks and finding near-instant consensus on the longest valid/accepted chain. ChainLocks leverages LLMQ Signing Requests/Sessions to accomplish this. ChainLocks relies on DIP0008 (bit 4) activation and SPORK_19_CHAINLOCKS_ENABLED spork. DIP0010 - LLMQ-based InstantSend InstantSend is a feature to allow instant confirmations of payments. It works by locking transaction inputs through masternode quorums. It has been present in Absolute for a few years and been proven to work. Nevertheless, there are some limits which could theoretically be removed in the old system but doing so would have created risks in terms of scalability and security. We introduce LLMQ-based InstantSend which is designed to be much more scalable without sacrificing security and which allows all transactions to be treated as InstantSend transactions. The old system differentiated transactions as InstantSend transactions by using the P2P message “ix” instead of “tx”. Since this distinction is not required in the new system, the P2P message “ix” will be removed after DIP0008 deployment (for now, transactions sent via "ix" message will be relayed further via "tx" message). Network Legacy messages mnw, mnwb, mnget, mnb, mnp, dseg, mnv, qdcommit and their corresponding inventory types (7, 10, 14, 15, 19, 22) are no longer suported. Message version is extended with a 256 bit field - a challenge sent to a masternode. Masternode which received such a challenge must reply with new p2p message mnauth directly after verack. This mnauth message must include a signed challenge that was previously sent via version. Mining Due to changes in coinbase payload this version requires for miners to signal their readiness via BIP9-like mechanism - by setting bit 4 of the block version to 1. Note that if your mining software simply uses coinbase_payload field from getblocktemplate RPC and doesn't construct coinbase payload manually then there should be no changes to your mining software required. We however encourage pools and solo-miners to check their software compatibility on testnet to ensure flawless migration. PrivateSend The wallet will try to create and consume denoms a bit more accurately now. It will also only create a limited number of inputs for each denominated amount to prevent bloating itself with mostly the smallest denoms. You can control this number of inputs via new -privatesenddenoms cmd-line option (default is 300). InstantSend Legacy InstantSend is going to be superseded by the newly implemented LLMQ-based one once DIP0008 (bit 4) is active and SPORK_20_INSTANTSEND_LLMQ_BASED spork is ON. Sporks There are two new sporks introduced in this version - SPORK_19_CHAINLOCKS_ENABLED and SPORK_20_INSTANTSEND_LLMQ_BASED. SPORK_17_QUORUM_DKG_ENABLED was introduced in v0.13 but was kept OFF. It will be turned on once 80% masternodes are upgraded to v0.14 which will enable DKG and DKG-based PoSe. QR codes Wallet can now show QR codes for addresses in the address book, receiving addresses and addresses identified in transactions list (right click -> "Show QR-code"). RPC, ZMQ and command-line changes This release introduced various changes to these subsystems, please see detailed release notes for more info.
Backport cleanup to align with 14.0.x
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.
Version 14 Update
DIP0004 - Coinbase Payload v2
DIP0008 - ChainLocks
DIP0010 - LLMQ-based InstantSend