From: Peter Todd <pete@petertodd•org>
To: Suhas Daftuar <sdaftuar@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Fri, 4 Nov 2022 22:35:03 -0400 [thread overview]
Message-ID: <Y2XL16AkpH+xNi9B@petertodd.org> (raw)
In-Reply-To: <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-05 2:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 23:52 Anthony Towns
2022-10-27 12:36 ` Gloria Zhao
2022-10-27 15:37 ` Anthony Towns
2022-10-27 18:17 ` Luke Dashjr
2022-10-27 13:49 ` Greg Sanders
2022-10-27 15:00 ` Peter Todd
2022-10-27 20:29 ` Antoine Riard
2022-10-30 2:24 ` Anthony Towns
2022-10-29 7:45 ` David A. Harding
2022-10-30 1:02 ` Anthony Towns
2022-10-30 2:40 ` Anthony Towns
2022-10-30 11:06 ` email
2022-10-31 13:02 ` Suhas Daftuar
2022-10-31 16:25 ` Greg Sanders
2022-10-31 17:21 ` email
2022-10-31 17:51 ` Peter Todd
2022-11-04 10:28 ` email
2022-11-02 3:07 ` Anthony Towns
2022-11-02 13:32 ` Greg Sanders
2022-11-02 19:50 ` Antoine Riard
2022-11-05 2:35 ` Peter Todd [this message]
[not found] <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-27 9:56 ` John Carvalho
2022-10-27 17:21 ` Anthony Towns
2022-10-27 17:35 ` Suhas Daftuar
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ
2022-11-10 14:38 ` email
2022-11-03 21:06 email
2022-11-07 14:32 ` Peter Todd
2022-11-07 14:47 ` Erik Aronesty
2022-11-08 14:54 ` email
2022-11-09 12:05 ` email
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2XL16AkpH+xNi9B@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sdaftuar@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox