path: root/f6/a763b38f74abf54084c2ced0b9f4f1a0466f36

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 619AAC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5088560B1B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bS7r5dPz0O3O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com
 [IPv6:2607:f8b0:4864:20::431])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8BEA6606A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 00:08:32 +0000 (UTC)
Received: by mail-pf1-x431.google.com with SMTP id e28so14304333pfj.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 31 Jan 2022 16:08:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-transfer-encoding:from:mime-version:date:message-id
 :references:in-reply-to:subject:to;
 bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=;
 b=pd+6jVWptLtqfQMdkfqR7yqasII8WcsNwlJcruGB0nTOpyxcDg4Kw8MBG2K9zns0GA
 4sxgz0UFwKNnATBYP6rexrz1qW59V2p68T9bWwwvZfeZv5QS92BnEGaeAlo+zeXbCDFS
 jrXU2DQ3HY1tpNmfqp+CEUGybH2wH+QeSv9ZsnpypKrOU9GPNB08oPWDeleJANwUsMhW
 zoL+X5VaPB2avvMMBYtNKW+JFsyWzr/WBkw22pTgO11wqOf2xr3fWGA9hvG0utuD4nq4
 zomMeUqR/gjA4NbXg8CFBnOLRx22AwzmsRbiaX3Rl8lKhGUnDohQZLLucMSkiIpmXQFe
 YVkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version:date
 :message-id:references:in-reply-to:subject:to;
 bh=ymrRFyF4HxHtXVeq5KxHjum+BqAQtdlnuvVHDP7Dh4o=;
 b=0wP9vrF91eNTGh42BsozgwKinAYtUDfG4CE7ZQbD6ggz7IbMvO1/kOSmlE8X3Etjrc
 AR3HgpM6HvtgKkmjRWkIYGhTt73D0lifRy0a3PNuPLLHEqNRCsC0nDaMUVZmM3yj3zP0
 7jGzSxxBisFKaNtD6B13AGkopXBnUGnV+pFwh7mJzvezw8eh0ebpxsrW+Sl9hXSelGCq
 ikaikf7crcV1pbGxZ/BE/9COzcfBveiWWLrej8My/0DcneyH6T6C2NJj9lWT7ArnEKAs
 Jxd8V5WR5zaTTg0jGftTv4kg+0IYAvxgs0Pq0qvcVVzGM9vvmtcnfVu1/N+Amuf9peu+
 Q0Sg==
X-Gm-Message-State: AOAM533cStvNVVSnmgkOvwS5i391bEFGC+01+2nPGnCcBuW8RXJ5oR5A
 N3xVSefCZvPa8FFkSBKv3m0RaA==
X-Google-Smtp-Source: ABdhPJxA3/Sw6FEfINVhwaZTb3HT46wRQujDiGDw4LlW5zWCBJzubKPIVZdBmlAl2rI3VySWsNIAEA==
X-Received: by 2002:aa7:8595:: with SMTP id w21mr22335245pfn.18.1643674111788; 
 Mon, 31 Jan 2022 16:08:31 -0800 (PST)
Received: from smtpclient.apple ([2601:600:9c00:1d0::ff78])
 by smtp.gmail.com with ESMTPSA id j14sm20151726pfj.218.2022.01.31.16.08.31
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Jan 2022 16:08:31 -0800 (PST)
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>
X-Mailer: iPhone Mail (19C63)
Subject: Re: [bitcoin-dev] Improving RBF policy
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2022 00:08:33 -0000


--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--