path: root/6b/e78a6aa2363db7c7a710839e80f672a8d762db

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1DFD0C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 21:38:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 19C3740129
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 21:38:26 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id E4Ph8HAwVaZm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 21:38:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [IPv6:2a00:1450:4864:20::132])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6C6BA400FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 21:38:24 +0000 (UTC)
Received: by mail-lf1-x132.google.com with SMTP id u20so156369lff.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 13:38:24 -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;
 bh=ACJlPYAo41gajLWA3eodcEWccfuVvHs3mfJXoLdYZO8=;
 b=VprZ69oQltYexK8hmz2b6eYWjGM26t9gnPPnMvOadbknNstIBgJE2oU9LmeOcJyaQw
 pGbYHaD7Idx0LkoscV/N2w6m+HgarL7dXC43ThYfOeG90kWnCX69m9I0nDU4BrmVRbNQ
 I9tf+ipvBq2AxN89WuKLPTRm2jm3ulVrKPVxUshX6DT/QyUlSx8KnFHbtVhoLWJuMwHK
 mZm3bIgbG71sX4zVMETDIsRo8+ws4PqXCL+64YoQ5R+B8XJWAnG/JcpZ7Ueuw4YvlK14
 YQ8v4tNZwROyL1LtEgsar4jr/83OqgMrbSOAoY+yX9Ka2xGkkWOIWgOuY8GAWNKytaQv
 F+Rw==
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;
 bh=ACJlPYAo41gajLWA3eodcEWccfuVvHs3mfJXoLdYZO8=;
 b=JiEyV5rVmNu5R3lseEsuxJ/FrwSB0fX7kH9Gh67O0htrXVpJnsV9eSbEOmCSLbtv/h
 2wshAUU9OgXUlF9++O/jZehUeh1fcgplh7rxXYpv9LMLkjNWUFverM27TIL5Nhk3lt5x
 +ssqjC7x5NBwmZZuIDfMPfYxdGtfIqUUJcOhn/q8PrB0S7U47eHkOS9sllj1o5FM0lr+
 AdjXhCYKIrbQ8qSVfy5wmacIORFeMQy7eew0ciWyFfbFOMcJd5kfc9NbWKL+r6YPGZkU
 LxX4cT2lxOO28aNodmTOK3zdMM4oJfikidQQEJzkf8rO6JYf6q0B2sjO+H2oH0d0bF78
 WgnQ==
X-Gm-Message-State: AOAM533grKaU9aSOfrh815sK0mxBx6VaHM2yBvkNu8ND0qoBCHEwArlZ
 5+QJa6t1PawhFzjPd4u3FlJqYiFFp2Z4cAXSHOHv9Y5tgaJV3g==
X-Google-Smtp-Source: ABdhPJwQFUijQ1Ot9ffN6ndZusuPttxFIPdbxj6hBx41Ytn67SgGJo0kkBxbsSHb+fBl1dMqn4cEnuxeI8hRBtBZXGw=
X-Received: by 2002:a05:6512:2288:: with SMTP id
 f8mr758293lfu.363.1644961102313; 
 Tue, 15 Feb 2022 13:38:22 -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>
In-Reply-To: <CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 15 Feb 2022 13:38:11 -0800
Message-ID: <CAD5xwhjGqEu5z1O0ho9pHnUD+woSKeGUxh+7rdHq5fPZU+mzww@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002c3b5c05d8155af5"
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: Tue, 15 Feb 2022 21:38:26 -0000

--0000000000002c3b5c05d8155af5
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><div class=3D"gmail_defau=
lt">The difference between sponsors and this issue is more subtle. The issu=
e Suhas raised was with a variant of sponsors trying to address a second cr=
iticism, not sponsors itself, which is secure against this.</div><div class=
=3D"gmail_default"><br></div><div class=3D"gmail_default">I think I can mak=
e this clear by defining a few different properties:</div><div class=3D"gma=
il_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"gmail_=
default">Simple Existential Reorgability: The=C2=A0transaction graph can be=
 reorged into a different series of blocks, and it is not computationally d=
ifficult to find such an ordering.</div><div class=3D"gmail_default">Epsilo=
n-Strong Reorgability: The transaction graph can be arbitrarily reorged int=
o any series of blocks as long as dependency order/timelocks are respected,=
 up to Epsilon blocks.</div><div class=3D"gmail_default"><div class=3D"gmai=
l_default">Epsilon: Simple Existential Reorgability: The=C2=A0transaction g=
raph can be reorged into a different series of blocks, and it is not comput=
ationally difficult to find such an ordering, up to epsilon blocks.</div><d=
iv class=3D"gmail_default">Perfect Reorgability: The transaction graph can =
be reorged into a different series of blocks, but the transactions themselv=
es are already locked in.</div><div class=3D"gmail_default"><br></div><div =
class=3D"gmail_default">Perfect Reorgability doesn&#39;t exist in Bitcoin b=
ecause unconfirmed transactions can be double spent which invalidates desce=
ndants. Notably, for a subset of the graph which is CTV Congestion control =
tree expansions, perfect reorg ability would exist, so it&#39;s not just a =
bullshit concept to think about :)</div><div class=3D"gmail_default"><br></=
div><div class=3D"gmail_default">The sponsors proposal is a change from Eps=
ilon-Strong Reorgability to Epsilon-Weak Reorgability. It&#39;s not clear t=
o me that there is any functional reason to rely on Strongness when Bitcoin=
&#39;s reorgability is already not Perfect,=C2=A0so a reorg generator with =
malicious intent can already disturb the tx graph. Epsion-Weak Reorgability=
=C2=A0seems to be a sufficient property.</div><div class=3D"gmail_default">=
<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">Jeremy<=
/div></div></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br>=
</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=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.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><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-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>&gt;&gt; 2. (from Suhas) &quot;once a valid tra=
nsaction is created, it should not become invalid later on unless the input=
s are double-spent.&quot;</div>&gt; This doesn&#39;t seem like a huge conce=
rn to me=C2=A0<div><br></div><div>I agree that this shouldn&#39;t be a conc=
ern. In fact, I&#39;ve asked numerous people in numerous places what practi=
cal downside there is to transactions that become invalid, and I&#39;ve hea=
rd basically radio silence other than one off hand remark by satoshi at the=
 dawn of time which didn&#39;t seem to me to have good reasoning. I haven&#=
39;t seen any downside whatsoever of transactions that can become invalid f=
or anyone waiting the standard 6 confirmations - the reorg risks only exist=
s for people not waiting for standard finalization. So I don&#39;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=C2=
=A0practical problem case can be identified. Even if a significant such=C2=
=A0case was identified, an easy solution would be to simply allow sponsorsh=
ip transactions to be mined on or after the sponsored 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 becom=
es invalid and all its descendants become invalid too.<br></div><div><br></=
div><div>The current consensus threshold for transactions to become invalid=
 is a 100 block reorg, and I see no reason to change this threshold.=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 v=
iolates this tx validity principle.<br></div></div></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>

--0000000000002c3b5c05d8155af5--