Improving RBF Policy



Summary:

The post discusses various issues related to DoS protection, iterative/additive batching, and the use of verifiable delay function in rate-limiting transaction replacement. The first point suggests limiting the amount of work required for replacing a transaction rather than focusing on the number of times a transaction can be replaced or the volume of transactions that can be evicted during a replacement. The second point highlights the benefits of iterative batching, where an organization puts a transaction in the mempool that pays to N users and updates it to N+2, N+2...N+M payouts as they see additional requests for payouts. However, due to the feerate rule, if businesses go from N to N+1, they need to pay 1 sat/byte over the whole transaction, leading to an increase in fees quadratically. One solution to this issue could be to allow relaying "txdiffs" that only require re-relay of signatures + new/modified outputs, not the entire transaction. The third point suggests using a verifiable delay function (VDF) over each of the N COutpoints individually to rate-limit transaction replacement, eliminating the VDF period depending on the feerate increase. A VDF is like proof-of-work that doesn't parallelize, so no matter how many computers you have, it would take about the same amount of time.


Updated on: 2023-06-15T16:00:36.742914+00:00