1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id EDEC6C0011
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 20:36:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id CDF1F83E4B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 20:36:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id e8klL0tUXDY4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 20:36:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
[IPv6:2a00:1450:4864:20::62d])
by smtp1.osuosl.org (Postfix) with ESMTPS id EED3283E4A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 20:36:23 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id gb39so1984894ejc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 12:36:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=baXYUtudHNIkHDqDva+P9NYfj+RWGqKDqWA8lhkg1gs=;
b=U9WhCqO6qxTkNKBEkdAj1SGttjokAYoJkBinYC++gj7ArttjB5hEn+ZCHTJ5A2isU3
VRlIHbLmdDcGzug4ObteJf7OmCY3duerCRecJsphTllhQDb6XO22I2TtOqsiE39L5Erd
T/NSk5rblNMNDkVW2+8Y4RAIfT4caT9MLBfHyyWEVgfcrYJyNKUck98mRi2oaFr9rxc4
zOclUxwkYy/c5+OQR8xpKKZA3+Zy6y2Q+52PVQ3qQpNbmtR8+hBaxdaCrLKHNmYQamJF
Eb88IwNy8VfkzJTI0IsyNYJh6KpHQbbUW/1ZnBUvylJTKtfdgu0p+RALG08AIxIh4QZ/
/CBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=baXYUtudHNIkHDqDva+P9NYfj+RWGqKDqWA8lhkg1gs=;
b=l/UY9JlhIMAaeqp7VHH+Kg9UIn8Zb59fqUn7KMx/UHXvi06R0NHRWdQN7wJ0ddYdiu
Xq1vu2iPFILE3mlAEEJC+Am/vkyVueh44bMyWb1HIqKKFJWys3YZVmOfnB1zwFK/MDA1
AL2Qyrj57njiu587hG2Iwgl+pU7YqFBHrspmf0gqBZUUd63jtG+ps67pKK1EGZ074dsI
KYo2/xzZRD7iRS5oZx2Pp5+nyKvHzpAqpIgzGDLZcxMo5gAymOvqeE6rRXGVgZBe7lEI
HtLO1IvK6xlywpT0CBKuru1If7/XRvOPoFk2TTu+vzebFLuBgs0KcnQ9ZRYKFJyJS+2r
M3kA==
X-Gm-Message-State: AOAM533caIZXijbyrHy5s0Dd/3lg7j/KhAXhwb2+Nu65UOgz38tVCo3C
5D4k3kTX+Djc6jw9yMbeP3tvcasg6kIzkY/A8KanrXatlyY=
X-Google-Smtp-Source: ABdhPJxFf5UFbRBMwhY/Ip3YOHxyB8San4w/Mfp9pJ44BALrXLpjl/5SVvon+DxfARDSw7Lli0/RXDd2tY+w40zL2x8=
X-Received: by 2002:a17:906:80c7:b0:6cf:9c76:1404 with SMTP id
a7-20020a17090680c700b006cf9c761404mr3631653ejx.207.1645043781852; Wed, 16
Feb 2022 12:36:21 -0800 (PST)
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"
X-Mailman-Approved-At: Wed, 16 Feb 2022 20:41:08 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Feb 2022 20:36:25 -0000
--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">>=C2=A0
the validity of a sponsor txn is "monotonically" 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'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'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'Beirne <<a h=
ref=3D"mailto:james.obeirne@gmail.com">james.obeirne@gmail.com</a>> 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">> 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>"monotonically" true at any point after the inclusio=
n of the sponsored<br>txn in a block.<br><br>> And when you say tx-index=
, do you mean an index for looking up a<br>> 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't true for a=
ll historical transactions. I <br>(embarrassingly) forgot this in the prior=
post. <br><br>The map of (txid -> transaction) for all time is a separa=
te index that<br>must be enabled via the `-txindex=3D1` flag; it isn't =
enabled by default<br>because it isn't required for consensus and its g=
rowth is unbounded.<br><br>> > The current consensus threshold for tr=
ansactions to become invalid<br>> > is a 100 block reorg<br>> <br>=
> What do you mean by this? The only 100 block period I'm aware of i=
s<br>> 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 "regular" double-spend<=
br>via reorg I'll leave for another message. I'm not sure that I un=
derstand<br>that myself. Personally I think if we hit a >100 block reorg=
, we've got<br>bigger issues than coinbase invalidation.<br></div></div=
>
</blockquote></div>
--00000000000041e3be05d8289a8f--
|
