From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id AE2F1C000B for ; Thu, 10 Feb 2022 23:09:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9C7FD60706 for ; Thu, 10 Feb 2022 23:09:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 dDFLHc9A_tUx for ; Thu, 10 Feb 2022 23:09:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by smtp3.osuosl.org (Postfix) with ESMTPS id 74CFE60675 for ; Thu, 10 Feb 2022 23:09:18 +0000 (UTC) Received: by mail-yb1-xb32.google.com with SMTP id j2so20105811ybu.0 for ; Thu, 10 Feb 2022 15:09:18 -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=bALvPqO5H8T6/FtS2qayzG4sNIIn7AUGfNXtwZRvdRg=; b=YFBM4PLQCVPYbmaCw0BihJ/Yqf4cN1wQ26frh37/PxLp77esa6HluzLZs0V8jjbzeo 2OqKvHmLeVW/1pwDVyFD0btIlQOaaslf4PYbI27uCZmj8nHEy0zgwE5DAowlZYKRoXba 6eWs9H7qiqipfn64w4kvD9QdMvbp0U3vU6Wr+N9z9Fb/NjxY3P/qOsnwQzAgIjArfRaZ wUm3udne6FFTwKb4/DIJWuQNoeptAyd4a19QjhnxR2y92NiIQxfdOsT0iPnUElY9Z8vo i2ht99BiHOVQ572XYlCAD21PCZb0pl11jwf36t9k0eXOOQavYSsbNW6nXahrLDzDdz34 l0Tg== 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=bALvPqO5H8T6/FtS2qayzG4sNIIn7AUGfNXtwZRvdRg=; b=WC7sBNacPZQsciiIGSI1csZ2ytnTvzUMtV2Vg5NTfROPtRCRAp4uPrUcYI7ADeAcnr 878OAEOWrfHOpZRpsx6GCO9kR0jrkVaWfLYNgVNstWUC0ByGI0ShNxs4LdNzscLyzW46 LMjrmN5ovbd6JD2d/GQT2xVy/d5gYP3LkHfhC7VxFuWVuaB+lfHT3zOfkURx1/wIAMVT cs2w2831P3vEWs5cdd0vjVFHF7ic+0u+a0A3Hbskg6WZlqSh6UiiteCENz+B5a64McRR o/IPWkDbQsaI+ejWmRPxbfLdoN7yhJxwoKMmSLskf1FmjQK1RgnW2uzHVvGrE/QQyd3q m7Jw== X-Gm-Message-State: AOAM533gxvMp4IJ3eAuojs77AMdV8W5Rd5NF8Ol9nrqTFpHcBRyFDwe/ 9KlMiYgBDv3Ed6i6ck+Lysau1haKAAFVQYjcu0k= X-Google-Smtp-Source: ABdhPJwpzaTp0FDFBHnVAX/JCYcE6FgpMsIt440QCs5pDAKqGBe9PfIEsJu7kl9zfSgJTUGeoysrO+yrIZzsfA50CeA= X-Received: by 2002:a25:4943:: with SMTP id w64mr9972260yba.619.1644534557360; Thu, 10 Feb 2022 15:09:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Fri, 11 Feb 2022 07:09:06 +0800 Message-ID: To: "James O'Beirne" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001cc56a05d7b20ae1" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 23:09:20 -0000 --0000000000001cc56a05d7b20ae1 Content-Type: text/plain; charset="UTF-8" One quick thought to the proposal and perhaps to sponsors in general(didn't have time to go over original proposal again): Since sponsors can come from anywhere, the wallet application must have access to the mempool to know what inputs must be double spent to RBF the sponsor transaction. Seems like an important difference to be considered. On Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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/019817.html > [1]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000001cc56a05d7b20ae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One quick thought to the proposal and perhaps to sponsors = in general(didn't have time to go over original proposal again):
Since sponsors=C2=A0can come from anywhere, the wallet applica= tion=C2=A0must have access to the mempool to know what inputs must be doubl= e spent to RBF the sponsor transaction.=C2=A0

= Seems like an important difference to be considered.

On Fri, Feb 11, 2= 022 at 3:49 AM James O'Beirne via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
There's been much talk about fee-bumping lately, an= d 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 th= e current issues, as well as some proposals to improve the
situation.
As others have noted, the post was great. But throughout the courseof reading it and the ensuing discussion, I became troubled by the
incr= easing complexity of both the status quo and some of the
pro= posed remedies.

Layering on special cases, more carve-ou= ts, and X and Y percentage
thresholds is going to make reasoning about t= he mempool harder than it
already is. Special consideration for "wh= at should be in the next
block" and/or the caching of block templat= es seems like an imposing
dependency, dragging in a bunch of state and i= nfrastructure to a
question that should be solely limited to mempool fee= rate aggregates
and the feerate of the particular txn package a wallet i= s 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 m= otivated chiefly by the quality of end-user experience,
constrained to o= bey incentive compatibility (i.e. miner reward, DoS
avoidance). Forgive = the abstract dalliance for a moment; I'll talk
through concretes aft= erwards.


# Purely additive feerate bumps should never be impossi= ble

Any user should always be able to add to the incentive to mine a= ny
transaction in a purely additive way. The countervailing force hereends up being spam prevention (a la min-relay-fee) to prevent someone
= from consuming bandwidth and mempool space with a long series of
infinit= esimal fee-bumps.

A fee bump, naturally, should be given the same p= er-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 succin= ct
representation. This leads to another design principle:


# = The bandwidth and chain space consumed by a fee-bump should be minimal
<= br>Instead of prompting a rebroadcast of the original transaction for
re= placement, which contains a lot of data not new to the network, it
makes= more sense to broadcast the "diff" which is the additive
cont= ribution towards some txn's feerate.

This dovetails with the id= ea that...


# Special transaction structure should not be require= d to bump fees

In an ideal design, special structural foresight woul= d not be needed
in order for a txn's feerate to be improved after b= roadcast.

Anchor outputs specified solely for CPFP, which amount to = many bytes of
wasted chainspace, are a hack. It's probably uncontrov= ersial at this
point to say that even RBF itself is kind of a hack - a s= pecial
sequence number should not be necessary for post-broadcast contri= bution
toward feerate. Not to mention RBF's seemingly wasteful consu= mption of
bandwidth due to the rebroadcast of data the network has alrea= dy seen.

In a sane design, no structural foresight - and certainly n= o wasted
bytes in the form of unused anchor outputs - should be needed i= n order
to add to a miner's reward for confirming a given transactio= n.

Planning for fee-bumps explicitly in transaction structure also o= ften
winds up locking in which keys are required to bump fees, at oddswith the idea that...


# Feerate bumps should be able to come f= rom anywhere

One of the practical downsides of CPFP that I haven'= ;t seen discussed in
this conversation is that it requires the transacti= on to pre-specify the
keys needed to sign for fee bumps. This is problem= atic 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 yo= u'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 betw= een allowing fee bumps to come from
anywhere and the threat of pinning-l= ike attacks. So we should venture
to remove pinning as a possibility, in= line with the first design
principle I discuss.


---

C= oming down to earth, the "tabula rasa" thought experiment above h= as led
me to favor an approach like the transaction sponsors design that= Jeremy
proposed in a prior discussion back in 2020[1].

Transacti= on sponsors allow feerates to be bumped after a transaction's
broadc= ast, regardless of the structure of the original transaction.
No rebroad= cast (wasted bandwidth) is required for the original txn data.
No wasted= chainspace on only-maybe-used prophylactic anchor outputs.

The int= erface 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
=C2=A0 =C2=A0allowed by policy. A malic= ious actor could execute a pinning-like
=C2=A0 =C2=A0attack by specifyi= ng an only-slightly-helpful feerate sponsor that
=C2=A0 =C2=A0then prec= ludes other larger bumps.

I think there are some ways around this sh= ortcoming. For example: what
if, by policy, sponsor txns had additional = constraints that

=C2=A0 - each input must be signed {SIGHASH_SINGLE= ,SIGHASH_NONE}|ANYONECANPAY,
=C2=A0 - the txn must be specified RBFable,=
=C2=A0 - a replacement for the sponsor txn must raise the sponsor feera= te,
=C2=A0 =C2=A0 including ancestors (maybe this is inherent in "= is RBFable," but
=C2=A0 =C2=A0 I don't want to conflate absolu= te feerates into this).

That way, there is still at most a single sp= onsor txn per txid in the
mempool, but anyone can "mix in" inp= uts which bump the effective
feerate of the sponsor.

This may not= be the exact solution we want, but I think it demonstrates
that the spo= nsors design has some flexibility and merits some thinking.

The seco= nd objection about sponsors was

2. (from Suhas) sponsors break the c= lassic invariant: "once a valid
=C2=A0 =C2=A0transaction is created= , it should not become invalid later on unless
=C2=A0 =C2=A0the 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 inpu= t to the sponsor. While the
theoretical objection against broadening whe= re one has to look in a txn
to determine its dependencies is understanda= ble, I don't see what the
practical cost here is.

Reorg comp= lexity seems comparable if not identical, especially if we
broaden spons= or rules to allow blocks to contain sponsor txns that are
both for txids= in the same block _or_ already included in the chain.

This theoreti= cal concession seems preferable to heaping more rules onto
an already la= byrinthine mempool policy that is difficult for both
implementers and us= ers to reason about practically and conceptually.

A third objection = that wasn't posed, IIRC, but almost certainly would
be:

3. Tr= ansaction 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 (a= nd sometimes implement) a dizzying potpourri of
mempool policies and spe= cial-cases. Expecting wallet implementers to
abide by a maze of rules fa= ithfully in order to ensure txn broadcast and
fee management invites bug= s 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.<= br>
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
top= ic merits a separate post, but consider that in the 5 years leading
up t= o the 2017 SegWit drama, we averaged about a soft-fork a year.
Uncontrov= ersial, "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 discus= sion on fees,
as well prompting other participants to go back and give t= he
transaction sponsor proposal a serious look. The sponsors interface i= s
about the simplest I can imagine for wallets, and it seems easy to
= reason about for implementers on Core and elsewhere. =C2=A0 =C2=A0 =C2=A0 = =C2=A0

I'm not out to propose soft-forks lightly, but the curren= t complexity
in fee management feels untenable, and as evidenced by all = the
discussion lately, fees are an increasingly crucial part of the syst= em.



[0]: https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
[= 1]: https://lists.linuxfoundation.org= /pipermail/bitcoin-dev/2020-September/018168.html
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000001cc56a05d7b20ae1--