Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 755A5C000B for ; Thu, 10 Jun 2021 21:45:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 64BFD607C3 for ; Thu, 10 Jun 2021 21:45:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYIOudwZSJLH for ; Thu, 10 Jun 2021 21:45:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by smtp3.osuosl.org (Postfix) with ESMTPS id F2F3F6070E for ; Thu, 10 Jun 2021 21:45:17 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id m41-20020a05600c3b29b02901b9e5d74f02so4207651wms.3 for ; Thu, 10 Jun 2021 14:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eXrWMM/Tk8FNcpd9+iVYncrIoV4cbrioURTkbwEqZ7Q=; b=eJHsEHtK/gcyVJ8RirKBY2W1ydJbio+UqyI4Az++DWwoZvF5oyLR5tIJToofAN2xTb KmvCh5a/vD5RJfGxg2RudGpB43kLpNAV8IAYtk1iFQYtSwwSGADBJfBkse029RoG7x/s S22m0rRCwxcatCBmAVR9Yefo18f3etheM4h1vpndqq+p4zulnM7+Vdkq7tyQu4mt7toj Q8gtFKCsWmqzsMrC3Zqv4CyfL9ey6x4MPMI2IZhwWbrHR9OY85v1YFxEYT+LKQsZ/VLV i+2pFmHhJU+vhGpWsOVaq88qrf9eO4dDK53xumpHNY0lBmzqvlc8RRYOioI7vYSCaAku oI9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eXrWMM/Tk8FNcpd9+iVYncrIoV4cbrioURTkbwEqZ7Q=; b=WmnqJwwxRJ2b1it8e3RJFEFfzHxjTQ+IWCvDw5Te1L6FqOWz2aBuX5Gw+q9sbJ/Sx9 Axnx4L4kTBEluI43qa1yqZqQWHdMuafJyLHxnOqalyW7G1vnmvJnBJzNnhLEmB5aDJLZ aq5NU3Kk7xpKX07BoRwl6yiHWGXK05uBdQ5PO+Fal5uQPGBZWNVxmiRG4hHLIwKn9N1f ynrYOCsKwI4Y0anJQM3UrMdJ/wEeP0r+vlpQVWTJuZYaO+1f0wzCiHjamVk/F/E4fEmP 04d1R1iA9Ac+VVxas9/GMqr/VtwqTHxFMu+Gno2qH5TgK1rFtSQT0tn90JSGdBFWyK3J +neQ== X-Gm-Message-State: AOAM532uZvTgd1Jnj6aA34WweoI5vTMqs2Jp0/BYdxqsbx+P0ZHRzb+k w6nyRQDYqpg6lkcQYebYCyXTnXEMtpSoQ7vGeaE= X-Google-Smtp-Source: ABdhPJz1mt2iAV6XUDXRWTJvoTRBRcP7hTycqToa9v12/sdh6DEX9E28wksIPrknfhKAlXybatz7AIMqwl1WS7Sjcus= X-Received: by 2002:a1c:1d14:: with SMTP id d20mr17228800wmd.177.1623361516064; Thu, 10 Jun 2021 14:45:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 10 Jun 2021 17:45:04 -0400 Message-ID: To: Lloyd Fournier Content-Type: multipart/alternative; boundary="00000000000081d15b05c4704ead" X-Mailman-Approved-At: Thu, 10 Jun 2021 22:08:13 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 21:45:20 -0000 --00000000000081d15b05c4704ead Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Lloyd, Thanks for this tx mutation proposal extending the scope of fee-bumping techniques. IIUC, the serves as a pointer to increase the output amount by value to recover the recompute the transaction hash against which the original signature is valid ? Let's do a quick analysis of this scheme. * onchain footprint : one tapleaf per contract participant, with O(log n) increase of witness size, also one output per contract participant * tx-relay bandwidth rebroadcast : assuming aforementioned in-place mempool substitution policy, the mutated transaction * batching : fee-bumping value is extract from contract transaction itself, so O(n) per contract * mempool flexibility : the mutated transaction * watchtower key management : to enable outsourcing, the mutating key must be shared, in theory enabling contract value siphoning to miner fees ? Further, I think tx mutation scheme can be achieved in another way, with SIGHASH_ANYAMOUNT. A contract participant tapscript will be the following : Where is committed with SIGHASH_ANYAMOUNT, blanking nValue of one or more outputs. That way, the fee-to-contract-value distribution can be unilaterally finalized at a later time through the finalizing key [0]. Note, I think that the tx mutation proposal relies on interactivity in the worst-case scenario where a counterparty wants to increase its fee-bumping output from the contract balance. This interactivity may lure a counterparty to alway lock the worst-case fee-bumping reserve in the output. I believe anchor output enables more "real-time" fee-bumping reserve adjustment ? Cheers, Antoine [0] Incautious sighash alleability is unsafe. Be careful, otherwise kitties will perish by the thousands : https://github.com/revault/practical-revault/pull/83 Le dim. 6 juin 2021 =C3=A0 22:28, Lloyd Fournier a =C3=A9crit : > Hi Antione, > > Thanks for bringing up this important topic. I think there might be > another class of solutions over input based, CPFP and sponsorship. I'll > call them tx mutation schemes. The idea is that you can set a key that ca= n > increase the fee by lowering a particular output after the tx is signed > without invalidating the signature. The premise is that anytime you need = to > bump the fee of a transaction you must necessarily have funds in an outpu= t > that are going to you and therefore you can sacrifice some of them to > increase the fee. This is obviously destructive to txids so child presign= ed > transactions will have to use ANYPREVOUT as in your proposal. The advanta= ge > is that it does not require keeping extra inputs around to bump the fee. > > So imagine a new opcode OP_CHECKSIG_MUTATED > . > This would check that is valid against if the > current transaction had the output at reduced by . = To > make this more efficient, if the public key is one byte: 0x02 it referenc= es > the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer = to > internal key[1]). > Now for our protocol we want both parties (p1 and p2) to be able to fee > bump a commitment transaction. They use MuSig to sign the commitment tx > under the external key with a decent fee for the current conditions. But = in > case it proves insufficient they have added the following two leaves to > their key in the funding output as a backup so that p1 and p2 can > unilaterally bump the fee of anything they sign spending from the funding > output: > > 1. OP_CHECKSIG_MUTATED(0, 0x02, , ) > OP_CHECKSIGADD(p1-fee-bump-key, ) OP_2 > OP_NUMEQUALVERIFY > 2. OP_CHECKSIG_MUTATED(1, 0x02, , ) > OP_CHECKSIGADD(p2-fee-bump-key, ) OP_2 > OP_NUMEQUALVERIFY > > where <...> indicates the thing comes from the witness stack. > So to bump the fee of the commit tx after it has been signed either party > takes the and adds a signature under their > fee-bump-key for the new tx and reveals their fee bump leaf. > is checked against the old transaction while the fee > bumped transaction is checked against the fee bump key. > > I know I have left out how to change mempool eviction rules to accommodat= e > this kind of fee bumping without DoS or pinning attacks but hopefully I > have demonstrated that this class of solutions also exists. > > [1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawik= i > > Cheers, > > LL > > > > On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi, >> >> This post is pursuing a wider discussion around better fee-bumping >> strategies for second-layer protocols. It draws out a comparison between >> input-based and CPFP fee-bumping techniques, and their apparent trade-of= fs >> in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching >> opportunity and mempool flexibility. >> >> Thanks to Darosior for reviews, ideas and discussions. >> >> ## Child-Pay-For-Parent >> >> CPFP is a mature fee-bumping technique, known and used for a while in th= e >> Bitcoin ecosystem. However, its usage in contract protocols with >> distrusting counterparties raised some security issues. As mempool's cha= in >> of unconfirmed transactions are limited in size, if any output is spenda= ble >> by any contract participant, it can be leveraged as a pinning vector to >> downgrade odds of transaction confirmation [0]. >> >> That said, contract transactions interested to be protected under the >> carve-out logic require to add a new output for any contract participant= , >> even if ultimately only one of them serves as an anchor to attach a CPFP= . >> >> ## 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 tod= ay >> 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. >> >> However, as of today, input-based fee-bumping doesn't work to bump first >> stages of contract transactions as it's destructive of the txid, and as >> such breaks chain of pre-signed transactions. A first improvement would = be >> the deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new >> malleability flag allows a transaction to be signed without reference to >> any specific previous output. That way, spent transactions can be >> fee-bumped without altering validity of the chain of transactions. >> >> Even assuming SIGHASH_ANYPREVOUT, if the first stage contract transactio= n >> includes multiple outputs (e.g the LN's commitment tx has multiple HTLC >> outputs), SIGHASH_SINGLE can't be used and the fee-bumping input value >> might be wasted. This edge can be smoothed by broadcasting a preliminary >> fan-out transaction with a set of outputs providing a range of feerate >> points for the bumped transaction. >> >> This overhead could be smoothed even further in the future with more >> advanced sighash malleability flags like SIGHASH_IOMAP, allowing >> transaction signers to commit to a map of inputs/outputs [2]. In the >> context of input-based, the overflowed fee value could be redirected to = an >> outgoing output. >> >> ## Onchain Footprint >> >> CPFP: One anchor output per participant must be included in the >> commitment transaction. To this anchor must be attached a child transact= ion >> with 2 inputs (one for the commitment, one for the bumping utxo) and 1 >> output. Onchain footprint: 2 inputs + 3 outputs. >> >> Input-based (today): If the bumping utxo is offering an adequate feerate >> point in function of network mempools congestion at time of broadcast, o= nly >> 1 input. If a preliminary fan-out transaction to adjust feerate point mu= st >> be broadcasted first, 1 input and 2 outputs more must be accounted for. >> Onchain footprint: 2 inputs + 3 outputs. >> >> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping >> utxo's value is wide enough to cover the worst-case of mempools congesti= on, >> the bumped transaction can be attached 1 input and 1 output. Onchain >> footprint: 1 input + 1 output. >> >> ## Tx-Relay Bandwidth Rebroadcast >> >> CPFP: In the context of multi-party protocols, we should assume bounded >> rationality of the participants w.r.t to an unconfirmed spend of the >> contract utxo across network mempools. Under this assumption, the bumped >> transaction might have been replaced by a concurrent state. To guarantee >> efficiency of the CPFP the whole chain of transactions should be >> rebroadcast, perhaps wasting bandwidth consumption for a still-identical >> bumped transaction [3]. Rebroadcast footprint: the whole chain of >> transactions. >> >> 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 und= er >> replacement policy, the remaining transactions must be updated and >> rebroadcast. Rebroadcast footprint: the whole chain of transactions. >> >> Input-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast, >> the fee-bumping is attached to the root of the chain of transactions but= it >> doesn't break the chain validity in itself. Assuming a future mempool >> acceptance logic to authorize in-place substitution, the rest of the cha= in >> could be preserved. Rebroadcast footprint: the root of the chain of >> transactions. >> >> ## Fee-Bumping Batching >> >> CPFP: In the context of multi-party protocols, in optimistic scenarios, >> we can assume aggregation of multiple chains of transactions. For e.g, a= LN >> operator is desirous to non-cooperatively close multiple channels at the >> same time and would like to combine their fee-bumping. With CPFP, one >> anchor output and one bumping input must be consumed per aggregated chai= n, >> even if the child transaction fields can be shared. Batching perf: 1 >> input/1 output per aggregated chain. >> >> Input-based (today): Unless the contract allows interactivity, multiple >> chains of transactions cannot be aggregated. One bumping input must be >> attached per chain, though if a preliminary fan-out transaction is relie= d >> on to offer multiple feerate points, transaction fields can be shared. >> Batching perf: 1 input/1 output per aggregated chain. >> >> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of >> transactions might be aggregated together *non-interactively*. One bumpi= ng >> input and outgoing output can be attached to the aggregated root. Batchi= ng >> perf: 1 input/1 output per aggregation. >> >> ## Fee-Bumping Mempool Flexibility >> >> CPFP: In the context of multi-party protocols, one of your counterpartie= s >> might build a branch of transactions from one of the root outputs thus >> saturating the in-mempool package limits. To avoid these shenanigans, LN >> channels are relying on the carve-out mechanism. Though, the carve-out >> mechanism includes its own limitation and doesn't scale beyond 2 contrac= t >> participants. >> >> Input-based: The root of the chain of transaction is the package's oldes= t >> ancestor, so package limits don't restrain its acceptance and it works >> whatever the number of contract participants. >> >> To conclude, this post scores 2 fee-bumping primitives for multi-party >> protocols on a range of factors. It hopes to unravel the ground for a re= al >> feerate performance framework of second-layers protocols . >> >> Beyond that, few points can be highlighted a) future soft forks allow >> significant onchain footprint savings, especially in case of batching, b= ) >> future package relay bandwidth efficiency should account for rebroadcast >> frequency of CPFPing multi-party protocols. On this latter point one >> follow-up might be to evaluate differing package relay *announcement* >> schemes in function of odds of non-cooperative protocol broadcast/odds o= f >> concurrent broadcast/rebroadcast frequencies. >> >> Thoughts ? >> >> Cheers, >> Antoine >> >> [0] >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/01= 6518.html >> [1] Beyond the revault architecture : >> https://github.com/revault/practical-revault/blob/master/revault.pdf >> [2] Already proposed a while back : >> https://bitcointalk.org/index.php?topic=3D252960.0 >> [3] In theory, an already-relayed transaction shouldn't pass Core's >> `filterInventoryKnown`. In practice, if the transaction is announced as >> part of a package_id, the child might have changed, not the parent, lead= ing >> to a redundant relay of the latter. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --00000000000081d15b05c4704ead Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Lloyd,

Thanks for this tx mutation proposal exte= nding the scope of fee-bumping techniques. IIUC, the <output_index> s= erves as a pointer to increase the output amount by value to recover the re= compute the transaction hash against which the original signature is valid = ?

Let's do a quick analysis of this scheme.
* onchain footpri= nt : one tapleaf per contract participant, with O(log n) increase of witnes= s size, also one output per contract participant
* tx-relay bandwidth re= broadcast : assuming aforementioned in-place mempool substitution policy, t= he mutated transaction
* batching : fee-bumping value is extract from co= ntract transaction itself, so O(n) per contract
* mempool flexibility : = the mutated transaction
* watchtower key management : to enable outsourc= ing, the mutating key must be shared, in theory enabling contract value sip= honing to miner fees ?

Further, I think tx mutation scheme can be ac= hieved in another way, with SIGHASH_ANYAMOUNT. A contract participant tapsc= ript will be the following :

<contract_key> <finalizing_ali= ce_key>

Where <contract_signature> is committed with SIGHAS= H_ANYAMOUNT, blanking nValue of one or more outputs. That way, the fee-to-c= ontract-value distribution can be unilaterally finalized at a later time th= rough the finalizing key [0].

Note, I think that the tx mutation pro= posal relies on interactivity in the worst-case scenario where a counterpar= ty wants to increase its fee-bumping output from the contract balance. This= interactivity may lure a counterparty to alway lock the worst-case fee-bum= ping reserve in the output. I believe anchor output enables more "real= -time" fee-bumping reserve adjustment ?

Cheers,
Antoine
<= br>[0] Incautious sighash alleability is unsafe. Be careful, otherwise kitt= ies will perish by the thousands :
https://github.com/revault/practical-revault/pu= ll/83

Le=C2=A0dim. 6 juin 2021 =C3=A0=C2=A022:28, Lloyd Fournier <= ;lloyd.fourn@gmail.com> a = =C3=A9crit=C2=A0:
Hi Antione,

Thanks for bri= nging up this important topic. I think there might be another class of solu= tions over input based, CPFP and sponsorship. I'll call them tx mutatio= n schemes. The idea is that you can set a key that can increase the fee by = lowering a particular output after the tx is signed without invalidating th= e signature.=20 The premise is that anytime you need to bump the fee of a transaction you = must necessarily have funds in an output that are going to you and therefor= e you can sacrifice some of them to increase the fee. This is obviously des= tructive to txids so child presigned transactions will have to use ANYPREVO= UT as in your proposal. The advantage is that it does not require keeping e= xtra inputs around to bump the fee.

So imagine= a new opcode OP_CHECKSIG_MUTATED <output index>=20 <publickey> <value> <signature>.
This would ch= eck that <signature> is valid against <publickey> if the curren= t transaction had the output at <output index> reduced by <value&g= t;. To make this more efficient, if the public key is one byte: 0x02 it ref= erences the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to = refer to internal key[1]).
Now for our protocol we want both = parties (p1 and p2) to be able to fee bump a commitment transaction. They u= se MuSig to sign the commitment tx under the external key with a decent fee= for the current conditions. But in case it proves insufficient they have a= dded the following two leaves to their key in the funding output as a backu= p so that p1 and p2 can unilaterally bump the fee of anything they sign spe= nding from the funding output:

1. OP_CHECKSIG_= MUTATED(0, 0x02, <fee-bump-value>,=20 <original-signature>) OP_CHECKSIGADD(p1-fee-bump-key, <p1-fee-bump= -signature>)=C2=A0 OP_2 OP_NUMEQUALVERIFY
2.=20 OP_CHECKSIG_MUTATED(1, 0x02, <fee-bump-value>,=20 <original-signature>) OP_CHECKSIGADD(p2-fee-bump-key, <p2-fee-bump= -signature>) OP_2 OP_NUMEQUALVERIFY

where <.= ..> indicates the thing comes from the witness stack.
So to bu= mp the fee of the commit tx after it has been signed either party takes the= <original-signature> and adds a signature under their fee-bump-key f= or the new tx and reveals their fee bump leaf. <original-signature> i= s checked against the old transaction while the fee bumped transaction is c= hecked against the fee bump key.

I know I have left out how to change mempool eviction rules to accommodate = this kind of fee bumping without DoS or pinning attacks but hopefully I hav= e demonstrated that this class of solutions also exists.

=

Cheers,

LL


On Fri, 2= 8 May 2021 at 07:13, Antoine Riard via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
Hi,

This post is pursuing a wider = discussion around better fee-bumping strategies for second-layer protocols.= It draws out a comparison between input-based and CPFP fee-bumping techniq= ues, and their apparent trade-offs in terms of onchain footprint, tx-relay = bandwidth rebroadcast, batching opportunity and mempool flexibility.
Thanks to Darosior for reviews, ideas and discussions.

## Child-Pay= -For-Parent

CPFP is a mature fee-bumping technique, known and used f= or a while in the Bitcoin ecosystem. However, its usage in contract protoco= ls with distrusting counterparties raised some security issues. As mempool&= #39;s chain of unconfirmed transactions are limited in size, if any output = is spendable by any contract participant, it can be leveraged as a pinning = vector to downgrade odds of transaction confirmation [0].

That said,= contract transactions interested to be protected under the carve-out logic= require to add a new output for any contract participant, even if ultimate= ly only one of them serves as an anchor to attach a CPFP.

## Input-B= ased

I think input-based fee-bumping has been less studied as fee-bu= mping primitive for L2s [1]. One variant of input-based fee-bumping usable = today is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleabili= ty 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 who= le package.

However, as of today, input-based fee-bumping doesn'= t work to bump first stages of contract transactions as it's destructiv= e of the txid, and as such breaks chain of pre-signed transactions. A first= improvement would be the deployment of the SIGHASH_ANYPREVOUT softfork pro= posal. This new malleability flag allows a transaction to be signed without= reference to any specific previous output. That way,=C2=A0 spent transacti= ons can be fee-bumped without altering validity of the chain of transaction= s.

Even assuming SIGHASH_ANYPREVOUT, if the first stage contract tra= nsaction includes multiple outputs (e.g the LN's commitment tx has mult= iple HTLC outputs), SIGHASH_SINGLE can't be used and the fee-bumping in= put value might be wasted. This edge can be smoothed by broadcasting a prel= iminary fan-out transaction with a set of outputs providing a range of feer= ate points for the bumped transaction.

This overhead could be smooth= ed even further in the future with more advanced sighash malleability flags= like SIGHASH_IOMAP, allowing transaction signers to commit to a map of inp= uts/outputs [2]. In the context of input-based, the overflowed fee value co= uld be redirected to an outgoing output.

## Onchain Footprint
CPFP: One anchor output per participant must be included in the commitment= transaction. To this anchor must be attached a child transaction with 2 in= puts (one for the commitment, one for the bumping utxo) and 1 output. Oncha= in footprint: 2 inputs + 3 outputs.

Input-based (today): If the bump= ing utxo is offering an adequate feerate point in function of network mempo= ols 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 outp= uts.

Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the = bumping utxo's value is wide enough to cover the worst-case of mempools= congestion, the bumped transaction can be attached 1 input and 1 output. O= nchain footprint: 1 input + 1 output.

## Tx-Relay Bandwidth Rebroadc= ast

CPFP: In the context of multi-party protocols, we should assume = bounded rationality of the participants w.r.t to an unconfirmed spend of th= e contract utxo across network mempools. Under this assumption, the bumped = transaction might have been replaced by a concurrent state. To guarantee ef= ficiency of the CPFP the whole chain of transactions should be rebroadcast,= perhaps wasting bandwidth consumption for a still-identical bumped transac= tion [3]. Rebroadcast footprint: the whole chain of transactions.

In= put-based (today): In case of rebroadcast, the fee-bumping input is attache= d to the root of the chain of transactions and as such breaks the chain val= idity in itself. Beyond the rebroadcast of the updated root under replaceme= nt policy, the remaining transactions must be updated and rebroadcast. Rebr= oadcast footprint: the whole chain of transactions.

Input-based(SIGH= ASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast, the fee-bumping is a= ttached to the root of the chain of transactions but it doesn't break t= he chain validity in itself. Assuming a future mempool acceptance logic to = authorize in-place substitution, the rest of the chain could be preserved. = Rebroadcast footprint: the root of the chain of transactions.

## Fee= -Bumping Batching

CPFP: In the context of multi-party protocols, in = optimistic scenarios, we can assume aggregation of multiple chains of trans= actions. For e.g, a LN operator is desirous to non-cooperatively close mult= iple channels at the same time and would like to combine their fee-bumping.= With CPFP, one anchor output and one bumping input must be consumed per ag= gregated chain, even if the child transaction fields can be shared. Batchin= g perf: 1 input/1 output per aggregated chain.

Input-based (today): = Unless the contract allows interactivity, multiple chains of transactions c= annot be aggregated. One bumping input must be attached per chain, though i= f a preliminary fan-out transaction is relied on to offer multiple feerate = points, transaction fields can be shared. Batching perf: 1 input/1 output p= er aggregated chain.

Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP):= Multiple chains of transactions might be aggregated together *non-interact= ively*. One bumping input and outgoing output can be attached to the aggreg= ated root. Batching perf: 1 input/1 output per aggregation.

## Fee-B= umping Mempool Flexibility

CPFP: In the context of multi-party proto= cols, one of your counterparties might build a branch of transactions from = one of the root outputs thus saturating the in-mempool package limits. To a= void these shenanigans, LN channels are relying on the carve-out mechanism.= Though, the carve-out mechanism includes its own limitation and doesn'= t scale beyond 2 contract participants.

Input-based: The root of the= chain of transaction is the package's oldest ancestor, so package limi= ts don't restrain its acceptance and it works whatever the number of co= ntract participants.

To conclude, this post scores 2 fee-bumping pri= mitives for multi-party protocols on a range of factors. It hopes to unrave= l the ground for a real feerate performance framework of second-layers prot= ocols .

Beyond that, few points can be highlighted a) future soft fo= rks allow significant onchain footprint savings, especially in case of batc= hing, b) future package relay bandwidth efficiency should account for rebro= adcast frequency of CPFPing multi-party protocols. On this latter point one= follow-up might be to evaluate differing package relay *announcement* sche= mes in function of odds of non-cooperative protocol broadcast/odds of concu= rrent broadcast/rebroadcast frequencies.

Thoughts ?

Cheers,Antoine

[0] https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
[1]= Beyond the revault architecture : https://github.c= om/revault/practical-revault/blob/master/revault.pdf
[2] Already pro= posed a while back : https://bitcointalk.org/index.php?topic=3D252960= .0
[3] In theory, an already-relayed transaction shouldn't pass = Core's `filterInventoryKnown`. In practice, if the transaction is annou= nced as part of a package_id, the child might have changed, not the parent,= leading to a redundant relay of the latter.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000081d15b05c4704ead--