{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-05-27\n📝 Original message:Hi,\n\nThis post is pursuing a wider discussion around better fee-bumping\nstrategies for second-layer protocols. It draws out a comparison between\ninput-based and CPFP fee-bumping techniques, and their apparent trade-offs\nin terms of onchain footprint, tx-relay bandwidth rebroadcast, batching\nopportunity and mempool flexibility.\n\nThanks to Darosior for reviews, ideas and discussions.\n\n## Child-Pay-For-Parent\n\nCPFP is a mature fee-bumping technique, known and used for a while in the\nBitcoin ecosystem. However, its usage in contract protocols with\ndistrusting counterparties raised some security issues. As mempool's chain\nof unconfirmed transactions are limited in size, if any output is spendable\nby any contract participant, it can be leveraged as a pinning vector to\ndowngrade odds of transaction confirmation [0].\n\nThat said, contract transactions interested to be protected under the\ncarve-out logic require to add a new output for any contract participant,\neven if ultimately only one of them serves as an anchor to attach a CPFP.\n\n## Input-Based\n\nI think input-based fee-bumping has been less studied as fee-bumping\nprimitive for L2s [1]. One variant of input-based fee-bumping usable today\nis the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability\nflags. If the transaction is the latest stage of the contract, a bumping\ninput can be attached just-in-time, thus increasing the feerate of the\nwhole package.\n\nHowever, as of today, input-based fee-bumping doesn't work to bump first\nstages of contract transactions as it's destructive of the txid, and as\nsuch breaks chain of pre-signed transactions. A first improvement would be\nthe deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new\nmalleability flag allows a transaction to be signed without reference to\nany specific previous output. That way,  spent transactions can be\nfee-bumped without altering validity of the chain of transactions.\n\nEven assuming SIGHASH_ANYPREVOUT, if the first stage contract transaction\nincludes multiple outputs (e.g the LN's commitment tx has multiple HTLC\noutputs), SIGHASH_SINGLE can't be used and the fee-bumping input value\nmight be wasted. This edge can be smoothed by broadcasting a preliminary\nfan-out transaction with a set of outputs providing a range of feerate\npoints for the bumped transaction.\n\nThis overhead could be smoothed even further in the future with more\nadvanced sighash malleability flags like SIGHASH_IOMAP, allowing\ntransaction signers to commit to a map of inputs/outputs [2]. In the\ncontext of input-based, the overflowed fee value could be redirected to an\noutgoing output.\n\n## Onchain Footprint\n\nCPFP: One anchor output per participant must be included in the commitment\ntransaction. To this anchor must be attached a child transaction with 2\ninputs (one for the commitment, one for the bumping utxo) and 1 output.\nOnchain footprint: 2 inputs + 3 outputs.\n\nInput-based (today): If the bumping utxo is offering an adequate feerate\npoint in function of network mempools congestion at time of broadcast, only\n1 input. If a preliminary fan-out transaction to adjust feerate point must\nbe broadcasted first, 1 input and 2 outputs more must be accounted for.\nOnchain footprint: 2 inputs + 3 outputs.\n\nInput-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping\nutxo's value is wide enough to cover the worst-case of mempools congestion,\nthe bumped transaction can be attached 1 input and 1 output. Onchain\nfootprint: 1 input + 1 output.\n\n## Tx-Relay Bandwidth Rebroadcast\n\nCPFP: In the context of multi-party protocols, we should assume bounded\nrationality of the participants w.r.t to an unconfirmed spend of the\ncontract utxo across network mempools. Under this assumption, the bumped\ntransaction might have been replaced by a concurrent state. To guarantee\nefficiency of the CPFP the whole chain of transactions should be\nrebroadcast, perhaps wasting bandwidth consumption for a still-identical\nbumped transaction [3]. Rebroadcast footprint: the whole chain of\ntransactions.\n\nInput-based (today): In case of rebroadcast, the fee-bumping input is\nattached to the root of the chain of transactions and as such breaks the\nchain validity in itself. Beyond the rebroadcast of the updated root under\nreplacement policy, the remaining transactions must be updated and\nrebroadcast. Rebroadcast footprint: the whole chain of transactions.\n\nInput-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast, the\nfee-bumping is attached to the root of the chain of transactions but it\ndoesn't break the chain validity in itself. Assuming a future mempool\nacceptance logic to authorize in-place substitution, the rest of the chain\ncould be preserved. Rebroadcast footprint: the root of the chain of\ntransactions.\n\n## Fee-Bumping Batching\n\nCPFP: In the context of multi-party protocols, in optimistic scenarios, we\ncan assume aggregation of multiple chains of transactions. For e.g, a LN\noperator is desirous to non-cooperatively close multiple channels at the\nsame time and would like to combine their fee-bumping. With CPFP, one\nanchor output and one bumping input must be consumed per aggregated chain,\neven if the child transaction fields can be shared. Batching perf: 1\ninput/1 output per aggregated chain.\n\nInput-based (today): Unless the contract allows interactivity, multiple\nchains of transactions cannot be aggregated. One bumping input must be\nattached per chain, though if a preliminary fan-out transaction is relied\non to offer multiple feerate points, transaction fields can be shared.\nBatching perf: 1 input/1 output per aggregated chain.\n\nInput-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of\ntransactions might be aggregated together *non-interactively*. One bumping\ninput and outgoing output can be attached to the aggregated root. Batching\nperf: 1 input/1 output per aggregation.\n\n## Fee-Bumping Mempool Flexibility\n\nCPFP: In the context of multi-party protocols, one of your counterparties\nmight build a branch of transactions from one of the root outputs thus\nsaturating the in-mempool package limits. To avoid these shenanigans, LN\nchannels are relying on the carve-out mechanism. Though, the carve-out\nmechanism includes its own limitation and doesn't scale beyond 2 contract\nparticipants.\n\nInput-based: The root of the chain of transaction is the package's oldest\nancestor, so package limits don't restrain its acceptance and it works\nwhatever the number of contract participants.\n\nTo conclude, this post scores 2 fee-bumping primitives for multi-party\nprotocols on a range of factors. It hopes to unravel the ground for a real\nfeerate performance framework of second-layers protocols .\n\nBeyond that, few points can be highlighted a) future soft forks allow\nsignificant onchain footprint savings, especially in case of batching, b)\nfuture package relay bandwidth efficiency should account for rebroadcast\nfrequency of CPFPing multi-party protocols. On this latter point one\nfollow-up might be to evaluate differing package relay *announcement*\nschemes in function of odds of non-cooperative protocol broadcast/odds of\nconcurrent broadcast/rebroadcast frequencies.\n\nThoughts ?\n\nCheers,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html\n[1] Beyond the revault architecture :\nhttps://github.com/revault/practical-revault/blob/master/revault.pdf\n[2] Already proposed a while back :\nhttps://bitcointalk.org/index.php?topic=252960.0\n[3] In theory, an already-relayed transaction shouldn't pass Core's\n`filterInventoryKnown`. In practice, if the transaction is announced as\npart of a package_id, the child might have changed, not the parent, leading\nto a redundant relay of the latter.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210527/73916240/attachment.html\u003e"}