path: root/da/1faf8f8c4148150277636bd4586075b0748573

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 A4420C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 19:44:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 8444760B1B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 19:44:42 +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 eQfchWGTLlNR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 19:44:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com
 [IPv6:2607:f8b0:4864:20::534])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 898AB60AC2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 19:44:41 +0000 (UTC)
Received: by mail-pg1-x534.google.com with SMTP id s16so16216409pgs.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 01 Feb 2022 11:44:41 -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:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=uV/BcAEaeaSyouTRGSgV4OTDPXKc/20UZCsk9B7AAxM=;
 b=inztvWmzT9bDFRqsJWM7cW+3kc9xqglBh3pSbEMnb9PvNL47UEF+L09VEmRoyL8siK
 /7ykZ1803YjmCDXiZLE48m28wWMPMpU7I5OTVE5LnY5tzhA4Uk+ZJWAJF2zmgBkCyF6S
 BktZnReboNZGmamU3cUny6Gt1Fo8PZLxFxXZNMFgPp8c+ExDzm/oUPvayKb9pjDuXLKZ
 xK66PR4eRp1K5lJlBJjnlVOB75XeVpjTo9FOd0TFNkVosREqbaIosLmpCdiAS2dMRklY
 rrKEEyYf1A8dgDkEPothDwkB0Ix3GWLY+XeoGy2RLV/dIdnfDzMvfo6OIZlk9YhnxluV
 OhvA==
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
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=uV/BcAEaeaSyouTRGSgV4OTDPXKc/20UZCsk9B7AAxM=;
 b=PxXT/6Pi/T1evXwu0nU9LgrixWGJXL9maMCGQQdab7MFZLAUCzdbl5ie/WGmOZwGp6
 err5vAjzJv3EDMs1I2tECz1OjKIXwxBrGTJgXXAzfzBH5DcwJRHJ1T0+/vO3ErRuWZeh
 rMoPqilVBqcURxsTJWdtRpxXTbG2R0yLaTHIbfQPMb1H8I6rPu8syOfMSQHrHC474Gdk
 9RlkzjtnMDQoKlUsILIu4bSYm5Hj3uYI1AMBgzBY0SlwcjwbBX4QpbQHLlwQ4lkd2m5t
 fz30dABJwAesbLBQ0UvDZdmS3T2cOmioRd4fWayA5+vf4w90drcej/Vxp0B/ZZEzI8Fd
 64iA==
X-Gm-Message-State: AOAM533kQa2KdpoVHl1JG25GXxFpz8bD3H+nAgnkKKV52yn1z/ruh+RC
 Cqlkz73tyEPkptgVvncMIlIOn4Zvf6I0XA==
X-Google-Smtp-Source: ABdhPJxT4mozbfuWO1cY80tCEyPTyP0CdlYflYP16uXLAupPmpJG5Zw+UO1Upjsqa8mkuSCblHhMzQ==
X-Received: by 2002:aa7:9989:: with SMTP id k9mr26212587pfh.23.1643744680670; 
 Tue, 01 Feb 2022 11:44:40 -0800 (PST)
Received: from smtpclient.apple ([2600:380:7078:729e:a86e:e357:856:18b3])
 by smtp.gmail.com with ESMTPSA id s19sm9255206pfu.34.2022.02.01.11.44.38
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Feb 2022 11:44:39 -0800 (PST)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 1 Feb 2022 11:44:37 -0800
Message-Id: <F47C4368-76F1-4365-977B-7939981C3182@voskuil.org>
References: <CAHUJnBD034D4-Ru0d4b4_2eYeNUKvmMcvQCW7OJTO9YzWFYHnQ@mail.gmail.com>
In-Reply-To: <CAHUJnBD034D4-Ru0d4b4_2eYeNUKvmMcvQCW7OJTO9YzWFYHnQ@mail.gmail.com>
To: Bram Cohen <bram@chia.net>
X-Mailer: iPhone Mail (19C63)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 19:44:42 -0000


--Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Feb 1, 2022, at 00:32, Bram Cohen <bram@chia.net> wrote:
>=20
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>>=20
>>>> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and disa=
llowing it is the feature, and that feature is mostly there to appease some p=
eople's delusions that zeroconf is a thing? It seems a bit overdue to disres=
pect the RBF flag in the direction of always assuming it's on.
>> What flag?
>=20
> The opt-in RBF flag in transactions.

Was being facetious. The =E2=80=9Cdisrespect=E2=80=9D referred to above assu=
mes respect that some implementations have never given.

>>> There are two different common regimes which result in different incenti=
vized behavior. One of them is that there's more than a block's backlog in t=
he mempool in which case between two conflicting transactions the one with t=
he higher fee rate should win. In the other case where there isn't a whole b=
lock's worth of transactions the one with higher total value should win.
>> These are not distinct scenarios. The rational choice is the highest fee b=
lock-valid subgraph of the set of unconfirmed transactions, in both cases (w=
ithin the limits of what is computationally feasible of course).
>=20
> It's weird because which of two or more conflicting transactions should wi=
n can oscillate back and forth depending on other stuff going on in the memp=
ool.

The assumption of RAM storage is an error and unrelated to network protocol.=
 There is nothing =E2=80=9Cgoing on=E2=80=9D in a set of unconfirmed valid t=
ransactions. They are logically unchanging.

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

There=E2=80=99s really no such thing. The p2p network is necessarily permiss=
ionless. A person can route whatever he wants. Presumably people will not ge=
nerally waste their own bandwidth by routing what they believe to be unconfi=
rmable. And whatever they would retain themselves is their presumption of co=
nfirmable.

This decision of what to retain one=E2=80=99s self is just a graph traversal=
 to determine the most valuable subset - an optimizing CSP (though generally=
 suboptimal due to the time constraint).

Short of DoS, the most profitable model is to retain *all* valid transaction=
s. [Note that a spend conflict is not an invalidity. Two valid transactions c=
an be confirmed in sibling branch blocks - both valid in some context.]

So the only consideration is low cost storage fill. The fee is a proof of sp=
end, which like proof of work (for headers/blocks), is the basis of DoS prot=
ection (for unconfirmed transactions). The issue with two conflicting subgra=
phs is that one or the other is ultimately unspendable. As such the fee on e=
ach is non-cumulative and therefore only one (the highest) is providing DoS p=
rotection. Any subsequent conflicting subgraph must pay not only for itself,=
 but for all preceding conflicting subgraphs.

This pays for the storage, which is a trade accepted by the owner of the nod=
e in order to have a preview of confirmable transactions. This supports both=
 mining generation of candidate blocks and rapid validation/confirmation of b=
locks.

It=E2=80=99s a rather straightforward system when considered in terms of how=
 it actually works (ie from a consensus standpoint). The only p2p issue is t=
he need to package transactions for consideration as a set, as otherwise par=
ents may be discarded before children can pay for them. Any set up to a full=
 block is entirely reasonable for consideration.

e=

--Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27
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"></div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr"><blockquote type=3D"cite">On Feb 1, 2022, at 00:32, B=
ram Cohen &lt;bram@chia.net&gt; wrote:<br><br></blockquote></div><blockquote=
 type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 31, 2022 at 4:08 PM Eric V=
oskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskuil.org</a>&gt; wrot=
e:<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"aut=
o"><div dir=3D"ltr"><div dir=3D"ltr"></div><div dir=3D"ltr"><br></div><div d=
ir=3D"ltr"><br><blockquote type=3D"cite">On Jan 31, 2022, at 15:15, Bram Coh=
en via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" 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 still verboten t=
o 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 ze=
roconf is a thing? It seems a bit overdue to disrespect the RBF flag in the d=
irection of always assuming it's on.</div></div></div></div></blockquote><di=
v>What flag?</div></div></div></blockquote><div><br></div><div>The opt-in RB=
F flag in transactions.</div></div></div></div></blockquote><div><br></div><=
div>Was being facetious. The =E2=80=9Cdisrespect=E2=80=9D referred to above a=
ssumes respect that some implementations have never given.</div><br><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div d=
ir=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 resul=
t 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 transa=
ctions the one with the higher fee rate should win. In the other case where t=
here isn't a whole block's worth of transactions the one with higher total v=
alue should win.</div></div></div></div></blockquote><div>These are not dist=
inct scenarios. The rational choice is the highest fee block-valid subgraph o=
f the set of unconfirmed transactions, in both cases (within the limits of w=
hat is computationally feasible of course).</div></div></div></blockquote><d=
iv><br></div><div>It's weird because which of two or more conflicting transa=
ctions should win can oscillate back and forth depending on other stuff goin=
g on in the mempool.</div></div></div></div></blockquote><div><br></div><div=
>The assumption of RAM storage is an error and unrelated to network protocol=
. There is nothing =E2=80=9Cgoing on=E2=80=9D in a set of unconfirmed valid t=
ransactions. They are logically unchanging.</div><br><blockquote type=3D"cit=
e"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div> There'=
s already a bit of that with child pays but this is stranger and has more od=
dball edge cases about which transactions to route.</div></div></div>
</div></blockquote><br><div>There=E2=80=99s really no such thing. The p2p ne=
twork is necessarily permissionless. A person can route whatever he wants. P=
resumably people will not generally waste their own bandwidth by routing wha=
t they believe to be unconfirmable. And whatever they would retain themselve=
s is their presumption of confirmable.</div><div><br></div><div>This decisio=
n of what to retain one=E2=80=99s self is just a graph traversal to determin=
e the most valuable subset - an optimizing CSP (though generally suboptimal d=
ue to the time constraint).</div><div><br></div><div>Short of DoS, the most p=
rofitable model is to retain *all* valid transactions. [Note that a spend co=
nflict is not an invalidity. Two valid transactions can be confirmed in sibl=
ing branch blocks - both valid in some context.]</div><div><br></div><div>So=
 the only consideration is low cost storage fill. The fee is a proof of spen=
d, which like proof of work (for headers/blocks), is the basis of DoS protec=
tion (for unconfirmed transactions). The issue with two conflicting subgraph=
s is that one or the other is ultimately unspendable. As such the fee on eac=
h is non-cumulative and therefore only one (the highest) is providing DoS pr=
otection. Any subsequent conflicting subgraph must pay not only for itself, b=
ut for all preceding conflicting subgraphs.</div><div><br></div><div>This pa=
ys for the storage, which is a trade accepted by the owner of the node in or=
der to have a preview of confirmable transactions. This supports both mining=
 generation of candidate blocks and rapid validation/confirmation of blocks.=
</div><div><br></div><div>It=E2=80=99s a rather straightforward system when c=
onsidered in terms of how it actually works (ie from a consensus standpoint)=
. The only p2p issue is the need to package transactions for consideration a=
s a set, as otherwise parents may be discarded before children can pay for t=
hem. Any set up to a full block is entirely reasonable for consideration.</d=
iv><div><br></div><div>e</div></body></html>=

--Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27--