|
| 1 | +{:.post-meta} |
| 2 | +*by [CardCoins][]* |
| 3 | + |
| 4 | +_"Additive batching" is a scheme in which additional outputs are |
| 5 | +added to unconfirmed transactions in the mempool. This field report outlines |
| 6 | +efforts [CardCoins][] has taken in introducing a reorg- and DoS-safe implementation |
| 7 | +of such a scheme in its customer payout workflow._ |
| 8 | + |
| 9 | +[Replace By Fee][topic rbf] (RBF, BIP125) and [batching][payment batching] are |
| 10 | +two important tools for any enterprises directly interacting with Bitcoin's |
| 11 | +mempool. Fees go up, fees go down, but the business must always fight for fee efficiency. |
| 12 | + |
| 13 | +Each tool, while powerful, has its own complexities and nuances. For example, |
| 14 | +batching customer withdrawals may save on fees for the enterprise, but will likely make |
| 15 | +[child pays for parent][topic cpfp] (CPFP) uneconomical for a customer who wishes to speed up the transaction. |
| 16 | +Similarly, RBF is useful for an enterprise who takes a fee-underbidding strategy |
| 17 | +(their initial transaction broadcast starts at a low fee, and is slowly bid |
| 18 | +upwards), but it exposes their customers to [potential confusion][rbf blog] as their |
| 19 | +withdrawal transaction updates in their wallet. It would also be messy for the |
| 20 | +customer to spend from this transaction while it remains unconfirmed, as the |
| 21 | +enterprise will have to pay for this child spend when attempting to replace |
| 22 | +the parent. Even worse, the enterprise may have a withdrawal [pinned][pinning] by another |
| 23 | +service which received the customer's withdrawal. |
| 24 | + |
| 25 | +When combining these two tools, a service provider unlocks new functionality but |
| 26 | +is similarly exposed to novel forms of complexity. In the base case, combining |
| 27 | +RBF and a single, static batch carries a simple combination of the complexities |
| 28 | +that RBF and batching carry discretely. However, when you combine RBF and |
| 29 | +"additive batching," emergent edge cases and dangerous failure scenarios present |
| 30 | +themselves. |
| 31 | + |
| 32 | +In additive RBF batching, the service provider introduces new outputs (and |
| 33 | +confirmed inputs) to a transaction in the mempool to incorporate new customer |
| 34 | +withdrawals into an unconfirmed transaction. This enables the service provider |
| 35 | +to give |
| 36 | +users the experience of an instantaneous withdrawal while still retaining much |
| 37 | +of the fee savings from doing large batches of customer withdrawals at once. As |
| 38 | +each customer requests a withdrawal, an output is added to the transaction in |
| 39 | +the mempool. This transaction continues to be updated until it confirms or |
| 40 | +reaches some other local optimum. |
| 41 | + |
| 42 | +There are many strategies to this type of additive RBF batching. At [CardCoins][] we |
| 43 | +took a safety-first approach to our implementation (with the help of [Matthew |
| 44 | +Zipkin][]), the details of which we described in a blog post, [RBF |
| 45 | +Batching at CardCoins: Diving into the Mempool's Dark Reorg Forest][cardcoins |
| 46 | +rbf blog]. |
| 47 | + |
| 48 | +{% include references.md %} |
| 49 | +[CardCoins]: https://www.cardcoins.co/ |
| 50 | +[payment batching]: /en/payment-batching/ |
| 51 | +[rbf blog]: /en/rbf-in-the-wild/#some-usability-examples |
| 52 | +[pinning]: /en/topics/transaction-pinning/ |
| 53 | +[Matthew Zipkin]: https://twitter.com/MatthewZipkin |
| 54 | +[cardcoins rbf blog]: https://blog.cardcoins.co/rbf-batching-at-cardcoins-diving-into-the-mempool-s-dark-reorg-forest |
0 commit comments