Published on: 2018-01-28T18:08:33+00:00
The Bitcoin-dev mailing list has been discussing the possibility of merging multiple unconfirmed transactions. The main objective is to combine these transactions into one, removing unnecessary inputs and change, while ensuring that the merged transaction pays an equal or higher fee compared to the original transactions. However, this is currently not feasible due to the bip125 rule, which requires a significant increase in the feerate for replacement transactions. Some participants in the discussion propose modifying this rule to allow retroactive transaction merging, as it is seen as more practical than appending existing transactions.One concern raised during the discussion is the potential for relay spam and the risk of pushing other users' transactions out of the mempool if transaction merging is allowed. To address this, some suggest that wallets and exchange APIs could collaborate to consolidate in-mempool transactions. Additionally, the complexity involved in implementing smarter types of merging is discussed, along with the need to relax the rules of BIP125 to support this approach if it can be done without introducing risks.The conversation also explores the difficulty of achieving no change when using an intelligent coin selection algorithm to pay for outputs. It is noted that most transactions involve change because inputs rarely match the exact payment amount requested. However, there are ways to optimize coin selection to avoid generating change. Developers Achow101 and Murch have created code for Bitcoin Core that implements an efficient algorithm for finding solutions in these cases.Another point of discussion is the incentive compatibility of BIP125. Some argue that accepting a replacement transaction with a lower fee rate in a competitive mempool may not be rational. Originally, Peter Todd proposed requiring only an increase in fee rate for replacement transactions, but later decided on both a feerate and absolute fee increase criteria for simplicity. Gregory Maxwell clarifies that BIP125 replacement does indeed require an increase in the fee rate, and the confusion arises from the use of the term "original transactions" when there should only be one transaction in the mempool at a time.Overall, the discussion highlights the challenges and feasibility of transaction merging in the mempool. There are varying opinions on modifying the rules of BIP125 to allow for retroactive transaction merging, with concerns about potential DoS vectors and the displacement of other transactions in the mempool. The difficulty of achieving no change with intelligent coin selection algorithms is also discussed, along with the need for a clear understanding of the incentive compatibility of BIP125 replacement. Currently, there is no direct method to track merged transactions when a replaced transaction gets confirmed after a new one has been created to achieve the same goal. Although merging multiple unconfirmed transactions could result in significant savings, finding a viable solution remains an ongoing challenge.
Updated on: 2023-08-01T22:30:43.321537+00:00