Author: email at yancy.lol 2022-11-04 10:28:17
Published on: 2022-11-04T10:28:17+00:00
The email thread between Peter Todd and Yancy on the bitcoin-dev mailing list discusses the implications of a "full-rbf" policy for transaction replacement. According to Peter, there is nothing special about a full-rbf transaction other than the fact that it replaces a previously broadcast transaction that didn't signal replacement. The interplay between mempool policies may not be trivial, but adding a full-rbf config flag is particularly trivial. Yancy raises a question about whether non-rbf nodes will relay full-rbf transactions and vice versa. Peter explains that there are nodes that signal full-rbf and preferentially peer to each other, ensuring good transaction propagation. However, there is no consensus over the mempool, so in certain cases, non-full-rbf nodes will broadcast replacements when they didn't receive the "first" transaction first.There is no discussion of benefits other than breaking zeroconf business practices, but accommodating both types of transaction policy seems worth it to some network participants. Nonetheless, adding more configuration options always increases code complexity, and with that, there is likely more unforeseen bugs. Overall, the email thread provides insights into the technicalities of implementing a full-rbf policy for transaction replacement.
Updated on: 2023-06-16T02:20:41.903937+00:00