Bitcoin Optech # 151: Selection of transactions
This week’s Bitcoin Optech newsletter describes a proposal to change Bitcoin Core’s transaction selection algorithm and more.
The Bitcoin Optech Newsletter provides readers with a high-level summary of the most important technical news about Bitcoin, along with resources that help them learn more. To help our readers stay up to date with Bitcoin, we are republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.
This week’s newsletter outlines a proposal to change Bitcoin Core’s transaction selection algorithm for miner block models to slightly increase miners’ profitability and give users who benefit from additional fees. greater collective leverage. Also included are our regular sections describing software releases and candidate releases, as well as notable changes to popular Bitcoin infrastructure software.
- Construction of the block model based on the candidate set (CSB): Mark Erhardt posted on the Bitcoin-Dev mailing list an analysis he and Clara Shikhelman performed on an alternative transaction selection algorithm for miners. Bitcoin’s consensus rules dictate that no transaction can be included in a block unless all of its unconfirmed ancestors are also included earlier in that same block. Bitcoin Core addresses this constraint by treating every transaction with unconfirmed ancestors as if it contained both the fees and the size of those ancestors. For example, if transaction B depends on unconfirmed transaction A, then Bitcoin Core adds the fees paid by the two transactions and divides them by the combined size of the two transactions. This allows Bitcoin Core to fairly compare all transactions in the mempool based on their effective rate, whether or not those transactions have ancestors. However, Erhardt and Shikhelman note that a more sophisticated algorithm that may require a bit more CPU can find sets of associated transactions. which are even more profitable to operate than Bitcoin Core’s existing simple algorithm. The authors tested their algorithm on historical data from mempool and found that it would have collected slightly more fees than Bitcoin Core’s existing algorithm in almost all recent blocks. If implemented and used by miners, the improved algorithm could allow multiple users who have each received output from a large join or bulk payment to each pay a small portion of the total fees required for the users. CPFP fees that exceed this join or payment. This would be an improvement over the current case where each user’s CPFP fee markup is considered independently and multiple associated fee markups may not have an overall effect on fetching an ancestor transaction.
Release and Release Candidates
New versions and candidate versions for popular Bitcoin infrastructure projects. Please consider upgrading to new versions or helping to test candidate versions.
- HWI 2.0.2 is a minor release which adds support for signing messages with BitBox02, still uses
'to the indicated BIP32 paths with reinforced derivation, and includes several bugfixes.
- LND 0.13.0-beta.rc3 is a release candidate that adds support for using a pruned Bitcoin full node, allows payments to be received and sent using Atomic MultiPath (AMP) and increases its PSBT capabilities, among other improvements and bug fixes.
Notable changes to code and documentation
Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIP) and Lightning BOLT.
- Bitcoin Core # 20833 is the first PR in an effort to implement acceptance of mempool packages in Bitcoin Core. This change allows the
testmempoolacceptRPC to accept multiple transactions where subsequent transactions can be descended from earlier transactions. Future PRs could allow testing of L2 transaction chains, submitting transaction packages directly to the memory pool via RPCs, and communicating packages over the P2P network.
- Bitcoin Core # 22017 updates the code signing certificate used for versions of Windows after the previous certificate was revoked by its issuer without providing an explicit reason. Several recent versions of Bitcoin Core could be re-released with slightly different version numbers so that their Windows binaries can use this certificate.
- Bitcoin Core # 18418 increases the maximum number of UTXO received at the same address that will be spent simultaneously if the
avoid_reusethe portfolio indicator is set. The higher the number of exits spent together, the higher the fees can be compared to a wallet with default metrics, but also the less likely it is that third parties will be able to identify the user’s subsequent transactions. .
- C-Lightning # 4501 adds JSON schemas for the output of about half of C-Lightning’s current commands (with schemas for the other half expected to be added in the future). The output produced during a run of the C-Lightning test suite is validated against schemas to ensure consistency. Schemas are also used to automatically generate C-Lightning documentation on the output produced by each order.
- LND # 5025 adds basic support for using the bookmark. Among other LN implementations tracked by Optech, C-Lightning also supports bookmark (see newsletter # 117).
- LND # 5155 adds a configuration option to randomly select wallet UTXOs to spend in a transaction; this reduces UTXO fragmentation in the wallet over time. In contrast, the default coin selection algorithm in LND spends higher value UTXOs before lower value UTXOs; this minimizes short-term fees but may result in the need to pay higher fees in the future when all of the inputs close to transaction size, or more, have already been spent.
- BOLTs # 672 updates BOLT2 to allow nodes to negotiate a
option_shutdown_anysegwitoption which, if set, allows LN closing transactions to be able to pay for any version of segwit script, including script types that do not yet have consensus meaning on the network, such as addresses for the taproot.
- BOLTs # 872 updates BIP69’s use of BOLT3 to further specify the sort order to be used for commit transaction inputs and outputs. One commenter points out that the use of BIP69 has so far caused three separate issues that may have led to accidental channel closings and small losses of funds due to unnecessary on-chain charges. The commentator suggests that this is another reason to move away from the explicit use of BIP69 (for other reasons, see Newsletter # 19).
Find the original article here.
Please sign up directly for the Bitcoin Optech newsletter to receive this content straight to your inbox each month.
The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.