damian at willtech.com.au [ARCHIVE] on Nostr: đź“… Original date posted:2022-02-13 đź“ť Original message: Good Afternoon, I wish to ...
đź“… Original date posted:2022-02-13
đź“ť Original message:
Good Afternoon,
I wish to post this discussion back to both threads to save repeating.
As Peter Todd pointed out there are already two ways to increase the fee
on a transaction RBF and Child Pays for Parent. Both of these methods
are secure and do not allow for attack. Someone said there is not
attack, however, sponsoring transactions allows for anyone to
arbitrarily attach fees to a transaction in mempool as there is now way
to validate that two UTXO's are associated as there are in the two cases
already implemented, and this vector allows exploit if unchecked. A
miner could arbitrarily attach 1BTC to a transaction is his own mempool,
in fact if the miner has sufficient bitcoin all transactions he intends
to mine, or in fact all miners could, and none of them need to broadcast
the supplementary fee as mempool is gossip. Then when the miner is
successful in creating a block all sponsored fees are returned and it is
necessary for legitimate transactions to include a large fee in order to
be selected, which may take to form sponsorship. This miners-only attack
allows fees to be arbitrarily driven up. As it is I guess fees are
averaging 0.238 BTC per block with 1.7K transactions per block and a fee
of 0.00014000 BTC per transaction and without block reward and this is
sufficient to drive down power usage which needs to go down a lot more
to be sustainable in our global environment.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2022-02-10 21:26, Antoine Riard via bitcoin-dev wrote:
> 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.html
> and roughly roughly implemented here :
> https://github.com/ariard/bitcoin/pull/1
>
> Le jeu. 10 févr. 2022 à 14:48, James O'Beirne via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> a Ă©crit :
>
>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
đź“ť Original message:
Good Afternoon,
I wish to post this discussion back to both threads to save repeating.
As Peter Todd pointed out there are already two ways to increase the fee
on a transaction RBF and Child Pays for Parent. Both of these methods
are secure and do not allow for attack. Someone said there is not
attack, however, sponsoring transactions allows for anyone to
arbitrarily attach fees to a transaction in mempool as there is now way
to validate that two UTXO's are associated as there are in the two cases
already implemented, and this vector allows exploit if unchecked. A
miner could arbitrarily attach 1BTC to a transaction is his own mempool,
in fact if the miner has sufficient bitcoin all transactions he intends
to mine, or in fact all miners could, and none of them need to broadcast
the supplementary fee as mempool is gossip. Then when the miner is
successful in creating a block all sponsored fees are returned and it is
necessary for legitimate transactions to include a large fee in order to
be selected, which may take to form sponsorship. This miners-only attack
allows fees to be arbitrarily driven up. As it is I guess fees are
averaging 0.238 BTC per block with 1.7K transactions per block and a fee
of 0.00014000 BTC per transaction and without block reward and this is
sufficient to drive down power usage which needs to go down a lot more
to be sustainable in our global environment.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2022-02-10 21:26, Antoine Riard via bitcoin-dev wrote:
> 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.html
> and roughly roughly implemented here :
> https://github.com/ariard/bitcoin/pull/1
>
> Le jeu. 10 févr. 2022 à 14:48, James O'Beirne via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> a Ă©crit :
>
>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev