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

--000000000000834f3505d82785b9
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; What do you mean by monotone in the =
context of sponsor transactions?<br><br>I take this to mean that the validi=
ty of a sponsor txn is<br>&quot;monotonically&quot; true at any point after=
 the inclusion 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 that not already something nodes do? <br><br>Indeed, not all no=
des have this ability. Each bitcoind node has a map<br>of unspent coins whi=
ch can be referenced by outpoint i.e.(txid, index),<br>but the same isn&#39=
;t true for all historical transactions. I <br>(embarrassingly) forgot this=
 in the prior post. <br><br>The map of (txid -&gt; transaction) for all tim=
e is a separate 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 consen=
sus and its growth is unbounded.<br><br>&gt; &gt; The current consensus thr=
eshold for transactions 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 is<br>&gt; the coinbase cooldown period. <br><br>If there were =
a reorg deeper than 100 blocks, it would permanently<br>invalidate any tran=
sactions spending the recently-matured coinbase<br>subsidy in any block bet=
ween $new_reorg_tip and ($former_tip_height -<br>100). These invalidated sp=
ends would not be able to be reorganized<br>into a new replacement chain.<b=
r><br>How this 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 s=
ure that I understand<br>that myself. Personally I think if we hit a &gt;10=
0 block reorg, we&#39;ve got<br>bigger issues than coinbase invalidation.<b=
r></div></div>

--000000000000834f3505d82785b9--