📅 Original date posted:2022-02-10
📝 Original message: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 at 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 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/20220211/c1c03c95/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-07 23:04:08
in reply to nevent1q…kmc5
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 23:04:08Event JSON
{
"id": "e216cc1940c6b6ff656e2e5e186984ced154864564f562786e40cea51a1c4728",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686179048,
"kind": 1,
"tags": [
[
"e",
"c703681c72b4e4669ca1bb5b15d757a9761db34f49baa03e75c29c4c1b65c0d1",
"",
"root"
],
[
"e",
"daeca8a7349450d077ee790ab7cef867f291eb5cb2457cf44b34d1a946e7df95",
"",
"reply"
],
[
"p",
"685a977aa1f8b6f8ec48fd9b94063704f408148948329ed2d729f63e54b31a3d"
]
],
"content": "📅 Original date posted:2022-02-10\n📝 Original message:One quick thought to the proposal and perhaps to sponsors in general(didn't\nhave time to go over original proposal again):\n\nSince sponsors can come from anywhere, the wallet application must have\naccess to the mempool to know what inputs must be double spent to RBF the\nsponsor transaction.\n\nSeems like an important difference to be considered.\n\nOn Fri, Feb 11, 2022 at 3:49 AM James O'Beirne via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e There's been much talk about fee-bumping lately, and for good reason -\n\u003e dynamic fee management is going to be a central part of bitcoin use as\n\u003e the mempool fills up (lord willing) and right now fee-bumping is\n\u003e fraught with difficulty and pinning peril.\n\u003e\n\u003e Gloria's recent post on the topic[0] was very lucid and highlights a\n\u003e lot of the current issues, as well as some proposals to improve the\n\u003e situation.\n\u003e\n\u003e As others have noted, the post was great. But throughout the course\n\u003e of reading it and the ensuing discussion, I became troubled by the\n\u003e increasing complexity of both the status quo and some of the\n\u003e proposed remedies.\n\u003e\n\u003e Layering on special cases, more carve-outs, and X and Y percentage\n\u003e thresholds is going to make reasoning about the mempool harder than it\n\u003e already is. Special consideration for \"what should be in the next\n\u003e block\" and/or the caching of block templates seems like an imposing\n\u003e dependency, dragging in a bunch of state and infrastructure to a\n\u003e question that should be solely limited to mempool feerate aggregates\n\u003e and the feerate of the particular txn package a wallet is concerned\n\u003e with.\n\u003e\n\u003e This is bad enough for protocol designers and Core developers, but\n\u003e making the situation any more intractable for \"end-users\" and wallet\n\u003e developers feels wrong.\n\u003e\n\u003e I thought it might be useful to step back and reframe. Here are a few\n\u003e aims that are motivated chiefly by the quality of end-user experience,\n\u003e constrained to obey incentive compatibility (i.e. miner reward, DoS\n\u003e avoidance). Forgive the abstract dalliance for a moment; I'll talk\n\u003e through concretes afterwards.\n\u003e\n\u003e\n\u003e # Purely additive feerate bumps should never be impossible\n\u003e\n\u003e Any user should always be able to add to the incentive to mine any\n\u003e transaction in a purely additive way. The countervailing force here\n\u003e ends up being spam prevention (a la min-relay-fee) to prevent someone\n\u003e from consuming bandwidth and mempool space with a long series of\n\u003e infinitesimal fee-bumps.\n\u003e\n\u003e A fee bump, naturally, should be given the same per-byte consideration\n\u003e as a normal Bitcoin transaction in terms of relay and block space,\n\u003e although it would be nice to come up with a more succinct\n\u003e representation. This leads to another design principle:\n\u003e\n\u003e\n\u003e # The bandwidth and chain space consumed by a fee-bump should be minimal\n\u003e\n\u003e Instead of prompting a rebroadcast of the original transaction for\n\u003e replacement, which contains a lot of data not new to the network, it\n\u003e makes more sense to broadcast the \"diff\" which is the additive\n\u003e contribution towards some txn's feerate.\n\u003e\n\u003e This dovetails with the idea that...\n\u003e\n\u003e\n\u003e # Special transaction structure should not be required to bump fees\n\u003e\n\u003e In an ideal design, special structural foresight would not be needed\n\u003e in order for a txn's feerate to be improved after broadcast.\n\u003e\n\u003e Anchor outputs specified solely for CPFP, which amount to many bytes of\n\u003e wasted chainspace, are a hack. It's probably uncontroversial at this\n\u003e point to say that even RBF itself is kind of a hack - a special\n\u003e sequence number should not be necessary for post-broadcast contribution\n\u003e toward feerate. Not to mention RBF's seemingly wasteful consumption of\n\u003e bandwidth due to the rebroadcast of data the network has already seen.\n\u003e\n\u003e In a sane design, no structural foresight - and certainly no wasted\n\u003e bytes in the form of unused anchor outputs - should be needed in order\n\u003e to add to a miner's reward for confirming a given transaction.\n\u003e\n\u003e Planning for fee-bumps explicitly in transaction structure also often\n\u003e winds up locking in which keys are required to bump fees, at odds\n\u003e with the idea that...\n\u003e\n\u003e\n\u003e # Feerate bumps should be able to come from anywhere\n\u003e\n\u003e One of the practical downsides of CPFP that I haven't seen discussed in\n\u003e this conversation is that it requires the transaction to pre-specify the\n\u003e keys needed to sign for fee bumps. This is problematic if you're, for\n\u003e example, using a vault structure that makes use of pre-signed\n\u003e transactions.\n\u003e\n\u003e What if the key you specified n the anchor outputs for a bunch of\n\u003e pre-signed txns is compromised? What if you'd like to be able to\n\u003e dynamically select the wallet that bumps fees? CPFP does you no favors\n\u003e here.\n\u003e\n\u003e There is of course a tension between allowing fee bumps to come from\n\u003e anywhere and the threat of pinning-like attacks. So we should venture\n\u003e to remove pinning as a possibility, in line with the first design\n\u003e principle I discuss.\n\u003e\n\u003e\n\u003e ---\n\u003e\n\u003e Coming down to earth, the \"tabula rasa\" thought experiment above has led\n\u003e me to favor an approach like the transaction sponsors design that Jeremy\n\u003e proposed in a prior discussion back in 2020[1].\n\u003e\n\u003e Transaction sponsors allow feerates to be bumped after a transaction's\n\u003e broadcast, regardless of the structure of the original transaction.\n\u003e No rebroadcast (wasted bandwidth) is required for the original txn data.\n\u003e No wasted chainspace on only-maybe-used prophylactic anchor outputs.\n\u003e\n\u003e The interface for end-users is very straightforward: if you want to bump\n\u003e fees, specify a transaction that contributes incrementally to package\n\u003e feerate for some txid. Simple.\n\u003e\n\u003e In the original discussion, there were a few main objections that I noted:\n\u003e\n\u003e 1. In Jeremy's original proposal, only one sponsor txn per txid is\n\u003e allowed by policy. A malicious actor could execute a pinning-like\n\u003e attack by specifying an only-slightly-helpful feerate sponsor that\n\u003e then precludes other larger bumps.\n\u003e\n\u003e I think there are some ways around this shortcoming. For example: what\n\u003e if, by policy, sponsor txns had additional constraints that\n\u003e\n\u003e - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,\n\u003e - the txn must be specified RBFable,\n\u003e - a replacement for the sponsor txn must raise the sponsor feerate,\n\u003e including ancestors (maybe this is inherent in \"is RBFable,\" but\n\u003e I don't want to conflate absolute feerates into this).\n\u003e\n\u003e That way, there is still at most a single sponsor txn per txid in the\n\u003e mempool, but anyone can \"mix in\" inputs which bump the effective\n\u003e feerate of the sponsor.\n\u003e\n\u003e This may not be the exact solution we want, but I think it demonstrates\n\u003e that the sponsors design has some flexibility and merits some thinking.\n\u003e\n\u003e The second objection about sponsors was\n\u003e\n\u003e 2. (from Suhas) sponsors break the classic invariant: \"once a valid\n\u003e transaction is created, it should not become invalid later on unless\n\u003e the inputs are double-spent.\"\n\u003e\n\u003e This doesn't seem like a huge concern to me if you consider the txid\n\u003e being sponsored as a sort of spiritual input to the sponsor. While the\n\u003e theoretical objection against broadening where one has to look in a txn\n\u003e to determine its dependencies is understandable, I don't see what the\n\u003e practical cost here is.\n\u003e\n\u003e Reorg complexity seems comparable if not identical, especially if we\n\u003e broaden sponsor rules to allow blocks to contain sponsor txns that are\n\u003e both for txids in the same block _or_ already included in the chain.\n\u003e\n\u003e This theoretical concession seems preferable to heaping more rules onto\n\u003e an already labyrinthine mempool policy that is difficult for both\n\u003e implementers and users to reason about practically and conceptually.\n\u003e\n\u003e A third objection that wasn't posed, IIRC, but almost certainly would\n\u003e be:\n\u003e\n\u003e 3. Transaction sponsors requires a soft-fork.\n\u003e\n\u003e Soft-forks are no fun, but I'll tell you what also isn't fun: being on\n\u003e the hook to model (and sometimes implement) a dizzying potpourri of\n\u003e mempool policies and special-cases. Expecting wallet implementers to\n\u003e abide by a maze of rules faithfully in order to ensure txn broadcast and\n\u003e fee management invites bugs for perpetuity and network behavior that is\n\u003e difficult to reason about a priori. Use of CPFP in the long-term also\n\u003e risks needless chain waste.\n\u003e\n\u003e If a soft-fork is the cost of cleaning up this essential process,\n\u003e consideration should be given to paying it as a one-time cost. This\n\u003e topic merits a separate post, but consider that in the 5 years leading\n\u003e up to the 2017 SegWit drama, we averaged about a soft-fork a year.\n\u003e Uncontroversial, \"safe\" changes to the consensus protocol shouldn't be\n\u003e out of the question when significant practical benefit is plain to see.\n\u003e\n\u003e ---\n\u003e\n\u003e I hope this message has added some framing to the discussion on fees,\n\u003e as well prompting other participants to go back and give the\n\u003e transaction sponsor proposal a serious look. The sponsors interface is\n\u003e about the simplest I can imagine for wallets, and it seems easy to\n\u003e reason about for implementers on Core and elsewhere.\n\u003e\n\u003e I'm not out to propose soft-forks lightly, but the current complexity\n\u003e in fee management feels untenable, and as evidenced by all the\n\u003e discussion lately, fees are an increasingly crucial part of the system.\n\u003e\n\u003e\n\u003e\n\u003e [0]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html\n\u003e [1]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/c1c03c95/attachment.html\u003e",
"sig": "0f80598f50f6dfd859bf652de862dd6e067a2a2848dc78ada2e46a2b77f97d89a7259f780a35126e84d68f4d11f26c909ce43393e904b98bbfe771550176b222"
}