Content-Type: multipart/alternative;
 boundary=Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 31 Jan 2022 16:08:30 -0800
Message-Id: <20ADE052-C2D6-49DD-AAD6-392A7CA1389B@voskuil.org>
References: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
In-Reply-To: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com>
To: Bram Cohen <bram@chia.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF policy
Precedence: list


--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:


=E2=80=A6

> Is it still verboten to acknowledge that RBF is normal behavior and disall=
owing it is the feature, and that feature is mostly there to appease some pe=
ople's delusions that zeroconf is a thing? It seems a bit overdue to disresp=
ect the RBF flag in the direction of always assuming it's on.

What flag?

>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>   accept replacement transactions which would decrease fee profits
>>   of a miner. In general, if our mempool policy deviates from what is
>> economically rational, it's likely that the transactions in our
>> mempool will not match the ones in miners' mempools, making our
>> fee estimation, compact block relay, and other mempool-dependent
>> functions unreliable. Incentive-incompatible policy may also
>> encourage transaction submission through routes other than the p2p
>> network, harming censorship-resistance and privacy of Bitcoin payments.
>=20
> There are two different common regimes which result in different incentivi=
zed 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 blo=
ck's worth of transactions the one with higher total value should win.

These are not distinct scenarios. The rational choice is the highest fee blo=
ck-valid subgraph of the set of unconfirmed transactions, in both cases (wit=
hin the limits of what is computationally feasible of course).

When collecting pooled txs the only issue is DoS protection, which is simply=
 a question of what any given miner is willing to pay, in terms of disk spac=
e, to archive conflicts for the opportunity to optimize block reward.

> It would be nice to have consolidated logic which handles both, it seems t=
he issue has to do with the slope of the supply/demand curve which in the fi=
rst case is gentle enough to keep the one transaction from hitting the rate b=
ut in the second one is basically infinite.

--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><meta http-equiv=3D"conten=
t-type" content=3D"text/html; charset=3Dutf-8"><div dir=3D"ltr"></div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Jan 3=
1, 2022, at 15:15, Bram Cohen via bitcoin-dev &lt;bitcoin-dev@lists.linuxfou=
ndation.org&gt; wrote:</blockquote></div><div dir=3D"ltr"><br></div>=E2=80=A6=
</div><div dir=3D"ltr"><br><blockquote type=3D"cite"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br></blockquote><div>Is it still verboten to acknowledge that RB=
F is normal behavior and disallowing it is the feature, and that feature is m=
ostly there to appease some people's delusions that zeroconf is a thing? It s=
eems a bit overdue to disrespect the RBF flag in the direction of always ass=
uming it's on.</div></div></div></div></blockquote><div><br></div><div>What f=
lag?</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- *=
*Incentive Compatibility**: Ensure that our RBF policy would not<br>
&nbsp; accept replacement transactions which would decrease fee profits<br>
&nbsp; of a miner. In general, if our mempool policy deviates from what is<b=
r>
economically rational, it's likely that the transactions in our<br>
mempool will not match the ones in miners' mempools, making our<br>
fee estimation, compact block relay, and other mempool-dependent<br>
functions unreliable. Incentive-incompatible policy may also<br>
encourage transaction submission through routes other than the p2p<br>
network, harming censorship-resistance and privacy of Bitcoin payments.<br><=
/blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>=
<div>These are not distinct scenarios. The rational choice is the highest fe=
e block-valid subgraph of the set of unconfirmed transactions, in both cases=
 (within the limits of what is computationally feasible of course).</div><di=
v><br></div><div>When collecting pooled txs the only issue is DoS protection=
, which is simply a question of what any given miner is willing to pay, in t=
erms of disk space, to archive conflicts for the opportunity to optimize blo=
ck reward.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div>It would be nice to have consolidated lo=
gic which handles both, it seems the issue has to do with the slope of the s=
upply/demand curve which in the first case is gentle enough to keep the one t=
ransaction from hitting the rate but in the second one is basically infinite=
.</div></div></div><br></div></blockquote></div></body></html>=

--Apple-Mail-3640B48A-D666-4AD7-8C68-DD8C1B136305--