V3 transaction policy for anti-pinning

Jan 22 - Jan 22, 2024

  • The discussion focuses on the design considerations for a transaction protocol within the constraints of version 3 (v3).

The suggested approach is to structure the protocol in such a manner that parent transactions have only one output that can be spent immediately. This configuration ensures that any Child Pays for Parent (CPFP) transaction would naturally conflict with each other, thereby triggering the Replace-By-Fee (RBF) rules. However, if the goal is to enable conflicts with parent transactions, this single-output requirement may not be necessary.

For instance, an exchange conducting batched payouts might create several versions of withdrawal transactions at varying fee rates. Such an exchange could confidently execute replacements up to an overhead of 1 kilobyte virtual size (kvB) if customers initiate sweeps. It is mentioned that it is not feasible to lock customer addresses using 1 CheckSequenceVerify (CSV), implying that this method cannot be used to control spending from those addresses.

Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback