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
Precedence: list

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