Author: ZmnSCPxj 2018-02-04 22:24:36
Published on: 2018-02-04T22:24:36+00:00
The author of the message attempts to create a precise algorithm for RBF (Opt-in Full Replace-by-Fee) in order to do "transaction merging" on the fly, whereby an unconfirmed transaction can be replaced without creating a new one. The issue lies in tracking the mess that occurs when a replacement transaction is confirmed after the original transaction has already been confirmed. One possible solution is to only consider a transaction "replaceable" if it has change, so that payments can be made immediately if the original transaction confirms, providing safety in a reorg. However, this solution only works if there is change and opens up complexities. The problematic sequence of events has been described, and the author proposes ensuring that a new transaction is incompatible with the original one by spending an input that the new transaction spends but the original doesn't. This ensures that either the original and new transactions confirm or just the new one does. The author also suggests using a vector of candidate TXOs controlled by the user to solve the problem with transaction optimization.
Updated on: 2023-05-20T05:07:00.297966+00:00