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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D0978C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 19:19:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id B8A94408A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 19:19:00 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gMbCI0rrAQd1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 19:19:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
[IPv6:2607:f8b0:4864:20::b2b])
by smtp4.osuosl.org (Postfix) with ESMTPS id F216E41677
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 19:18:59 +0000 (UTC)
Received: by mail-yb1-xb2b.google.com with SMTP id bt13so8270730ybb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Feb 2022 11:18:59 -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=6Ys/HnIWKvesQnNG8Hz8tTjvgZsEJ0W2ri+W+1xYR1U=;
b=RfWe2+76a/OzAU8lJ+fUiPClCzIY1gq+l048H8yx0hmKLbSoOcoBlh8UxA6BTjGsW5
ryAU9lXUdBOwGRWQg113bUeffiBIi85ympSM5JsDcwjklg1pTvpqyOmazqzkYWk5PWv0
7AxeqKdS428RceJX2I8XFRtyRLjvc0xpcpVeCPFUsZq/1xkKHR7NpKf+aHf1uh4W2R1c
08IjIHNUxsRHA2blPiRb5Ih1bEPquSaw7J7QQ3uXanF4+GtvMZXGHpzfEO1AZMhq6uLR
aVBDPXovo6usmnjAIHATZCrusmLkdTkWFmc1bK/9p6grn70phlDLt5t/KZlDu0bTVEXr
pJ0g==
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=6Ys/HnIWKvesQnNG8Hz8tTjvgZsEJ0W2ri+W+1xYR1U=;
b=QUfWaV7YU2vGw43sYoJCon1DgTAxNlLbRAMAPO0Czrv+0tN120KADpYGbWnm32ykP1
sDEF5DfurhT5Jbz5p6zsxbSjDJe6cqxmYLUPrsgq1A3IVLgdJcOluZKNaO+81qMl/94j
NypJcic3Up2Po9B8X94jH5UJVJSTBUV9HgfdqheaviswNwGusPvMJOFIWGrRSK0QHKgp
PG1ZqyxR/CPu6IuNFJKnJU6sZfSsdmSBBiKkKrCv2nvTvL9vNcdVTPV+Xs3dgg5Zyg+m
uz4CpIWgJJxiGLbPmrMDxZs6VyeZxExOisIfLVRU81+fGFeWITtkGj6/Rc7shtnXiH8X
pirA==
X-Gm-Message-State: AOAM531xr9yJMSH5Lu7mchX2YQq1l0I5OqNIe9jPNfh7du82qLDnPBn8
sE5lB1gVj9r1gDszekP1QZ9KQh4jvpRldsfWe1s=
X-Google-Smtp-Source: ABdhPJxHqJi19ySdXtCQNZtFlT7e9yYb8/gwuSHTuC6XxJAEME76pOtMicDyucUnzFKQ7sUPquX2GW38rk2LB4QvceI=
X-Received: by 2002:a25:76d1:0:b0:622:6d1c:ab0e with SMTP id
r200-20020a2576d1000000b006226d1cab0emr3758214ybc.680.1645039138850; Wed, 16
Feb 2022 11:18:58 -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>
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
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 19:19:00 -0000
--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">> 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>"monotonically" true at any point after=
the inclusion 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 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'=
;t true for all historical transactions. I <br>(embarrassingly) forgot this=
in the prior post. <br><br>The map of (txid -> transaction) for all tim=
e is a separate index that<br>must be enabled via the `-txindex=3D1` flag; =
it isn't enabled by default<br>because it isn't required for consen=
sus and its growth is unbounded.<br><br>> > The current consensus thr=
eshold for transactions 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 is<br>> 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 "regular" =
double-spend<br>via reorg I'll leave for another message. I'm not s=
ure that I understand<br>that myself. Personally I think if we hit a >10=
0 block reorg, we've got<br>bigger issues than coinbase invalidation.<b=
r></div></div>
--000000000000834f3505d82785b9--
|
