MIME-Version: 1.0
References: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
 <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
In-Reply-To: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
From: Bram Cohen <bram@chia.net>
Date: Tue, 1 Feb 2022 00:32:09 -0800
Message-ID: <CAHUJnBD034D4-Ru0d4b4_2eYeNUKvmMcvQCW7OJTO9YzWFYHnQ@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="0000000000006ccb1e05d6f0bddf"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF policy
Precedence: list

--0000000000006ccb1e05d6f0bddf
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric@voskuil.org> wrote:

>
>
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly there to appease
> some people's delusions that zeroconf is a thing? It seems a bit overdue to
> disrespect the RBF flag in the direction of always assuming it's on.
>
> What flag?
>

The opt-in RBF flag in transactions.


> There are two different common regimes which result in different
> incentivized behavior. One of them is that there's more than a block's
> backlog in the mempool in which case between two conflicting transactions
> the one with the higher fee rate should win. In the other case where there
> isn't a whole block's worth of transactions the one with higher total value
> should win.
>
> These are not distinct scenarios. The rational choice is the highest fee
> block-valid subgraph of the set of unconfirmed transactions, in both cases
> (within the limits of what is computationally feasible of course).
>

It's weird because which of two or more conflicting transactions should win
can oscillate back and forth depending on other stuff going on in the
mempool. There's already a bit of that with child pays but this is stranger
and has more oddball edge cases about which transactions to route.

--0000000000006ccb1e05d6f0bddf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 31, 2022 at 4:08 PM Eric =
Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"auto"><div dir=3D"ltr"><div dir=3D"ltr"></div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr"><br><blockquote type=3D"cite">On Jan 31, 2022, at 15:15, Br=
am Cohen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
wrote:</blockquote></div></div><div dir=3D"ltr"><blockquote type=3D"cite"><=
div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Is it stil=
l verboten to acknowledge that RBF is normal behavior and disallowing it is=
 the feature, and that feature is mostly there to appease some people&#39;s=
 delusions that zeroconf is a thing? It seems a bit overdue to disrespect t=
he RBF flag in the direction of always assuming it&#39;s on.</div></div></d=
iv></div></blockquote><div>What flag?</div></div></div></blockquote><div><b=
r></div><div>The opt-in RBF flag in transactions.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=
=3D"ltr"><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div c=
lass=3D"gmail_quote"><div>There are two different common regimes which resu=
lt in different incentivized behavior. One of them is that there&#39;s more=
 than a block&#39;s backlog in the mempool in which case between two confli=
cting transactions the one with the higher fee rate should win. In the othe=
r case where there isn&#39;t a whole block&#39;s worth of transactions the =
one with higher total value should win.</div></div></div></div></blockquote=
><div>These are not distinct scenarios. The rational choice is the highest =
fee block-valid subgraph of the set of unconfirmed transactions, in both ca=
ses (within the limits of what is computationally feasible of course).</div=
></div></div></blockquote><div><br></div><div>It&#39;s weird because which =
of two or more conflicting transactions should win can oscillate back and f=
orth depending on other stuff going on in the mempool. There&#39;s already =
a bit of that with child pays but this is stranger and has more oddball edg=
e cases about which transactions to route.</div></div></div>

--0000000000006ccb1e05d6f0bddf--