V3 transaction policy for anti-pinning

V3 transaction policy for anti-pinning

Original Postby instagibbs

Posted on: January 22, 2024 13:34 UTC

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.