diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2022-02-11 00:26:53 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-11 05:27:10 +0000 |
| commit | ca9ccf5000b2c1e467f96667f1f141c56e55d67a (patch) | |
| tree | 8c45b34839395fcea774a88c77b73cb493f61851 | |
| parent | a79c9447b38bc035d27b949e1af39f2ffd5225ad (diff) | |
| download | pi-bitcoindev-ca9ccf5000b2c1e467f96667f1f141c56e55d67a.tar.gz pi-bitcoindev-ca9ccf5000b2c1e467f96667f1f141c56e55d67a.zip | |
Re: [bitcoin-dev] Thoughts on fee bumping
| -rw-r--r-- | 75/a3334a80c663892353ec4b373febfcf331b6af | 703 |
1 files changed, 703 insertions, 0 deletions
diff --git a/75/a3334a80c663892353ec4b373febfcf331b6af b/75/a3334a80c663892353ec4b373febfcf331b6af new file mode 100644 index 000000000..3343530fb --- /dev/null +++ b/75/a3334a80c663892353ec4b373febfcf331b6af @@ -0,0 +1,703 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 00049C000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 05:27:10 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id C61AB607B4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 05:27:10 +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 HmvkyuZO7nvL + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 05:27:08 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com + [IPv6:2607:f8b0:4864:20::b2c]) + by smtp3.osuosl.org (Postfix) with ESMTPS id 721426079D + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Feb 2022 05:27:08 +0000 (UTC) +Received: by mail-yb1-xb2c.google.com with SMTP id y129so21772367ybe.7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 10 Feb 2022 21:27:08 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=Ootu4AaqPP8i3DeFJ3b5dkifAuMLgzvP+Fm8RiA9Crk=; + b=Tf5RFVAscsi/H972KgCBBQV4dDt2U9pFU0G6YCdWr20QuDEIJAt6IGoXa87BBkevEF + He735J/utOsIQ1T8qQTg/LTvx1tMvamYdHe7g4ZtHXLQlaMLM0rmJ5O7+whxhlPDBOaa + DL5fD6ojDt0epOfnzX2FLorpvgZLiiE/6M5UKNKq2STgg8cg49DoSoy/bmFI0cct0Dz7 + QANfLQlNASHbFSeduZPWLIbst5vf3c71OZYnO5zsAd87RjX5L2+F4zRI8nMgKJ4oc6rT + XhiSqZVPDhAnr2u6+atVHCv5J1Ndl+MnbYTaOHnrHdVmdC7xa6X+7++zxdIUAO5UN5A5 + 9cCg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to; + bh=Ootu4AaqPP8i3DeFJ3b5dkifAuMLgzvP+Fm8RiA9Crk=; + b=wo8w6jdZjWC4wWkSjRFSbDrhD+7bSQaZWa+R5BHJSX9dZh0VEYEh71xTkGvu5pye73 + diq2b/R3nu1YXbM2kCj/U80mlP9POZliNzROcYOKtf/8+4naVIuufN36Dp5HjBbdsCu6 + s0HOktz1DYYDpXswkd2R01ZlA1xewjWBSbWmQrV+LUx0lQku5AgmvAWeJTwZplltMUbz + 7IxePWcH76DX218arx17/slfS0Gjq3qibXIM7REM1mt4wBdldFkbbxx0MVyrXKDvj5DT + gDDDfcqBL4G48jYZd2ghq3uyBbqm6Z/V4WzErc5WlulmKlT8pITChYjwaPs17iE+d83a + lvJg== +X-Gm-Message-State: AOAM533rQnilxjm/2Oeuw3b8zqFkciZiQI82eM+gC0SpETlvAOlFokMk + TicqFE0Ec+L87lfS9xUzi8Js1JE04J5hzTELsQg= +X-Google-Smtp-Source: ABdhPJxSwS1pFWLO7cAjP5Y80vek+cTIePLsqLIrZJWSCe7yeakjeHJwo58658FoErrE/fe5DrkEBGJVYUhFefqe0jA= +X-Received: by 2002:a81:b61b:: with SMTP id u27mr127913ywh.450.1644557226115; + Thu, 10 Feb 2022 21:27:06 -0800 (PST) +MIME-Version: 1.0 +References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com> +In-Reply-To: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Fri, 11 Feb 2022 00:26:53 -0500 +Message-ID: <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com> +To: "James O'Beirne" <james.obeirne@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000046865005d7b75109" +X-Mailman-Approved-At: Fri, 11 Feb 2022 09:12:53 +0000 +Subject: Re: [bitcoin-dev] Thoughts on fee bumping +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 11 Feb 2022 05:27:11 -0000 + +--00000000000046865005d7b75109 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi James, + +I fully agree on the need to reframe the conversation around +mempools/fee-bumping/L2s though please see my following comments, it's far +from simple! + +> Layering on special cases, more carve-outs, and X and Y percentage +> thresholds is going to make reasoning about the mempool harder than it +> already is. + +I think that's true with a lot of (all ?) pieces of software, there is a +trend towards complexification. As new Bitcoin use-cases such as LN or +vaults appear, it's not surprising to see the base layer upper interfaces +changing to support the requirements. Same with kernels, at beginning, you +can have a basic memory support with paging/memory rights/kernel allocators +then as you start to support more platforms/devices you might have to +support swaps/DMA/VMs management... + +That we should keep the complexity reasonably sane to enable human +auditing, and maybe learn from the failures of systems engineering, that's +something to muse on. + +> The countervailing force here ends up being spam prevention (a la +min-relay-fee) +> to prevent someone from consuming bandwidth and mempool space with a long +series of +> infinitesimal fee-bumps. + +I think here we should dissociate a) long-chain of transactions and b) +high-number of repeated fee-bumps. + +For a) _if_ SIGHASH_ANYPREVOUT is deployed and Eltoo adopted as a primary +update mechanism for stateful L2s, one might envision long-chain of update +transactions servicing as a new pinning vector, where all the chain +elements are offering a compelling feerate/fees. It might be solvable with +smarter mempool logic sorting the elements from the best offer to the lower +ones, though that issue would need more serious investigation. + +For b) if we bound with a hard constant the number of RBF attempts, we +decrease the fault-tolerance of L2 transaction issuers. Some of them might +connect directly to the miners because they're offering higher number of +incentive-compatible RBF attempts than vanilla full-nodes. That might +provoke a more or slow centralization of the transaction relay topology... + +> Instead of prompting a rebroadcast of the original transaction for +> replacement, which contains a lot of data not new to the network, it +> makes more sense to broadcast the "diff" which is the additive +> contribution towards some txn's feerate. + +In a distributed system such as the Bitcoin p2p network, you might have +transaction A and transaction B broadcast at the same time and your peer +topology might fluctuate between original send and broadcast +of the diff, you don't know who's seen what... You might inefficiently +announce diff A on top of B and diff B on top A. We might leverage set +reconciliation there a la Erlay, though likely with increased round-trips. + +> It's probably uncontroversial at this +> point to say that even RBF itself is kind of a hack - a special +> sequence number should not be necessary for post-broadcast contribution +> toward feerate. + +I think here we should dissociate the replace-by-fee mechanism itself from +the replacement signaling one. To have a functional RBF, you don't need +signaling at all, just consider all received transactions as replaceable. +The replacement signaling one has been historically motivated to protect +the applications relying on zero-confs (with all the past polemics about +the well-foundedness of such claims on other nodes' policy). + +> In a sane design, no structural foresight - and certainly no wasted +>bytes in the form of unused anchor outputs - should be needed in order +>to add to a miner's reward for confirming a given transaction. + +Have you heard about SIGHASH_GROUP [0] ? It would move away from the +transaction to enable arbitrary bundles of input/outputs. You will have +your pre-signed bundle of inputs/outputs enforcing your LN/vaults/L2 and +then at broadcast time, you can attach an input/output. I think it would +answer your structural foresight. + +> One of the practical downsides of CPFP that I haven't seen discussed in +> this conversation is that it requires the transaction to pre-specify the +> keys needed to sign for fee bumps. This is problematic if you're, for +> example, using a vault structure that makes use of pre-signed +> transactions. + +It's true it requires to pre-specify the fee-bumping key. Though note the +fee-bumping key can be fully separated from the "vaults"/"channels" set of +main keys and hosted on replicated infrastructure such as watchtowers. + +> The interface for end-users is very straightforward: if you want to bump +> fees, specify a transaction that contributes incrementally to package +> feerate for some txid. Simple. + +As a L2 transaction issuer you can't be sure the transaction you wish to +point to is already in the mempool, or have not been replaced by your +counterparty spending the same shared-utxo, either competitively or +maliciously. So as a measure of caution, you should broadcast sponsor + +target transactions in the same package, thus cancelling the bandwidth +saving (I think). + +> This theoretical concession seems preferable to heaping more rules onto +an already labyrinthine mempool policy that is difficult for both +implementers and users to reason about practically and conceptually. + +I don't think a sponsor is a silver-bullet to solve all the L2-related +mempool issues. It won't solve the most concerning pinning attacks, as I +think the bottleneck is replace-by-fee. Neither solve the issues encumbered +by the L2s by the dust limit. + +> If a soft-fork is the cost of cleaning up this essential process, +> consideration should be given to paying it as a one-time cost. This +> topic merits a separate post, but consider that in the 5 years leading +> up to the 2017 SegWit drama, we averaged about a soft-fork a year. +> Uncontroversial, "safe" changes to the consensus protocol shouldn't be +> out of the question when significant practical benefit is plain to see. + +Zooming out, I think we're still early in solving those L2 issues, as the +most major second-layers are still in a design or deployment phase. We +might freeze our transaction propagation interface, and get short for some +of the most interesting ones like channel factories and payment pools. +Further, I think we're not entirely sure how the mining ecosystem is going +to behave once the reward is drained and their incentives towards L2 +confirmations. + +Still, if we think we have a correct picture of the fee-bumping/mempools +issues and are sufficiently confident with the stability of L2 designs, I +think the next step would be to come with quantitative modelling of each +resources consumed by fee-bumping (CPU validation/bandwidth/signing +interactivity for the L2s...) and then score the "next-gen" fee-bumping +primitives. + +> I'm not out to propose soft-forks lightly, but the current complexity +> in fee management feels untenable, and as evidenced by all the +> discussion lately, fees are an increasingly crucial part of the system. + +Overall, I think that's a relevant discussion to have ecosystem-wise. +Though there is a lot of context and I don't think there is a simple way +forward. Maybe better to stick to an evolutionary development process with +those mempool/fee-bumping issues. We might envision two-or-three steps +ahead though unlikely more. + +Cheers, +Antoine + +[0] SIGHASH_GROUP described here +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.htm= +l +and roughly roughly implemented here : +https://github.com/ariard/bitcoin/pull/1 + +Le jeu. 10 f=C3=A9vr. 2022 =C3=A0 14:48, James O'Beirne via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : + +> There's been much talk about fee-bumping lately, and for good reason - +> dynamic fee management is going to be a central part of bitcoin use as +> the mempool fills up (lord willing) and right now fee-bumping is +> fraught with difficulty and pinning peril. +> +> Gloria's recent post on the topic[0] was very lucid and highlights a +> lot of the current issues, as well as some proposals to improve the +> situation. +> +> As others have noted, the post was great. But throughout the course +> of reading it and the ensuing discussion, I became troubled by the +> increasing complexity of both the status quo and some of the +> proposed remedies. +> +> Layering on special cases, more carve-outs, and X and Y percentage +> thresholds is going to make reasoning about the mempool harder than it +> already is. Special consideration for "what should be in the next +> block" and/or the caching of block templates seems like an imposing +> dependency, dragging in a bunch of state and infrastructure to a +> question that should be solely limited to mempool feerate aggregates +> and the feerate of the particular txn package a wallet is concerned +> with. +> +> This is bad enough for protocol designers and Core developers, but +> making the situation any more intractable for "end-users" and wallet +> developers feels wrong. +> +> I thought it might be useful to step back and reframe. Here are a few +> aims that are motivated chiefly by the quality of end-user experience, +> constrained to obey incentive compatibility (i.e. miner reward, DoS +> avoidance). Forgive the abstract dalliance for a moment; I'll talk +> through concretes afterwards. +> +> +> # Purely additive feerate bumps should never be impossible +> +> Any user should always be able to add to the incentive to mine any +> transaction in a purely additive way. The countervailing force here +> ends up being spam prevention (a la min-relay-fee) to prevent someone +> from consuming bandwidth and mempool space with a long series of +> infinitesimal fee-bumps. +> +> A fee bump, naturally, should be given the same per-byte consideration +> as a normal Bitcoin transaction in terms of relay and block space, +> although it would be nice to come up with a more succinct +> representation. This leads to another design principle: +> +> +> # The bandwidth and chain space consumed by a fee-bump should be minimal +> +> Instead of prompting a rebroadcast of the original transaction for +> replacement, which contains a lot of data not new to the network, it +> makes more sense to broadcast the "diff" which is the additive +> contribution towards some txn's feerate. +> +> This dovetails with the idea that... +> +> +> # Special transaction structure should not be required to bump fees +> +> In an ideal design, special structural foresight would not be needed +> in order for a txn's feerate to be improved after broadcast. +> +> Anchor outputs specified solely for CPFP, which amount to many bytes of +> wasted chainspace, are a hack. It's probably uncontroversial at this +> point to say that even RBF itself is kind of a hack - a special +> sequence number should not be necessary for post-broadcast contribution +> toward feerate. Not to mention RBF's seemingly wasteful consumption of +> bandwidth due to the rebroadcast of data the network has already seen. +> +> In a sane design, no structural foresight - and certainly no wasted +> bytes in the form of unused anchor outputs - should be needed in order +> to add to a miner's reward for confirming a given transaction. +> +> Planning for fee-bumps explicitly in transaction structure also often +> winds up locking in which keys are required to bump fees, at odds +> with the idea that... +> +> +> # Feerate bumps should be able to come from anywhere +> +> One of the practical downsides of CPFP that I haven't seen discussed in +> this conversation is that it requires the transaction to pre-specify the +> keys needed to sign for fee bumps. This is problematic if you're, for +> example, using a vault structure that makes use of pre-signed +> transactions. +> +> What if the key you specified n the anchor outputs for a bunch of +> pre-signed txns is compromised? What if you'd like to be able to +> dynamically select the wallet that bumps fees? CPFP does you no favors +> here. +> +> There is of course a tension between allowing fee bumps to come from +> anywhere and the threat of pinning-like attacks. So we should venture +> to remove pinning as a possibility, in line with the first design +> principle I discuss. +> +> +> --- +> +> Coming down to earth, the "tabula rasa" thought experiment above has led +> me to favor an approach like the transaction sponsors design that Jeremy +> proposed in a prior discussion back in 2020[1]. +> +> Transaction sponsors allow feerates to be bumped after a transaction's +> broadcast, regardless of the structure of the original transaction. +> No rebroadcast (wasted bandwidth) is required for the original txn data. +> No wasted chainspace on only-maybe-used prophylactic anchor outputs. +> +> The interface for end-users is very straightforward: if you want to bump +> fees, specify a transaction that contributes incrementally to package +> feerate for some txid. Simple. +> +> In the original discussion, there were a few main objections that I noted= +: +> +> 1. In Jeremy's original proposal, only one sponsor txn per txid is +> allowed by policy. A malicious actor could execute a pinning-like +> attack by specifying an only-slightly-helpful feerate sponsor that +> then precludes other larger bumps. +> +> I think there are some ways around this shortcoming. For example: what +> if, by policy, sponsor txns had additional constraints that +> +> - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY, +> - the txn must be specified RBFable, +> - a replacement for the sponsor txn must raise the sponsor feerate, +> including ancestors (maybe this is inherent in "is RBFable," but +> I don't want to conflate absolute feerates into this). +> +> That way, there is still at most a single sponsor txn per txid in the +> mempool, but anyone can "mix in" inputs which bump the effective +> feerate of the sponsor. +> +> This may not be the exact solution we want, but I think it demonstrates +> that the sponsors design has some flexibility and merits some thinking. +> +> The second objection about sponsors was +> +> 2. (from Suhas) sponsors break the classic invariant: "once a valid +> transaction is created, it should not become invalid later on unless +> the inputs are double-spent." +> +> This doesn't seem like a huge concern to me if you consider the txid +> being sponsored as a sort of spiritual input to the sponsor. While the +> theoretical objection against broadening where one has to look in a txn +> to determine its dependencies is understandable, I don't see what the +> practical cost here is. +> +> Reorg complexity seems comparable if not identical, especially if we +> broaden sponsor rules to allow blocks to contain sponsor txns that are +> both for txids in the same block _or_ already included in the chain. +> +> This theoretical concession seems preferable to heaping more rules onto +> an already labyrinthine mempool policy that is difficult for both +> implementers and users to reason about practically and conceptually. +> +> A third objection that wasn't posed, IIRC, but almost certainly would +> be: +> +> 3. Transaction sponsors requires a soft-fork. +> +> Soft-forks are no fun, but I'll tell you what also isn't fun: being on +> the hook to model (and sometimes implement) a dizzying potpourri of +> mempool policies and special-cases. Expecting wallet implementers to +> abide by a maze of rules faithfully in order to ensure txn broadcast and +> fee management invites bugs for perpetuity and network behavior that is +> difficult to reason about a priori. Use of CPFP in the long-term also +> risks needless chain waste. +> +> If a soft-fork is the cost of cleaning up this essential process, +> consideration should be given to paying it as a one-time cost. This +> topic merits a separate post, but consider that in the 5 years leading +> up to the 2017 SegWit drama, we averaged about a soft-fork a year. +> Uncontroversial, "safe" changes to the consensus protocol shouldn't be +> out of the question when significant practical benefit is plain to see. +> +> --- +> +> I hope this message has added some framing to the discussion on fees, +> as well prompting other participants to go back and give the +> transaction sponsor proposal a serious look. The sponsors interface is +> about the simplest I can imagine for wallets, and it seems easy to +> reason about for implementers on Core and elsewhere. +> +> I'm not out to propose soft-forks lightly, but the current complexity +> in fee management feels untenable, and as evidenced by all the +> discussion lately, fees are an increasingly crucial part of the system. +> +> +> +> [0]: +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= +17.html +> [1]: +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/01= +8168.html +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000046865005d7b75109 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi James,<br><br>I fully agree on the need to reframe the = +conversation around mempools/fee-bumping/L2s though please see my following= + comments, it's far from simple!<br><br>> Layering on special cases,= + more carve-outs, and X and Y percentage<br>> thresholds is going to mak= +e reasoning about the mempool harder than it<br>> already is.<br><br>I t= +hink that's true with a lot of (all ?) pieces of software, there is a t= +rend towards complexification. As new Bitcoin use-cases such as LN or vault= +s appear, it's not surprising to see the base layer upper interfaces ch= +anging to support the requirements. Same with kernels, at beginning, you ca= +n have a basic memory support with paging/memory rights/kernel allocators t= +hen as you start to support more platforms/devices you might have to suppor= +t swaps/DMA/VMs management...<br><br>That we should keep the complexity rea= +sonably sane to enable human auditing, and maybe learn from the failures of= + systems engineering, that's something to muse on.<br><br>> The coun= +tervailing force here ends up being spam prevention (a la min-relay-fee)<br= +>> to prevent someone from consuming bandwidth and mempool space with a = +long series of<br>> infinitesimal fee-bumps.<br><br>I think here we shou= +ld dissociate a) long-chain of transactions and b) high-number of repeated = +fee-bumps.<br><br>For a) _if_ SIGHASH_ANYPREVOUT is deployed and Eltoo adop= +ted as a primary update mechanism for stateful L2s, one might envision long= +-chain of update transactions servicing as a new pinning vector, where all = +the chain elements are offering a compelling feerate/fees. It might be solv= +able with smarter mempool logic sorting the elements from the best offer to= + the lower ones, though that issue would need more serious investigation.<b= +r><br>For b) if we bound with a hard constant the number of RBF attempts, w= +e decrease the fault-tolerance of L2 transaction issuers. Some of them migh= +t connect directly to the miners because they're offering higher number= + of incentive-compatible RBF attempts than vanilla full-nodes. That might p= +rovoke a more or slow centralization of the transaction relay topology...<b= +r><br>> Instead of prompting a rebroadcast of the original transaction f= +or<br>> replacement, which contains a lot of data not new to the network= +, it<br>> makes more sense to broadcast the "diff" which is th= +e additive<br>> contribution towards some txn's feerate.<br><br>In a= + distributed system such as the Bitcoin p2p network, you might have transac= +tion A and transaction B=C2=A0 broadcast at the same time and your peer top= +ology might fluctuate between original send and broadcast<br>of the diff, y= +ou don't know who's seen what... You might inefficiently announce d= +iff A on top of B and diff B on top A. We might leverage set reconciliation= + there a la Erlay, though likely with increased round-trips.<br><br>> It= +'s probably uncontroversial at this<br>> point to say that even RBF = +itself is kind of a hack - a special<br>> sequence number should not be = +necessary for post-broadcast contribution<br>> toward feerate.<br><br>I = +think here we should dissociate the replace-by-fee mechanism itself from th= +e replacement signaling one. To have a functional RBF, you don't need s= +ignaling at all, just consider all received transactions as replaceable. Th= +e replacement signaling one has been historically motivated to protect the = +applications relying on zero-confs (with all the past polemics about the we= +ll-foundedness of such claims on other nodes' policy).<br><br>> In a= + sane design, no structural foresight - and certainly no wasted<br>>byte= +s in the form of unused anchor outputs - should be needed in order<br>>t= +o add to a miner's reward for confirming a given transaction.<br><br>Ha= +ve you heard about SIGHASH_GROUP [0] ? It would move away from the transact= +ion to enable arbitrary bundles of input/outputs. You will have your pre-si= +gned bundle of inputs/outputs enforcing your LN/vaults/L2 and then at broad= +cast time, you can attach an input/output. I think it would answer your str= +uctural foresight.<br><br>> One of the practical downsides of CPFP that = +I haven't seen discussed in<br>> this conversation is that it requir= +es the transaction to pre-specify the<br>> keys needed to sign for fee b= +umps. This is problematic if you're, for<br>> example, using a vault= + structure that makes use of pre-signed<br>> transactions.<br><br>It'= +;s true it requires to pre-specify the fee-bumping key. Though note the fee= +-bumping key can be fully separated from the "vaults"/"chann= +els" set of main keys and hosted on replicated infrastructure such as = +watchtowers.<br><br>> The interface for end-users is very straightforwar= +d: if you want to bump<br>> fees, specify a transaction that contributes= + incrementally to package<br>> feerate for some txid. Simple.<br><br>As = +a L2 transaction issuer you can't be sure the transaction you wish to p= +oint to is already in the mempool, or have not been replaced by your counte= +rparty spending the same shared-utxo, either competitively or maliciously. = +So as a measure of caution, you should broadcast sponsor + target transacti= +ons in the same package, thus cancelling the bandwidth saving (I think).<br= +><br>> This theoretical concession seems preferable to heaping more rule= +s onto<br>an already labyrinthine mempool policy that is difficult for both= +<br>implementers and users to reason about practically and conceptually.<br= +><br>I don't think a sponsor is a silver-bullet to solve all the L2-rel= +ated mempool issues. It won't solve the most concerning pinning attacks= +, as I think the bottleneck is replace-by-fee. Neither solve the issues enc= +umbered by the L2s by the dust limit.<br><br>> If a soft-fork is the cos= +t of cleaning up this essential process,<br>> consideration should be gi= +ven to paying it as a one-time cost. This<br>> topic merits a separate p= +ost, but consider that in the 5 years leading<br>> up to the 2017 SegWit= + drama, we averaged about a soft-fork a year.<br>> Uncontroversial, &quo= +t;safe" changes to the consensus protocol shouldn't be<br>> out= + of the question when significant practical benefit is plain to see.<br><br= +>Zooming out, I think we're still early in solving those L2 issues, as = +the most major second-layers are still in a design or deployment phase. We = +might freeze our transaction propagation interface, and get short for some = +of the most interesting ones like channel factories and payment pools. Furt= +her, I think we're not entirely sure how the mining ecosystem is going = +to behave once the reward is drained and their incentives towards L2 confir= +mations.<br><br>Still, if we think we have a correct picture of the fee-bum= +ping/mempools issues and are sufficiently confident with the stability of L= +2 designs, I think the next step would be to come with quantitative modelli= +ng of each resources consumed by fee-bumping (CPU validation/bandwidth/sign= +ing interactivity for the L2s...) and then score the "next-gen" f= +ee-bumping primitives.<br><br>> I'm not out to propose soft-forks li= +ghtly, but the current complexity<br>> in fee management feels untenable= +, and as evidenced by all the<br>> discussion lately, fees are an increa= +singly crucial part of the system.<br><br>Overall, I think that's a rel= +evant discussion to have ecosystem-wise. Though there is a lot of context a= +nd I don't think there is a simple way forward. Maybe better to stick t= +o an evolutionary development process with those mempool/fee-bumping issues= +. We might envision two-or-three steps ahead though unlikely more.<br><br>C= +heers,<br>Antoine<br><br>[0] SIGHASH_GROUP described here <a href=3D"https:= +//lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html">htt= +ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html</= +a><br>and roughly roughly implemented here : <a href=3D"https://github.com/= +ariard/bitcoin/pull/1">https://github.com/ariard/bitcoin/pull/1</a><br></di= +v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le= +=C2=A0jeu. 10 f=C3=A9vr. 2022 =C3=A0=C2=A014:48, James O'Beirne via bit= +coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= +in-dev@lists.linuxfoundation.org</a>> a =C3=A9crit=C2=A0:<br></div><bloc= +kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= +1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>There= +9;s been much talk about fee-bumping lately, and for good reason -<br>dynam= +ic fee management is going to be a central part of bitcoin use as<br>the me= +mpool fills up (lord willing) and right now fee-bumping is<br>fraught with = +difficulty and pinning peril.<br><br>Gloria's recent post on the topic[= +0] was very lucid and highlights a<br>lot of the current issues, as well as= + some proposals to improve the<br>situation.<br><br>As others have noted, t= +he post was great. But throughout the course<br>of reading it and the ensui= +ng discussion, I became troubled by the<br>increasing complexity of both th= +e status quo and some of the <br></div><div>proposed remedies. <br></div><d= +iv><br>Layering on special cases, more carve-outs, and X and Y percentage<b= +r>thresholds is going to make reasoning about the mempool harder than it<br= +>already is. Special consideration for "what should be in the next<br>= +block" and/or the caching of block templates seems like an imposing<br= +>dependency, dragging in a bunch of state and infrastructure to a<br>questi= +on that should be solely limited to mempool feerate aggregates<br>and the f= +eerate of the particular txn package a wallet is concerned<br>with. <br><br= +>This is bad enough for protocol designers and Core developers, but<br>maki= +ng the situation any more intractable for "end-users" and wallet<= +br>developers feels wrong.<br><br>I thought it might be useful to step back= + and reframe. Here are a few<br>aims that are motivated chiefly by the qual= +ity of end-user experience,<br>constrained to obey incentive compatibility = +(i.e. miner reward, DoS<br>avoidance). Forgive the abstract dalliance for a= + moment; I'll talk<br>through concretes afterwards.<br><br><br># Purely= + additive feerate bumps should never be impossible<br><br>Any user should a= +lways be able to add to the incentive to mine any<br>transaction in a purel= +y additive way. The countervailing force here<br>ends up being spam prevent= +ion (a la min-relay-fee) to prevent someone<br>from consuming bandwidth and= + mempool space with a long series of<br>infinitesimal fee-bumps. <br><br>A = +fee bump, naturally, should be given the same per-byte consideration<br>as = +a normal Bitcoin transaction in terms of relay and block space,<br>although= + it would be nice to come up with a more succinct<br>representation. This l= +eads to another design principle:<br><br><br># The bandwidth and chain spac= +e consumed by a fee-bump should be minimal<br><br>Instead of prompting a re= +broadcast of the original transaction for<br>replacement, which contains a = +lot of data not new to the network, it<br>makes more sense to broadcast the= + "diff" which is the additive<br>contribution towards some txn= +9;s feerate. <br><br>This dovetails with the idea that...<br><br><br># Spec= +ial transaction structure should not be required to bump fees<br><br>In an = +ideal design, special structural foresight would not be needed <br>in order= + for a txn's feerate to be improved after broadcast.<br><br>Anchor outp= +uts specified solely for CPFP, which amount to many bytes of<br>wasted chai= +nspace, are a hack. It's probably uncontroversial at this<br>point to s= +ay that even RBF itself is kind of a hack - a special<br>sequence number sh= +ould not be necessary for post-broadcast contribution<br>toward feerate. No= +t to mention RBF's seemingly wasteful consumption of<br>bandwidth due t= +o the rebroadcast of data the network has already seen.<br><br>In a sane de= +sign, no structural foresight - and certainly no wasted<br>bytes in the for= +m of unused anchor outputs - should be needed in order<br>to add to a miner= +'s reward for confirming a given transaction.<br><br>Planning for fee-b= +umps explicitly in transaction structure also often<br>winds up locking in = +which keys are required to bump fees, at odds<br>with the idea that...<br><= +br><br># Feerate bumps should be able to come from anywhere<br><br>One of t= +he practical downsides of CPFP that I haven't seen discussed in<br>this= + conversation is that it requires the transaction to pre-specify the<br>key= +s needed to sign for fee bumps. This is problematic if you're, for<br>e= +xample, using a vault structure that makes use of pre-signed<br>transaction= +s. <br><br>What if the key you specified n the anchor outputs for a bunch o= +f<br>pre-signed txns is compromised? What if you'd like to be able to<b= +r>dynamically select the wallet that bumps fees? CPFP does you no favors<br= +>here.<br><br>There is of course a tension between allowing fee bumps to co= +me from<br>anywhere and the threat of pinning-like attacks. So we should ve= +nture<br>to remove pinning as a possibility, in line with the first design<= +br>principle I discuss.<br><br><br>---<br><br>Coming down to earth, the &qu= +ot;tabula rasa" thought experiment above has led<br>me to favor an app= +roach like the transaction sponsors design that Jeremy<br>proposed in a pri= +or discussion back in 2020[1].<br><br>Transaction sponsors allow feerates t= +o be bumped after a transaction's<br>broadcast, regardless of the struc= +ture of the original transaction.<br>No rebroadcast (wasted bandwidth) is r= +equired for the original txn data.<br>No wasted chainspace on only-maybe-us= +ed prophylactic anchor outputs. <br><br>The interface for end-users is very= + straightforward: if you want to bump<br>fees, specify a transaction that c= +ontributes incrementally to package<br>feerate for some txid. Simple.<br><b= +r>In the original discussion, there were a few main objections that I noted= +:<br><br>1. In Jeremy's original proposal, only one sponsor txn per txi= +d is<br>=C2=A0 =C2=A0allowed by policy. A malicious actor could execute a p= +inning-like <br>=C2=A0 =C2=A0attack by specifying an only-slightly-helpful = +feerate sponsor that <br>=C2=A0 =C2=A0then precludes other larger bumps.<br= +><br>I think there are some ways around this shortcoming. For example: what= +<br>if, by policy, sponsor txns had additional constraints that <br><br>=C2= +=A0 - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,= +<br>=C2=A0 - the txn must be specified RBFable,<br>=C2=A0 - a replacement f= +or the sponsor txn must raise the sponsor feerate, <br>=C2=A0 =C2=A0 includ= +ing ancestors (maybe this is inherent in "is RBFable," but <br>= +=C2=A0 =C2=A0 I don't want to conflate absolute feerates into this).<br= +><br>That way, there is still at most a single sponsor txn per txid in the<= +br>mempool, but anyone can "mix in" inputs which bump the effecti= +ve<br>feerate of the sponsor.<br><br>This may not be the exact solution we = +want, but I think it demonstrates<br>that the sponsors design has some flex= +ibility and merits some thinking.<br><br>The second objection about sponsor= +s was<br><br>2. (from Suhas) sponsors break the classic invariant: "on= +ce a valid<br>=C2=A0 =C2=A0transaction is created, it should not become inv= +alid later on unless <br>=C2=A0 =C2=A0the inputs are double-spent."<br= +><br>This doesn't seem like a huge concern to me if you consider the tx= +id<br>being sponsored as a sort of spiritual input to the sponsor. While th= +e<br>theoretical objection against broadening where one has to look in a tx= +n<br>to determine its dependencies is understandable, I don't see what = +the<br>practical cost here is. <br><br>Reorg complexity seems comparable if= + not identical, especially if we<br>broaden sponsor rules to allow blocks t= +o contain sponsor txns that are<br>both for txids in the same block _or_ al= +ready included in the chain.<br><br>This theoretical concession seems prefe= +rable to heaping more rules onto<br>an already labyrinthine mempool policy = +that is difficult for both<br>implementers and users to reason about practi= +cally and conceptually.<br><br>A third objection that wasn't posed, IIR= +C, but almost certainly would<br>be:<br><br>3. Transaction sponsors require= +s a soft-fork.<br><br>Soft-forks are no fun, but I'll tell you what als= +o isn't fun: being on<br>the hook to model (and sometimes implement) a = +dizzying potpourri of<br>mempool policies and special-cases. Expecting wall= +et implementers to<br>abide by a maze of rules faithfully in order to ensur= +e txn broadcast and<br>fee management invites bugs for perpetuity and netwo= +rk behavior that is<br>difficult to reason about a priori. Use of CPFP in t= +he long-term also<br>risks needless chain waste.<br><br>If a soft-fork is t= +he cost of cleaning up this essential process,<br>consideration should be g= +iven to paying it as a one-time cost. This<br>topic merits a separate post,= + but consider that in the 5 years leading<br>up to the 2017 SegWit drama, w= +e averaged about a soft-fork a year.<br>Uncontroversial, "safe" c= +hanges to the consensus protocol shouldn't be<br>out of the question wh= +en significant practical benefit is plain to see.<br><br>---<br><br>I hope = +this message has added some framing to the discussion on fees,<br>as well p= +rompting other participants to go back and give the<br>transaction sponsor = +proposal a serious look. The sponsors interface is<br>about the simplest I = +can imagine for wallets, and it seems easy to<br>reason about for implement= +ers on Core and elsewhere. =C2=A0 =C2=A0 =C2=A0 =C2=A0<br><br>I'm not o= +ut to propose soft-forks lightly, but the current complexity<br>in fee mana= +gement feels untenable, and as evidenced by all the<br>discussion lately, f= +ees are an increasingly crucial part of the system. <br><br><br><br>[0]: <a= + href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Janua= +ry/019817.html" target=3D"_blank">https://lists.linuxfoundation.org/piperma= +il/bitcoin-dev/2022-January/019817.html</a><br>[1]: <a href=3D"https://list= +s.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html" tar= +get=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020= +-September/018168.html</a><br></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--00000000000046865005d7b75109-- + + |