path: root/1e/57bf429d9851603f5af97de204872dedef47d9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4B87FC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 02:54:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 2A36A82862
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 02:54:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id oNCe57BZ9gb7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 02:54:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 83256827CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 02:54:46 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id h8so1405182ejy.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 18:54:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=;
 b=afz9lnXXNOMjkbR3oG7HoTSTtsupoAyJZrSqQzcmhClGFAsXkBLrENbgrwk3u+Xj+m
 jTr83iHFJ4yKFvyGbbBC59mcVadqIucxSFEIe7PYDcpdJZzj9UH+5ePb3d/YV9m7YZr9
 xuVPD7znLJU7tTwgTpZAtDrh4LydGbJbgneRJK1bfOyFe9RRUuWF2VyGvNt3JzZSHAdT
 RVvTDJt55FQHvYDBlb/9jE/Xt8XOOtnU5zeox9U4WAlozucDQTJs8djdL3Qf8r7RwVva
 EX5/Va6EmsJDhe1iTI5sGtFbG6G5U/gM3LI5/1fC5PiX+qt5kSPL1LW9FgbqpwvyvA/y
 UeKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=ccBIAYaF5YF6SQyQAJ5wA8e5Jp6MMdcWuHN+9Dt7cdw=;
 b=X8PkgRYxu7ZSyoT4W+WigOrKW1nR6rTkFKcgVMA6hchjGS1in+AZfWSaU5eqKTY3Z7
 E3lG5IG6LLmnEuJF+S4JeX2XlYGBkdevN0SPk4tS1DNpBlCBoTBs2BrtngzfJYZXdQ2T
 Y5A1s/qTZOlOTndTKIKh7c1zb3eHDx5ApLgVCC0/OQemyU/DAo2BptZ+AdMDPKbB/Xi/
 EJTepnjHSX46t77QE0gPyL3vWHNJfwF46eckTcUd8NcZOuADWFzbCVXY9ajJewuXZZe9
 rRt6tAAg5u4w1afA0NNCfamgOK6crUEIHCTGsWXIF1ZWD+HDgCm5PRx5aKaLGK5wujIy
 iVYg==
X-Gm-Message-State: AOAM5310kLTwnO3VSqA04exYyFB2kSpBWbsHLJQ8GXcB7cBz0rYK4xpG
 3D9Xt9Wab6IV+ExsFh1FtSkSsrEB+A5oZOkfmFNaEmPu
X-Google-Smtp-Source: ABdhPJwthjU1v7Rpdh16iZL++cXe0fXgGinIWD2mS8gRLBXckDWwjJBdC8eDif82KEch7VMTBVZg0xAOk3kTp8ayehQ=
X-Received: by 2002:a17:906:93f7:b0:6cc:6319:6c43 with SMTP id
 yl23-20020a17090693f700b006cc63196c43mr718168ejb.176.1644980084199; Tue, 15
 Feb 2022 18:54:44 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
 <CALZpt+FwZTXEYYiJ=1XTXbDVECW41e9rNq8rn8AYr6m3yLAkPA@mail.gmail.com>
 <CAPfvXfJN9zeJDYka8BycU102xGdwQ2O9=Khgjag-eYLmXRdsdA@mail.gmail.com>
 <CALZpt+G0uXL04onty2N++6tWeX7Y=5KWw3x8-A0MvyUgZR-4Xw@mail.gmail.com>
 <CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
 <CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
 <CAD5xwhjGqEu5z1O0ho9pHnUD+woSKeGUxh+7rdHq5fPZU+mzww@mail.gmail.com>
In-Reply-To: <CAD5xwhjGqEu5z1O0ho9pHnUD+woSKeGUxh+7rdHq5fPZU+mzww@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 15 Feb 2022 20:54:28 -0600
Message-ID: <CAGpPWDa0hs2FWiE3VZ9Y4hKkEt6Up0oTgfKu3+N04h1Fn33DsA@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000094d69905d819c52a"
X-Mailman-Approved-At: Wed, 16 Feb 2022 13:35:05 +0000
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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: Wed, 16 Feb 2022 02:54:48 -0000

--00000000000094d69905d819c52a
Content-Type: text/plain; charset="UTF-8"

@Jeremy

 > there are technical reasons for sponsors to not be monotone. Mostly that
it requires the maintenance of an additional permanent TX-Index, making
Bitcoin's state grow at a much worse rate

What do you mean by monotone in the context of sponsor transactions? And when
you say tx-index, do you mean an index for looking up a transaction by its
ID? Is that not already something nodes do?

> The sponsors proposal is a change from Epsilon-Strong Reorgability to
Epsilon-Weak Reorgability

It doesn't look like you defined that term in your list. Did you mean what
you listed as "Epsilon: Simple Existential Reorgability"? If so, I would
say that should be sufficient. I'm not sure I would even distinguish
between the "strong" and "simple" versions of these things, tho you could
talk about things that make reorgs more or less computationally difficult
on a spectrum. As long as the computational difficulty isn't significant
for miners vs their other computational costs, the computation isn't really
a problem.

@Russell
> The current consensus threshold for transactions to become invalid is a
100 block reorg

What do you mean by this? The only 100 block period I'm aware of is the
coinbase cooldown period.

>  I promise to personally build a wallet that always creates transactions
on the verge of becoming invalid should anyone ever implement a feature
that violates this tx validity principle.

Could you explain how you would build a wallet like that with a sponsor
transaction as described by Jeremy? What damage do you think such a wallet
could do? As far as I can tell, such a wallet is very unlikely to do more
damage to the network than it does to the user of that wallet.

On Tue, Feb 15, 2022 at 3:39 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The difference between sponsors and this issue is more subtle. The issue
> Suhas raised was with a variant of sponsors trying to address a second
> criticism, not sponsors itself, which is secure against this.
>
> I think I can make this clear by defining a few different properties:
>
> Strong Reorgability: The transaction graph can be arbitrarily reorged into
> any series of blocks as long as dependency order/timelocks are respected.
> Simple Existential Reorgability: The transaction graph can be reorged into
> a different series of blocks, and it is not computationally difficult to
> find such an ordering.
> Epsilon-Strong Reorgability: The transaction graph can be arbitrarily
> reorged into any series of blocks as long as dependency order/timelocks are
> respected, up to Epsilon blocks.
> Epsilon: Simple Existential Reorgability: The transaction graph can be
> reorged into a different series of blocks, and it is not computationally
> difficult to find such an ordering, up to epsilon blocks.
> Perfect Reorgability: The transaction graph can be reorged into a
> different series of blocks, but the transactions themselves are already
> locked in.
>
> Perfect Reorgability doesn't exist in Bitcoin because unconfirmed
> transactions can be double spent which invalidates descendants. Notably,
> for a subset of the graph which is CTV Congestion control tree expansions,
> perfect reorg ability would exist, so it's not just a bullshit concept to
> think about :)
>
> The sponsors proposal is a change from Epsilon-Strong Reorgability to
> Epsilon-Weak Reorgability. It's not clear to me that there is any
> functional reason to rely on Strongness when Bitcoin's reorgability is
> already not Perfect, so a reorg generator with malicious intent can already
> disturb the tx graph. Epsion-Weak Reorgability seems to be a sufficient
> property.
>
> Do you disagree with that?
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
> On Tue, Feb 15, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>>> >> 2. (from Suhas) "once a valid transaction is created, it should not
>>> become invalid later on unless the inputs are double-spent."
>>> > This doesn't seem like a huge concern to me
>>>
>>> I agree that this shouldn't be a concern. In fact, I've asked numerous
>>> people in numerous places what practical downside there is to transactions
>>> that become invalid, and I've heard basically radio silence other than one
>>> off hand remark by satoshi at the dawn of time which didn't seem to me to
>>> have good reasoning. I haven't seen any downside whatsoever of transactions
>>> that can become invalid for anyone waiting the standard 6 confirmations -
>>> the reorg risks only exists for people not waiting for standard
>>> finalization. So I don't think we should consider that aspect of a
>>> sponsorship transaction that can only be mined with the transaction it
>>> sponsors to be a problem unless a specific practical problem case can be
>>> identified. Even if a significant such case was identified, an easy
>>> solution would be to simply allow sponsorship transactions to be mined on
>>> or after the sponsored transaction is mined.
>>>
>>
>> The downside is that in a 6 block reorg any transaction that is moved
>> past its expiration date becomes invalid and all its descendants become
>> invalid too.
>>
>> The current consensus threshold for transactions to become invalid is a
>> 100 block reorg, and I see no reason to change this threshold.  I promise
>> to personally build a wallet that always creates transactions on the verge
>> of becoming invalid should anyone ever implement a feature that violates
>> this tx validity principle.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">@Jeremy<div><br></div><div>=C2=A0&gt;=C2=A0<span style=3D"=
color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">there are technica=
l reasons for sponsors to not be monotone. Mostly that it requires the main=
tenance=C2=A0of an additional permanent TX-Index, making Bitcoin&#39;s stat=
e grow at a much worse=C2=A0rate</span></div><div><span style=3D"color:rgb(=
0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span =
style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">What do y=
ou mean by monotone in the context of sponsor transactions? And w</span><sp=
an style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">hen yo=
u say tx-index, do you mean an index for looking up a transaction by its ID=
? Is that not already something nodes do?=C2=A0</span></div><div><br><div>&=
gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-s=
erif">The sponsors proposal is a change from Epsilon-Strong Reorgability to=
 Epsilon-Weak Reorgability</span></div><div><span style=3D"color:rgb(0,0,0)=
;font-family:arial,helvetica,sans-serif"><br></span></div><div><span style=
=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">It doesn&#39;t=
 look like you defined that term in your list.</span>=C2=A0Did you mean wha=
t you listed as &quot;<span style=3D"color:rgb(0,0,0);font-family:arial,hel=
vetica,sans-serif">Epsilon: Simple Existential Reorgability&quot;? If so, I=
 would say that should be sufficient. I&#39;m not sure I would even disting=
uish between the &quot;strong&quot; and &quot;simple&quot; versions of thes=
e things, tho you could talk about things that make reorgs more or less com=
putationally difficult on a spectrum. As long as the computational difficul=
ty isn&#39;t significant for miners vs their other computational costs, the=
 computation isn&#39;t really a problem.</span></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><di=
v><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">@=
Russell</span></div><div>&gt; The current consensus threshold for transacti=
ons to become invalid is a 100 block reorg</div><div><br></div><div>What do=
 you mean by this? The only 100 block period I&#39;m aware of is the coinba=
se cooldown period.=C2=A0</div><div><br></div><div>&gt;=C2=A0 I promise to =
personally build a wallet that always creates transactions on the verge of =
becoming invalid should anyone ever implement a feature that violates this =
tx validity principle.</div><div><br></div><div>Could you explain how you w=
ould build a wallet like that with a sponsor transaction as described by Je=
remy? What damage do you think such a wallet could do? As far as I can tell=
, such a wallet is very unlikely to do more damage to the network than it d=
oes to the user of that wallet.=C2=A0</div></div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 15, 2022 at 3:=
39 PM Jeremy Rubin via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; wrote:<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"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><div class=3D"gmail_d=
efault">The difference between sponsors and this issue is more subtle. The =
issue Suhas raised was with a variant of sponsors trying to address a secon=
d criticism, not sponsors itself, which is secure against this.</div><div c=
lass=3D"gmail_default"><br></div><div class=3D"gmail_default">I think I can=
 make this clear by defining a few different properties:</div><div class=3D=
"gmail_default"><br></div><div class=3D"gmail_default">Strong Reorgability:=
 The transaction graph can be arbitrarily reorged into any series of blocks=
 as long as dependency order/timelocks are respected.</div><div class=3D"gm=
ail_default">Simple Existential Reorgability: The=C2=A0transaction graph ca=
n be reorged into a different series of blocks, and it is not computational=
ly difficult to find such an ordering.</div><div class=3D"gmail_default">Ep=
silon-Strong Reorgability: The transaction graph can be arbitrarily reorged=
 into any series of blocks as long as dependency order/timelocks are respec=
ted, up to Epsilon blocks.</div><div class=3D"gmail_default"><div class=3D"=
gmail_default">Epsilon: Simple Existential Reorgability: The=C2=A0transacti=
on graph can be reorged into a different series of blocks, and it is not co=
mputationally difficult to find such an ordering, up to epsilon blocks.</di=
v><div class=3D"gmail_default">Perfect Reorgability: The transaction graph =
can be reorged into a different series of blocks, but the transactions them=
selves are already locked in.</div><div class=3D"gmail_default"><br></div><=
div class=3D"gmail_default">Perfect Reorgability doesn&#39;t exist in Bitco=
in because unconfirmed transactions can be double spent which invalidates d=
escendants. Notably, for a subset of the graph which is CTV Congestion cont=
rol tree expansions, perfect reorg ability would exist, so it&#39;s not jus=
t a bullshit concept to think about :)</div><div class=3D"gmail_default"><b=
r></div><div class=3D"gmail_default">The sponsors proposal is a change from=
 Epsilon-Strong Reorgability to Epsilon-Weak Reorgability. It&#39;s not cle=
ar to me that there is any functional reason to rely on Strongness when Bit=
coin&#39;s reorgability is already not Perfect,=C2=A0so a reorg generator w=
ith malicious intent can already disturb the tx graph. Epsion-Weak Reorgabi=
lity=C2=A0seems to be a sufficient property.</div><div class=3D"gmail_defau=
lt"><br></div><div class=3D"gmail_default">Do you disagree with that?</div>=
<div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Best,</=
div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Jer=
emy</div></div></div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"lt=
r">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@Jer=
emyRubin</a><br></div></div></div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 15, 2022 at 12:25 PM Russell =
O&#39;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>&gt;&gt; 2. (from Su=
has) &quot;once a valid transaction is created, it should not become invali=
d later on unless the inputs are double-spent.&quot;</div>&gt; This doesn&#=
39;t seem like a huge concern to me=C2=A0<div><br></div><div>I agree that t=
his shouldn&#39;t be a concern. In fact, I&#39;ve asked numerous people in =
numerous places what practical downside there is to transactions that becom=
e invalid, and I&#39;ve heard basically radio silence other than one off ha=
nd remark by satoshi at the dawn of time which didn&#39;t seem to me to hav=
e good reasoning. I haven&#39;t seen any downside whatsoever of transaction=
s that can become invalid for anyone waiting the standard 6 confirmations -=
 the reorg risks only exists for people not waiting for standard finalizati=
on. So I don&#39;t think we should consider that aspect of a sponsorship tr=
ansaction that can only be mined with the transaction it sponsors to be a p=
roblem unless a specific=C2=A0practical problem case can be identified. Eve=
n if a significant such=C2=A0case was identified, an easy solution would be=
 to simply allow sponsorship transactions to be mined on or after the spons=
ored transaction is mined. <br></div></div></blockquote><div><br></div><div=
>The downside is that in a 6 block reorg any transaction that is moved past=
 its expiration date becomes invalid and all its descendants become invalid=
 too.<br></div><div><br></div><div>The current consensus threshold for tran=
sactions to become invalid is a 100 block reorg, and I see no reason to cha=
nge this threshold.=C2=A0 I promise to personally build a wallet that alway=
s creates transactions on the verge of becoming invalid should anyone ever =
implement a feature that violates this tx validity principle.<br></div></di=
v></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000094d69905d819c52a--