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: "James O'Beirne" <james.obeirne@gmail.com>
Date: Tue, 15 Feb 2022 15:53:13 -0500
Message-ID: <CAPfvXfJnDajpxjpnhXNZiBTLqBmNEmj5CdFNx8UxEE4R1ydepA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006b181d05d814b993"
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

--0000000000006b181d05d814b993
Content-Type: text/plain; charset="UTF-8"

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

Worth noting that the transaction sponsors design is no worse an
offender on this count than, say, CPFP is, provided we adopt the change
that sponsored txids are required to be included in the current block
*or* prior blocks. (The original proposal allowed current block only).

In other words, the sponsored txids are just "virtual inputs" to the
sponsor transaction.

This is a much different case than e.g. transaction expiry based on
wall-clock time or block height, which I agree complicates reorgs
significantly.

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

<div dir=3D"ltr">&gt; The downside is that in a 6 block reorg any transacti=
on that is moved<br>&gt; past its expiration date becomes invalid and all i=
ts descendants<br>&gt; become invalid too.<br><br>Worth noting that the tra=
nsaction sponsors design is no worse an<br>offender on this count than, say=
, CPFP is, provided we adopt the change<br>that sponsored txids are require=
d to be included in the current block<br>*or* prior blocks. (The original p=
roposal allowed current block only).<br><br>In other words, the sponsored t=
xids are just &quot;virtual inputs&quot; to the<br>sponsor transaction.<br>=
<br>This is a much different case than e.g. transaction expiry based on<br>=
wall-clock time or block height, which I agree complicates reorgs<br>signif=
icantly.<br></div>

--0000000000006b181d05d814b993--