📅 Original date posted:2021-06-13
📝 Original message:On Fri, 11 Jun 2021 at 07:45, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi Lloyd,
>
> Thanks for this tx mutation proposal extending the scope of fee-bumping
> techniques. IIUC, the <output_index> 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 ?
>
Right.
> 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
>
Yes but we can fix this (see below).
* 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 ?
>
Yes. You could use OP_LESSTHAN to make sure the value being deducted by the
watchtower is not above a threshold.
> Further, I think tx mutation scheme can be achieved in another way, with
> SIGHASH_ANYAMOUNT. A contract participant tapscript will be the following :
>
> <contract_key> <finalizing_alice_key>
>
> Where <contract_signature> 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].
>
Yes, that's also a way to do it. I was trying to preserve the original
external key signature in my attempt but this is probably not necessary. L2
protocols could just exchange two signatures instead. One optimistic one on
the external key and one pessimistic SIGHASH_ANYAMOUNT one on the
<contract_key>.
> 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 ?
>
Hmmm well I was hoping that you wouldn't need interaction ever. I can see
that my commitment TX example was too contrived because it has balance
outputs that go exclusively to one party.
Let's take a better example: A PTLC output with both timeout and success
pre-signed transactions spending from it. We must only let the person
offering the PTLC reduce the output of the timeout tx and the converse for
the success tx.
Note very carefully that if we naively apply OP_CHECKSIG_MUTATED or
SIGHASH_ANYAMOUNT with one tapleaf for each party then we risk one party
being able to lower the other party's output by doing a switcharoo on the
tapleaf after they see the signature for their counterparty's tx in the
mempool. In your example you could fix it by having a different
<contract_key> but this means we can't compress <contract_key> by just
using the taproot internal/external key.
What about this: Instead of party specific "finalizing_alice_key" or
p1-fee-bump-key as I denoted it, we just use the key of the output whose
value we are reducing. This also solves the O(log(n)) tapleaves for
OP_CHECKSIG_MUTATED approach as well -- just have one tapleaf for fee
bumping but authorize it under the key of the output we are reducing. Thus
we need something like OP_PUSH_TAPROOT_OUTPUT_KEY <output index> which
takes the taproot external key at that output (fail if not taproot) and
puts it on the stack. So to be clear you have the <output index> on the
witness stack rather than having it fixed in a particular tapleaf (as per
my original post) and then use OP_DUP to pass it to both
OP_CHECKSIG_MUTATED and OP_PUSH_TAPROOT_OUTPUT_KEY.
This makes a lot of sense as it matches the semantics of what we are trying
to achieve: allow the owner of an output (whether an individual or group)
to reduce that output's value to pay a higher fee.
Furthermore this removes all keys from the tapleaf since they are all
aliased to either the input we are spending or one of the output keys of
the tx we are spending to. This is quite a big improvement over my original
idea.
This works for lightning commit tx and for the case of a PTLC contract. It
also seems to work for the DLC funding output. I'd be interested to know if
anyone can think of a protocol where this would be inconvenient or
impossible to use as the main pre-signed tx fee bumping system.
Cheers,
LL
Le dim. 6 juin 2021 à 22:28, Lloyd Fournier <lloyd.fourn at gmail.com> a
> écrit :
>
>> 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 can
>> 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 output
>> 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 presigned
>> transactions will have to use ANYPREVOUT as in your proposal. The advantage
>> is that it does not require keeping extra inputs around to bump the fee.
>>
>> So imagine a new opcode OP_CHECKSIG_MUTATED <output index> <publickey>
>> <value> <signature>.
>> This would check that <signature> is valid against <publickey> if the
>> current transaction had the output at <output index> reduced by <value>. To
>> make this more efficient, if the public key is one byte: 0x02 it references
>> 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, <fee-bump-value>, <original-signature>)
>> OP_CHECKSIGADD(p1-fee-bump-key, <p1-fee-bump-signature>) OP_2
>> OP_NUMEQUALVERIFY
>> 2. OP_CHECKSIG_MUTATED(1, 0x02, <fee-bump-value>, <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 bump 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 for the new tx and reveals their fee bump leaf.
>> <original-signature> 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
>> accommodate 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.mediawiki
>>
>> Cheers,
>>
>> LL
>>
>>
>>
>> On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev <
>> bitcoin-dev at 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-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 for a while in
>>> the Bitcoin ecosystem. However, its usage in contract protocols with
>>> distrusting counterparties raised some security issues. As mempool'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 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 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.
>>>
>>> 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
>>> transaction 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 transaction
>>> 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, 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.
>>>
>>> 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. 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 under
>>> 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 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 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 chain,
>>> 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 relied
>>> 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 bumping
>>> input and outgoing output can be attached to the aggregated root. Batching
>>> perf: 1 input/1 output per aggregation.
>>>
>>> ## Fee-Bumping Mempool Flexibility
>>>
>>> CPFP: In the context of multi-party protocols, one of your
>>> counterparties 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 contract participants.
>>>
>>> Input-based: The root of the chain of transaction is the package's
>>> oldest 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 real
>>> 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 of
>>> concurrent broadcast/rebroadcast frequencies.
>>>
>>> Thoughts ?
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.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=252960.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, leading
>>> to a redundant relay of the latter.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210613/065d7cbf/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-07 22:54:29
in reply to nevent1q…eq35
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-07 22:54:29Event JSON
{
"id": "90b0f5960fdcb1c8bfa60937f8ff38a57e73258d2dd581d57d3734fce612d6cb",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686178469,
"kind": 1,
"tags": [
[
"e",
"1359d1037bcc333641858d12ecffe27a5d9f5a125da659af5141f32fc40d20c9",
"",
"root"
],
[
"e",
"3b4c5d51989ce2a7faf38c76f517f806ab9a2df79c46cb5b4bea0c3f5d1ba9a4",
"",
"reply"
],
[
"p",
"0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2"
]
],
"content": "📅 Original date posted:2021-06-13\n📝 Original message:On Fri, 11 Jun 2021 at 07:45, Antoine Riard \u003cantoine.riard at gmail.com\u003e wrote:\n\n\u003e Hi Lloyd,\n\u003e\n\u003e Thanks for this tx mutation proposal extending the scope of fee-bumping\n\u003e techniques. IIUC, the \u003coutput_index\u003e serves as a pointer to increase the\n\u003e output amount by value to recover the recompute the transaction hash\n\u003e against which the original signature is valid ?\n\u003e\n\nRight.\n\n\n\u003e Let's do a quick analysis of this scheme.\n\u003e * onchain footprint : one tapleaf per contract participant, with O(log n)\n\u003e increase of witness size, also one output per contract participant\n\u003e\n\nYes but we can fix this (see below).\n\n* tx-relay bandwidth rebroadcast : assuming aforementioned in-place mempool\n\u003e substitution policy, the mutated transaction\n\u003e\n* batching : fee-bumping value is extract from contract transaction itself,\n\u003e so O(n) per contract\n\u003e * mempool flexibility : the mutated transaction\n\u003e * watchtower key management : to enable outsourcing, the mutating key must\n\u003e be shared, in theory enabling contract value siphoning to miner fees ?\n\u003e\n\nYes. You could use OP_LESSTHAN to make sure the value being deducted by the\nwatchtower is not above a threshold.\n\n\n\u003e Further, I think tx mutation scheme can be achieved in another way, with\n\u003e SIGHASH_ANYAMOUNT. A contract participant tapscript will be the following :\n\u003e\n\u003e \u003ccontract_key\u003e \u003cfinalizing_alice_key\u003e\n\u003e\n\u003e Where \u003ccontract_signature\u003e is committed with SIGHASH_ANYAMOUNT, blanking\n\u003e nValue of one or more outputs. That way, the fee-to-contract-value\n\u003e distribution can be unilaterally finalized at a later time through the\n\u003e finalizing key [0].\n\u003e\n\nYes, that's also a way to do it. I was trying to preserve the original\nexternal key signature in my attempt but this is probably not necessary. L2\nprotocols could just exchange two signatures instead. One optimistic one on\nthe external key and one pessimistic SIGHASH_ANYAMOUNT one on the\n\u003ccontract_key\u003e.\n\n\n\u003e Note, I think that the tx mutation proposal relies on interactivity in the\n\u003e worst-case scenario where a counterparty wants to increase its fee-bumping\n\u003e output from the contract balance. This interactivity may lure a\n\u003e counterparty to alway lock the worst-case fee-bumping reserve in the\n\u003e output. I believe anchor output enables more \"real-time\" fee-bumping\n\u003e reserve adjustment ?\n\u003e\n\nHmmm well I was hoping that you wouldn't need interaction ever. I can see\nthat my commitment TX example was too contrived because it has balance\noutputs that go exclusively to one party.\nLet's take a better example: A PTLC output with both timeout and success\npre-signed transactions spending from it. We must only let the person\noffering the PTLC reduce the output of the timeout tx and the converse for\nthe success tx.\nNote very carefully that if we naively apply OP_CHECKSIG_MUTATED or\nSIGHASH_ANYAMOUNT with one tapleaf for each party then we risk one party\nbeing able to lower the other party's output by doing a switcharoo on the\ntapleaf after they see the signature for their counterparty's tx in the\nmempool. In your example you could fix it by having a different\n\u003ccontract_key\u003e but this means we can't compress \u003ccontract_key\u003e by just\nusing the taproot internal/external key.\n\nWhat about this: Instead of party specific \"finalizing_alice_key\" or\np1-fee-bump-key as I denoted it, we just use the key of the output whose\nvalue we are reducing. This also solves the O(log(n)) tapleaves for\nOP_CHECKSIG_MUTATED approach as well -- just have one tapleaf for fee\nbumping but authorize it under the key of the output we are reducing. Thus\nwe need something like OP_PUSH_TAPROOT_OUTPUT_KEY \u003coutput index\u003e which\ntakes the taproot external key at that output (fail if not taproot) and\nputs it on the stack. So to be clear you have the \u003coutput index\u003e on the\nwitness stack rather than having it fixed in a particular tapleaf (as per\nmy original post) and then use OP_DUP to pass it to both\nOP_CHECKSIG_MUTATED and OP_PUSH_TAPROOT_OUTPUT_KEY.\nThis makes a lot of sense as it matches the semantics of what we are trying\nto achieve: allow the owner of an output (whether an individual or group)\nto reduce that output's value to pay a higher fee.\nFurthermore this removes all keys from the tapleaf since they are all\naliased to either the input we are spending or one of the output keys of\nthe tx we are spending to. This is quite a big improvement over my original\nidea.\n\nThis works for lightning commit tx and for the case of a PTLC contract. It\nalso seems to work for the DLC funding output. I'd be interested to know if\nanyone can think of a protocol where this would be inconvenient or\nimpossible to use as the main pre-signed tx fee bumping system.\n\nCheers,\n\nLL\n\nLe dim. 6 juin 2021 à 22:28, Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Hi Antione,\n\u003e\u003e\n\u003e\u003e Thanks for bringing up this important topic. I think there might be\n\u003e\u003e another class of solutions over input based, CPFP and sponsorship. I'll\n\u003e\u003e call them tx mutation schemes. The idea is that you can set a key that can\n\u003e\u003e increase the fee by lowering a particular output after the tx is signed\n\u003e\u003e without invalidating the signature. The premise is that anytime you need to\n\u003e\u003e bump the fee of a transaction you must necessarily have funds in an output\n\u003e\u003e that are going to you and therefore you can sacrifice some of them to\n\u003e\u003e increase the fee. This is obviously destructive to txids so child presigned\n\u003e\u003e transactions will have to use ANYPREVOUT as in your proposal. The advantage\n\u003e\u003e is that it does not require keeping extra inputs around to bump the fee.\n\u003e\u003e\n\u003e\u003e So imagine a new opcode OP_CHECKSIG_MUTATED \u003coutput index\u003e \u003cpublickey\u003e\n\u003e\u003e \u003cvalue\u003e \u003csignature\u003e.\n\u003e\u003e This would check that \u003csignature\u003e is valid against \u003cpublickey\u003e if the\n\u003e\u003e current transaction had the output at \u003coutput index\u003e reduced by \u003cvalue\u003e. To\n\u003e\u003e make this more efficient, if the public key is one byte: 0x02 it references\n\u003e\u003e the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to\n\u003e\u003e internal key[1]).\n\u003e\u003e Now for our protocol we want both parties (p1 and p2) to be able to fee\n\u003e\u003e bump a commitment transaction. They use MuSig to sign the commitment tx\n\u003e\u003e under the external key with a decent fee for the current conditions. But in\n\u003e\u003e case it proves insufficient they have added the following two leaves to\n\u003e\u003e their key in the funding output as a backup so that p1 and p2 can\n\u003e\u003e unilaterally bump the fee of anything they sign spending from the funding\n\u003e\u003e output:\n\u003e\u003e\n\u003e\u003e 1. OP_CHECKSIG_MUTATED(0, 0x02, \u003cfee-bump-value\u003e, \u003coriginal-signature\u003e)\n\u003e\u003e OP_CHECKSIGADD(p1-fee-bump-key, \u003cp1-fee-bump-signature\u003e) OP_2\n\u003e\u003e OP_NUMEQUALVERIFY\n\u003e\u003e 2. OP_CHECKSIG_MUTATED(1, 0x02, \u003cfee-bump-value\u003e, \u003coriginal-signature\u003e)\n\u003e\u003e OP_CHECKSIGADD(p2-fee-bump-key, \u003cp2-fee-bump-signature\u003e) OP_2\n\u003e\u003e OP_NUMEQUALVERIFY\n\u003e\u003e\n\u003e\u003e where \u003c...\u003e indicates the thing comes from the witness stack.\n\u003e\u003e So to bump the fee of the commit tx after it has been signed either party\n\u003e\u003e takes the \u003coriginal-signature\u003e and adds a signature under their\n\u003e\u003e fee-bump-key for the new tx and reveals their fee bump leaf.\n\u003e\u003e \u003coriginal-signature\u003e is checked against the old transaction while the fee\n\u003e\u003e bumped transaction is checked against the fee bump key.\n\u003e\u003e\n\u003e\u003e I know I have left out how to change mempool eviction rules to\n\u003e\u003e accommodate this kind of fee bumping without DoS or pinning attacks but\n\u003e\u003e hopefully I have demonstrated that this class of solutions also exists.\n\u003e\u003e\n\u003e\u003e [1]\n\u003e\u003e https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e\n\u003e\u003e LL\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\n\u003e\u003e\u003e This post is pursuing a wider discussion around better fee-bumping\n\u003e\u003e\u003e strategies for second-layer protocols. It draws out a comparison between\n\u003e\u003e\u003e input-based and CPFP fee-bumping techniques, and their apparent trade-offs\n\u003e\u003e\u003e in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching\n\u003e\u003e\u003e opportunity and mempool flexibility.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thanks to Darosior for reviews, ideas and discussions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Child-Pay-For-Parent\n\u003e\u003e\u003e\n\u003e\u003e\u003e CPFP is a mature fee-bumping technique, known and used for a while in\n\u003e\u003e\u003e the Bitcoin ecosystem. However, its usage in contract protocols with\n\u003e\u003e\u003e distrusting counterparties raised some security issues. As mempool's chain\n\u003e\u003e\u003e of unconfirmed transactions are limited in size, if any output is spendable\n\u003e\u003e\u003e by any contract participant, it can be leveraged as a pinning vector to\n\u003e\u003e\u003e downgrade odds of transaction confirmation [0].\n\u003e\u003e\u003e\n\u003e\u003e\u003e That said, contract transactions interested to be protected under the\n\u003e\u003e\u003e carve-out logic require to add a new output for any contract participant,\n\u003e\u003e\u003e even if ultimately only one of them serves as an anchor to attach a CPFP.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Input-Based\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think input-based fee-bumping has been less studied as fee-bumping\n\u003e\u003e\u003e primitive for L2s [1]. One variant of input-based fee-bumping usable today\n\u003e\u003e\u003e is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability\n\u003e\u003e\u003e flags. If the transaction is the latest stage of the contract, a bumping\n\u003e\u003e\u003e input can be attached just-in-time, thus increasing the feerate of the\n\u003e\u003e\u003e whole package.\n\u003e\u003e\u003e\n\u003e\u003e\u003e However, as of today, input-based fee-bumping doesn't work to bump first\n\u003e\u003e\u003e stages of contract transactions as it's destructive of the txid, and as\n\u003e\u003e\u003e such breaks chain of pre-signed transactions. A first improvement would be\n\u003e\u003e\u003e the deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new\n\u003e\u003e\u003e malleability flag allows a transaction to be signed without reference to\n\u003e\u003e\u003e any specific previous output. That way, spent transactions can be\n\u003e\u003e\u003e fee-bumped without altering validity of the chain of transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Even assuming SIGHASH_ANYPREVOUT, if the first stage contract\n\u003e\u003e\u003e transaction includes multiple outputs (e.g the LN's commitment tx has\n\u003e\u003e\u003e multiple HTLC outputs), SIGHASH_SINGLE can't be used and the fee-bumping\n\u003e\u003e\u003e input value might be wasted. This edge can be smoothed by broadcasting a\n\u003e\u003e\u003e preliminary fan-out transaction with a set of outputs providing a range of\n\u003e\u003e\u003e feerate points for the bumped transaction.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This overhead could be smoothed even further in the future with more\n\u003e\u003e\u003e advanced sighash malleability flags like SIGHASH_IOMAP, allowing\n\u003e\u003e\u003e transaction signers to commit to a map of inputs/outputs [2]. In the\n\u003e\u003e\u003e context of input-based, the overflowed fee value could be redirected to an\n\u003e\u003e\u003e outgoing output.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Onchain Footprint\n\u003e\u003e\u003e\n\u003e\u003e\u003e CPFP: One anchor output per participant must be included in the\n\u003e\u003e\u003e commitment transaction. To this anchor must be attached a child transaction\n\u003e\u003e\u003e with 2 inputs (one for the commitment, one for the bumping utxo) and 1\n\u003e\u003e\u003e output. Onchain footprint: 2 inputs + 3 outputs.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based (today): If the bumping utxo is offering an adequate feerate\n\u003e\u003e\u003e point in function of network mempools congestion at time of broadcast, only\n\u003e\u003e\u003e 1 input. If a preliminary fan-out transaction to adjust feerate point must\n\u003e\u003e\u003e be broadcasted first, 1 input and 2 outputs more must be accounted for.\n\u003e\u003e\u003e Onchain footprint: 2 inputs + 3 outputs.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping\n\u003e\u003e\u003e utxo's value is wide enough to cover the worst-case of mempools congestion,\n\u003e\u003e\u003e the bumped transaction can be attached 1 input and 1 output. Onchain\n\u003e\u003e\u003e footprint: 1 input + 1 output.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Tx-Relay Bandwidth Rebroadcast\n\u003e\u003e\u003e\n\u003e\u003e\u003e CPFP: In the context of multi-party protocols, we should assume bounded\n\u003e\u003e\u003e rationality of the participants w.r.t to an unconfirmed spend of the\n\u003e\u003e\u003e contract utxo across network mempools. Under this assumption, the bumped\n\u003e\u003e\u003e transaction might have been replaced by a concurrent state. To guarantee\n\u003e\u003e\u003e efficiency of the CPFP the whole chain of transactions should be\n\u003e\u003e\u003e rebroadcast, perhaps wasting bandwidth consumption for a still-identical\n\u003e\u003e\u003e bumped transaction [3]. Rebroadcast footprint: the whole chain of\n\u003e\u003e\u003e transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based (today): In case of rebroadcast, the fee-bumping input is\n\u003e\u003e\u003e attached to the root of the chain of transactions and as such breaks the\n\u003e\u003e\u003e chain validity in itself. Beyond the rebroadcast of the updated root under\n\u003e\u003e\u003e replacement policy, the remaining transactions must be updated and\n\u003e\u003e\u003e rebroadcast. Rebroadcast footprint: the whole chain of transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast,\n\u003e\u003e\u003e the fee-bumping is attached to the root of the chain of transactions but it\n\u003e\u003e\u003e doesn't break the chain validity in itself. Assuming a future mempool\n\u003e\u003e\u003e acceptance logic to authorize in-place substitution, the rest of the chain\n\u003e\u003e\u003e could be preserved. Rebroadcast footprint: the root of the chain of\n\u003e\u003e\u003e transactions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Fee-Bumping Batching\n\u003e\u003e\u003e\n\u003e\u003e\u003e CPFP: In the context of multi-party protocols, in optimistic scenarios,\n\u003e\u003e\u003e we can assume aggregation of multiple chains of transactions. For e.g, a LN\n\u003e\u003e\u003e operator is desirous to non-cooperatively close multiple channels at the\n\u003e\u003e\u003e same time and would like to combine their fee-bumping. With CPFP, one\n\u003e\u003e\u003e anchor output and one bumping input must be consumed per aggregated chain,\n\u003e\u003e\u003e even if the child transaction fields can be shared. Batching perf: 1\n\u003e\u003e\u003e input/1 output per aggregated chain.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based (today): Unless the contract allows interactivity, multiple\n\u003e\u003e\u003e chains of transactions cannot be aggregated. One bumping input must be\n\u003e\u003e\u003e attached per chain, though if a preliminary fan-out transaction is relied\n\u003e\u003e\u003e on to offer multiple feerate points, transaction fields can be shared.\n\u003e\u003e\u003e Batching perf: 1 input/1 output per aggregated chain.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of\n\u003e\u003e\u003e transactions might be aggregated together *non-interactively*. One bumping\n\u003e\u003e\u003e input and outgoing output can be attached to the aggregated root. Batching\n\u003e\u003e\u003e perf: 1 input/1 output per aggregation.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Fee-Bumping Mempool Flexibility\n\u003e\u003e\u003e\n\u003e\u003e\u003e CPFP: In the context of multi-party protocols, one of your\n\u003e\u003e\u003e counterparties might build a branch of transactions from one of the root\n\u003e\u003e\u003e outputs thus saturating the in-mempool package limits. To avoid these\n\u003e\u003e\u003e shenanigans, LN channels are relying on the carve-out mechanism. Though,\n\u003e\u003e\u003e the carve-out mechanism includes its own limitation and doesn't scale\n\u003e\u003e\u003e beyond 2 contract participants.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Input-based: The root of the chain of transaction is the package's\n\u003e\u003e\u003e oldest ancestor, so package limits don't restrain its acceptance and it\n\u003e\u003e\u003e works whatever the number of contract participants.\n\u003e\u003e\u003e\n\u003e\u003e\u003e To conclude, this post scores 2 fee-bumping primitives for multi-party\n\u003e\u003e\u003e protocols on a range of factors. It hopes to unravel the ground for a real\n\u003e\u003e\u003e feerate performance framework of second-layers protocols .\n\u003e\u003e\u003e\n\u003e\u003e\u003e Beyond that, few points can be highlighted a) future soft forks allow\n\u003e\u003e\u003e significant onchain footprint savings, especially in case of batching, b)\n\u003e\u003e\u003e future package relay bandwidth efficiency should account for rebroadcast\n\u003e\u003e\u003e frequency of CPFPing multi-party protocols. On this latter point one\n\u003e\u003e\u003e follow-up might be to evaluate differing package relay *announcement*\n\u003e\u003e\u003e schemes in function of odds of non-cooperative protocol broadcast/odds of\n\u003e\u003e\u003e concurrent broadcast/rebroadcast frequencies.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thoughts ?\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Antoine\n\u003e\u003e\u003e\n\u003e\u003e\u003e [0]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html\n\u003e\u003e\u003e [1] Beyond the revault architecture :\n\u003e\u003e\u003e https://github.com/revault/practical-revault/blob/master/revault.pdf\n\u003e\u003e\u003e [2] Already proposed a while back :\n\u003e\u003e\u003e https://bitcointalk.org/index.php?topic=252960.0\n\u003e\u003e\u003e [3] In theory, an already-relayed transaction shouldn't pass Core's\n\u003e\u003e\u003e `filterInventoryKnown`. In practice, if the transaction is announced as\n\u003e\u003e\u003e part of a package_id, the child might have changed, not the parent, leading\n\u003e\u003e\u003e to a redundant relay of the latter.\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210613/065d7cbf/attachment-0001.html\u003e",
"sig": "b304ef780cb36fe351a452e6aa191157d6d5be9f310573ae0e5def1f5d61d8c7b96021028f761c1125b79e8b33f0ab7fae4de3a6c42f921e67672e34ef6ed749"
}