Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-05 📝 Original message:On Mon, Oct 31, 2022 at ...
📅 Original date posted:2022-11-05
📝 Original message:On Mon, Oct 31, 2022 at 09:02:02AM -0400, Suhas Daftuar via bitcoin-dev wrote:
Sending this email for the sake of repeating a point I made on GitHub for the
mailing list audience:
> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we view
> mempool policy in the Bitcoin Core project, and how that seems to be
> changing in the discussions around `-mempoolfullrbf`, are on-point and
> provide a helpful baseline for considering future policy changes.
<snip>
> To those who argue for making fullrbf a default policy on the network (or
> even just offering a flag for users to enable fullrbf), I pose this
> hypothetical: suppose we deploy the v3 transaction policy proposal (which I
> hope will happen in the near future). That policy would restrict the ways
> that outputs of a v3 transaction can be spent while the transaction is
> unconfirmed, including by limiting the number and size of descendants that
> such a transaction can have, and limiting the types of unconfirmed
> ancestors that can be included. Suppose in a few years someone proposes
> that we add a "-disable_v3_transaction_enforcement" flag to our software,
> to let users decide to turn off those policy restrictions and treat v3
> transactions the same as v2, for all the same reasons that could be argued
> today with fullrbf: miners might earn more revenue if we allowed multiple
> descendant v3 transactions; it's illogical for the recipient of a v3
> transaction to believe what is a fundamentally unenforceable promise of a
> sender to not issue more high value children that descend from an
> unconfirmed transaction; it's inappropriate for Bitcoin Core to dictate
> policy on the network and we should honor user choice to turn off that flag
> if that’s what users want; if users are relying on v3’s policy restrictions
> for security then that is an unstable model and we should assume it will
> get broken[5].
Let's frame this question differently: given that there are potential
incentives around a hypothetical `-disable_v3_transaction_enforcement` flag,
why are we trying to prevent miners and others from experimenting with
incentives around `fullrbf`?
Yanking the `mempoolfullrbf` flag from Bitcoin Core v24.0 simply puts a
temporary roadblock in the face of full-rbf. Without that roadblock, we might
find that some miners do in fact choose to enable it. The sooner we find that
out, the sooner we can learn about the incentives involved in that decision.
Meanwhile, if we insted put up those roadblocks, we'll be designing mechanisms
like v3 blind, without the benefit of seeing how incentives play out fully.
This experimentation can't happen on testnet: incentives don't work properly
when there isn't money at stake. And the proposed reversion pull-reqs don't
even leave the option for testnet anyway. So we're left with one choice:
release a full-rbf option, and see what happens on mainnet.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/7e2f2a87/attachment.sig>;
📝 Original message:On Mon, Oct 31, 2022 at 09:02:02AM -0400, Suhas Daftuar via bitcoin-dev wrote:
Sending this email for the sake of repeating a point I made on GitHub for the
mailing list audience:
> AJ,
>
> Thanks for the thoughtful post. I think your observations about how we view
> mempool policy in the Bitcoin Core project, and how that seems to be
> changing in the discussions around `-mempoolfullrbf`, are on-point and
> provide a helpful baseline for considering future policy changes.
<snip>
> To those who argue for making fullrbf a default policy on the network (or
> even just offering a flag for users to enable fullrbf), I pose this
> hypothetical: suppose we deploy the v3 transaction policy proposal (which I
> hope will happen in the near future). That policy would restrict the ways
> that outputs of a v3 transaction can be spent while the transaction is
> unconfirmed, including by limiting the number and size of descendants that
> such a transaction can have, and limiting the types of unconfirmed
> ancestors that can be included. Suppose in a few years someone proposes
> that we add a "-disable_v3_transaction_enforcement" flag to our software,
> to let users decide to turn off those policy restrictions and treat v3
> transactions the same as v2, for all the same reasons that could be argued
> today with fullrbf: miners might earn more revenue if we allowed multiple
> descendant v3 transactions; it's illogical for the recipient of a v3
> transaction to believe what is a fundamentally unenforceable promise of a
> sender to not issue more high value children that descend from an
> unconfirmed transaction; it's inappropriate for Bitcoin Core to dictate
> policy on the network and we should honor user choice to turn off that flag
> if that’s what users want; if users are relying on v3’s policy restrictions
> for security then that is an unstable model and we should assume it will
> get broken[5].
Let's frame this question differently: given that there are potential
incentives around a hypothetical `-disable_v3_transaction_enforcement` flag,
why are we trying to prevent miners and others from experimenting with
incentives around `fullrbf`?
Yanking the `mempoolfullrbf` flag from Bitcoin Core v24.0 simply puts a
temporary roadblock in the face of full-rbf. Without that roadblock, we might
find that some miners do in fact choose to enable it. The sooner we find that
out, the sooner we can learn about the incentives involved in that decision.
Meanwhile, if we insted put up those roadblocks, we'll be designing mechanisms
like v3 blind, without the benefit of seeing how incentives play out fully.
This experimentation can't happen on testnet: incentives don't work properly
when there isn't money at stake. And the proposed reversion pull-reqs don't
even leave the option for testnet anyway. So we're left with one choice:
release a full-rbf option, and see what happens on mainnet.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/7e2f2a87/attachment.sig>;