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>
In-Reply-To: <CAGpPWDaZ=Qx_phzjFJXzQc0ePWfuJmGKsPrsvj9X1pBTBrRgWA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 15 Feb 2022 15:24:29 -0500
Message-ID: <CAMZUoKnhyzJ=6W-=hxpmCyjiPyYMuS=eKjLN+bu5cuLRQ42nxA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a5e02b05d81452ae"
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

--000000000000a5e02b05d81452ae
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=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>&gt;&gt; 2. (from=
 Suhas) &quot;once a valid transaction is created, it should not become inv=
alid later on unless the inputs are double-spent.&quot;</div>&gt; This does=
n&#39;t seem like a huge concern to me=C2=A0<div><br></div><div>I agree tha=
t this 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 be=
come invalid, and I&#39;ve heard 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 transact=
ions that can become invalid for anyone waiting the standard 6 confirmation=
s - the reorg risks only exists for people not waiting for standard finaliz=
ation. 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 sponsorship transactions to be mined on or after the sp=
onsored 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 p=
ast its expiration date becomes invalid and all its descendants become inva=
lid too.<br></div><div><br></div><div>The current consensus threshold for t=
ransactions 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 al=
ways creates transactions on the verge of becoming invalid should anyone ev=
er implement a feature that violates this tx validity principle.<br></div><=
/div></div>

--000000000000a5e02b05d81452ae--