delvingbitcoin
Deterministic tx selection for censorship resistance
Posted on: January 4, 2025 07:56 UTC
The discussed email elaborates on the complexities and proposed methodologies regarding transaction selection and block space allocation in cryptocurrency mining pools.
The primary focus is on a scenario where 100% participation in a described pool would necessitate miners to process transactions previously included in shares before selecting their transactions. This situation presents two notable exceptions. Firstly, if the deterministic algorithm prioritizes transactions with the highest fee rates, it allows for the immediate inclusion of such transactions into blocks by adhering to this algorithm. Secondly, the proposition includes allocating 95% of the block space deterministically based on specific criteria, while reserving 5% of the block space for miners to include transactions at their discretion, reminiscent of the priority space in older mining practices.
The implementation of a deterministic mempool at the consensus level among a pool introduces considerable challenges, especially concerning the adaptation and enforcement of new policies or technological updates such as TRUC relay, Revised By Fee (RBF) policies, soft fork features introduction, and adjustments in minimum fee rates or size limits. Moreover, the complexity escalates when there’s a need for efficient calculation of the mempool's top from its previous state, which is crucial for handling situations where multiple transactions are processed simultaneously, exceeding the standard processing width.
A technical solution is suggested to manage the influx of transaction data within the pool efficiently. By utilizing sha256(sharehash)
as a random seed, a mechanism could be established where only a fraction of the transactions (about 10%) could include up to 150kvB of transaction data destined for subsequent blocks, whereas the majority (90%) would be limited to including a much smaller amount of transaction data (5kvB). This approach aims to distribute approximately ~2MvB of transaction data across 100 beads (or segments), aligning with a practical framework for a pool with 10% hashrate operating at 1/100th difficulty, thereby facilitating a more manageable and equitable process for transaction data relay and incorporation over a span of 600 seconds (or 10 minutes) at the given hash rate and difficulty level.