You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!
Background
Please feel free to skip this section if you are already familiar
I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.
My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.
A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].
Two transactions with the same non-witness data but different witnesses have the same txid but different wtxid, and the same fee but not necessarily the same feerate. Currently, in mempool validation, if we see a transaction that has the same txid as one in the mempool, we reject it as a duplicate. This shouldn’t pose a serious security risk except in transactions where multiple parties contribute to the inputs (which is also rare and usually involves trusted or somewhat trusted parties). However, the correct behavior should be to replace mempool transactions if a new transaction has a better feerate, with some caveats to avoid DoS attacks (similar to BIP125).
Previous work and discussion:
Antoine Riard first pointed out this issue in #19645. His implementation uses the existing mempool validation code to replace by BIP125 rules. He has indicated that he isn’t planning to return to this work in the near future (in #l2-onchain-support): https://gist.github.com/glozow/d
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
The purpose of the mempool is to store the best candidates for inclusion in a block, i.e., the ones with the highest fees (including fee-bumped ones).
Non-mining nodes use the mempool to make block validation faster and to aid transaction relay.
If transaction relay and mempool logic are working well, all transactions paying reasonable fees should make it to miners, and all nodes with (even small) mempools should have the transactions that will be in the next blocks.
Currently, we limit the size of our mempool (default 300MB) and only validate transactions one at a time -
this creates a limitation in a node's ability to determine which transactions have the highest fees, because a low fee transaction can have a high fee child.