dash(G1): deterministic equal-feerate tx selection (byte-parity seam) - #623
Merged
Conversation
Block-template tx ordering was the next non-deterministic seam after the curtime seam (#622): get_sorted_txs_with_fees streamed a std::multimap<double,uint256>, so equal-feerate txs kept mempool INSERTION order — node-dependent, breaking G1 byte-parity of the embedded-GBT template projection against the p2pool-dash/dashcore oracle. Replace the index with a FeeKey set sorting feerate-desc then txid-asc, matching dashcore CompareTxMemPoolEntryByAncestorFee (GetHash tiebreak). Selection is now byte-reproducible regardless of arrival order. Fenced to src/impl/dash/coin/mempool.hpp + test. No shared/other-coin tree, no consensus-value change (same txs, deterministic order). KAT pins equal-feerate ties resolve txid-ascending, insertion-independent.
…vided double FeeKey keyed the sorted index on a pre-divided double (fee/base_size). That division rounds, so it can collapse a strict dashcore order into a tie -- or split a dashcore tie into a strict order -- diverging the selection order (and thus template byte-serialization) from the p2pool-dash/dashcore oracle. dashcore CompareTxMemPoolEntryByAncestorFee avoids division by cross-multiplying (fee, size) as doubles; FeeKey now carries (fee, base_size) and reproduces that exact comparison. Equal feerate still breaks by txid ascending (GetHash), as the oracle does. Adds an exhaustive-search divergence-vector KAT that pins the cross-multiply against an independent oracle reimplementation and the real std::set<FeeKey> index. Fenced to src/impl/dash/coin/mempool.hpp + test/test_dash_mempool.cpp; no shared/other-coin/consensus reach.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
G1 byte-parity — next non-deterministic seam after curtime (#622)
The embedded-GBT template builder serializes txs in the order get_sorted_txs_with_fees() returns. That index was a std::multimap<double,uint256>, so equal-feerate txs stayed in mempool insertion order — node-dependent. Two nodes with identical mempool contents but different arrival order produced different template bytes: a non-deterministic seam breaking G1 byte-parity vs the p2pool-dash / dashcore oracle. Independent of #622 (does not touch curtime).
Fix
Replace the index with a FeeKey set sorting feerate-desc, then txid-asc — matching dashcore CompareTxMemPoolEntryByAncestorFee (breaks feerate ties by GetHash()). Selection is byte-reproducible regardless of tx arrival order; removal becomes O(log n) direct erase.
Scope / safety
Verify (non-hollow, Linux x86_64, from build/)
No self-merge — surfacing for integrator verify (oracle tiebreak + full rollup) then operator tap.