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>
 <CAGpPWDa0hs2FWiE3VZ9Y4hKkEt6Up0oTgfKu3+N04h1Fn33DsA@mail.gmail.com>
 <CAPfvXfLFaBQnBixpK5+rMXw2BTxw0YGnR=6iTYUpZHt6X=5yNw@mail.gmail.com>
In-Reply-To: <CAPfvXfLFaBQnBixpK5+rMXw2BTxw0YGnR=6iTYUpZHt6X=5yNw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 16 Feb 2022 14:36:04 -0600
Message-ID: <CAGpPWDYpasB_N+tj2sGZa=s8faBNpWv2k8E6GE4Up4_ikdkOKA@mail.gmail.com>
To: "James O'Beirne" <james.obeirne@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000041e3be05d8289a8f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

--00000000000041e3be05d8289a8f
Content-Type: text/plain; charset="UTF-8"

>  the validity of a sponsor txn is "monotonically" true at any point after
the inclusion of the sponsored txn in a block.

Oh I see his point now. If sponsors were valid at any point in the future,
not only would a utxo index be needed but an index of all transactions.
Yeah, that wouldn't be good. And the solution of bounding the sponsor
transaction to be valid in some window after the transaction is included
doesn't solve the original point of making sponsor transactions never
become invalid. Thanks for the clarification James, and good point Jeremy.

On Wed, Feb 16, 2022 at 1:19 PM James O'Beirne <james.obeirne@gmail.com>
wrote:

> > What do you mean by monotone in the context of sponsor transactions?
>
> I take this to mean that the validity of a sponsor txn is
> "monotonically" true at any point after the inclusion of the sponsored
> txn in a block.
>
> > 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?
>
> Indeed, not all nodes have this ability. Each bitcoind node has a map
> of unspent coins which can be referenced by outpoint i.e.(txid, index),
> but the same isn't true for all historical transactions. I
> (embarrassingly) forgot this in the prior post.
>
> The map of (txid -> transaction) for all time is a separate index that
> must be enabled via the `-txindex=1` flag; it isn't enabled by default
> because it isn't required for consensus and its growth is unbounded.
>
> > > 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.
>
> If there were a reorg deeper than 100 blocks, it would permanently
> invalidate any transactions spending the recently-matured coinbase
> subsidy in any block between $new_reorg_tip and ($former_tip_height -
> 100). These invalidated spends would not be able to be reorganized
> into a new replacement chain.
>
> How this differs in practice or principle from a "regular" double-spend
> via reorg I'll leave for another message. I'm not sure that I understand
> that myself. Personally I think if we hit a >100 block reorg, we've got
> bigger issues than coinbase invalidation.
>

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

<div dir=3D"ltr">&gt;=C2=A0

the validity of a sponsor txn is &quot;monotonically&quot; true at any poin=
t after the inclusion of the sponsored txn in a block.<div><br></div><div>O=
h I see his point now. If sponsors=C2=A0were valid at any point in the futu=
re, not only would a utxo index be needed but an index of all transactions.=
 Yeah, that wouldn&#39;t be good. And the solution of bounding the sponsor =
transaction to be valid in some window after the transaction=C2=A0is includ=
ed doesn&#39;t solve the original point of making sponsor transactions=C2=
=A0never become invalid. Thanks for the clarification James, and good point=
 Jeremy.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Feb 16, 2022 at 1:19 PM James O&#39;Beirne &lt;<a h=
ref=3D"mailto:james.obeirne@gmail.com">james.obeirne@gmail.com</a>&gt; wrot=
e:<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"l=
tr"><div dir=3D"ltr">&gt; What do you mean by monotone in the context of sp=
onsor transactions?<br><br>I take this to mean that the validity of a spons=
or txn is<br>&quot;monotonically&quot; true at any point after the inclusio=
n of the sponsored<br>txn in a block.<br><br>&gt; And when you say tx-index=
, do you mean an index for looking up a<br>&gt; transaction by its ID? Is t=
hat not already something nodes do? <br><br>Indeed, not all nodes have this=
 ability. Each bitcoind node has a map<br>of unspent coins which can be ref=
erenced by outpoint i.e.(txid, index),<br>but the same isn&#39;t true for a=
ll historical transactions. I <br>(embarrassingly) forgot this in the prior=
 post. <br><br>The map of (txid -&gt; transaction) for all time is a separa=
te index that<br>must be enabled via the `-txindex=3D1` flag; it isn&#39;t =
enabled by default<br>because it isn&#39;t required for consensus and its g=
rowth is unbounded.<br><br>&gt; &gt; The current consensus threshold for tr=
ansactions to become invalid<br>&gt; &gt; is a 100 block reorg<br>&gt; <br>=
&gt; What do you mean by this? The only 100 block period I&#39;m aware of i=
s<br>&gt; the coinbase cooldown period. <br><br>If there were a reorg deepe=
r than 100 blocks, it would permanently<br>invalidate any transactions spen=
ding the recently-matured coinbase<br>subsidy in any block between $new_reo=
rg_tip and ($former_tip_height -<br>100). These invalidated spends would no=
t be able to be reorganized<br>into a new replacement chain.<br><br>How thi=
s differs in practice or principle from a &quot;regular&quot; double-spend<=
br>via reorg I&#39;ll leave for another message. I&#39;m not sure that I un=
derstand<br>that myself. Personally I think if we hit a &gt;100 block reorg=
, we&#39;ve got<br>bigger issues than coinbase invalidation.<br></div></div=
>
</blockquote></div>

--00000000000041e3be05d8289a8f--