From: darosior <darosior@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Date: Thu, 27 May 2021 21:45:35 +0000 [thread overview]
Message-ID: <sfryINjjAWF5hDSvohEhqCl2nBlllag5nA9tiPleUb1HyjmBcb6Y6v7VwIfaHVXfyiXAHGAgQfbwNsIz8dvckOSjV-zxaq7DckjHStYPJZU=@protonmail.com> (raw)
In-Reply-To: <CALZpt+FvLb=N5Qygs+dPmh1o9QCwXj8RoznF5n47opOq7CG_0g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]
Hi,
> ## Input-Based
>
> I think input-based fee-bumping has been less studied as fee-bumping primitive for L2s [1]. One variant of input-based fee-bumping usable today is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags. If the transaction is the latest stage of the contract, a bumping input can be attached just-in-time, thus increasing the feerate of the whole package.
Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault,
which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them entirely).
> Input-based (today): If the bumping utxo is offering an adequate feerate point in function of network mempools congestion at time of broadcast, only 1 input. If a preliminary fan-out transaction to adjust feerate point must be broadcasted first, 1 input and 2 outputs more must be accounted for. Onchain footprint: 2 inputs + 3 outputs.
I believe that it's better to broadcast a single fan-out transaction creating your entire UTXO pool in advance. You could create one coin per contract you are watching which value would be
used to bump your transaction feerate from the presigned one to -say- the average feerate over the past month, and then have smaller coins that you could attach to any transaction to bump
by a certain threshold (say, 10sat/vbyte). You would create as many small coin as your reserve algorithm tells you (which could be "i need to be able, worst case, to close all my contracts
with the worst historical feerate." or (fractional reserve version) "i need to be able, worst case, to close 10% of my contracts at the average feerate of the past year, the remaining ones sorry
for my loss"). [1]
This method is both much more optimal (though you need to sometimes incur the cost of many small additional inputs) and also makes sure that your feebump does not depend on the confirmation
of a first stage transaction (as you can only RBF with new inputs if they are confirmed).
> Input-based (today): In case of rebroadcast, the fee-bumping input is attached to the root of the chain of transactions and as such breaks the chain validity in itself. Beyond the rebroadcast of the updated root under replacement policy, the remaining transactions must be updated and rebroadcast. Rebroadcast footprint: the whole chain of transactions.
Why not just attaching it at the tail of the chain? Bumping the last child with additional input would effectively be a CPFP for the entire chain in this case.
Thanks for starting this discussion :)
Antoine
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
[1] Credits to Jacob Swambo, who came up with the single fan-out transaction and with whom i'm discussing how to practically apply these ideas to Revault.
[-- Attachment #2: Type: text/html, Size: 3619 bytes --]
next prev parent reply other threads:[~2021-05-27 21:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 20:14 Antoine Riard
2021-05-27 21:45 ` darosior [this message]
2021-05-28 4:13 ` Antoine Riard
2021-05-28 22:25 ` darosior
2021-06-10 21:16 ` Antoine Riard
2021-06-10 13:18 ` darosior
2021-06-07 2:27 ` Lloyd Fournier
2021-06-10 21:45 ` Antoine Riard
2021-06-10 22:47 ` darosior
2021-06-13 5:56 ` Lloyd Fournier
2021-06-13 14:16 ` Jeremy
2021-06-14 17:18 ` Antoine Riard
2021-06-14 16:46 ` Antoine Riard
2021-06-15 0:59 ` Lloyd Fournier
2021-06-15 3:08 ` Lloyd Fournier
2021-07-08 11:17 ` Anthony Towns
2021-07-09 13:19 ` Antoine Riard
2021-07-10 1:47 ` Anthony Towns
2021-07-12 0:02 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='sfryINjjAWF5hDSvohEhqCl2nBlllag5nA9tiPleUb1HyjmBcb6Y6v7VwIfaHVXfyiXAHGAgQfbwNsIz8dvckOSjV-zxaq7DckjHStYPJZU=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox