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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
Return-Path: <manecosta@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1491CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jun 2022 15:54:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id CF3D84092E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jun 2022 15:54:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CF3D84092E
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=FDDgO84N
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
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 W60870Zoj3W2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jun 2022 15:54:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 15A2A4091D
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
[IPv6:2a00:1450:4864:20::42f])
by smtp4.osuosl.org (Postfix) with ESMTPS id 15A2A4091D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jun 2022 15:54:15 +0000 (UTC)
Received: by mail-wr1-x42f.google.com with SMTP id q9so11566932wrd.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jun 2022 08:54:15 -0700 (PDT)
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=7puIEwHpIZXgIr6rwO5+NUKo3mFs+LLAS3VXt1R6wTo=;
b=FDDgO84NOOf4as3+99m8NnBEKgFi8ckDOWeDscycFJCgXAfnxN9mOAFaV8SYEqeB0j
ClDTmZgQqaOGQB605Y21g86QXLbL2rBp9kVE3fwhJu0OFbCQpMY2xyA9AZzlBY98IMBX
pu5H/5Gm47uziViutb30MtDyv34jR+BFqzM/DYc+epu8jZJa+SdnfkFl055OfqxVXhlF
BNQPOEmRBuB4pBEW1xAxTyw6nNbNqzl0M3hI34svwCJPYkRl8gTCNaQBk3OZurIzWsDW
2IwwiEXVjbbJRUGE+KE+ZcY2xvj8FzqhSAWXnr9MVvfPreK5y9YK1M7bPugWts8dsxt5
OrfQ==
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=7puIEwHpIZXgIr6rwO5+NUKo3mFs+LLAS3VXt1R6wTo=;
b=h/6bfExsj2ILFp3DTnzbTuKocJeiS3aa3rOq/pDGgtfh5d2P8oJ2w+WiL2VkqK89In
024XUCZVW0qppBPcY18IrvyRVhkqGofS62Q2L/eMkhEkpFpkExQxTUdtUqj1riKJdLK/
wvh9DJSdpbv5u5ka2ouag0lwgUO6C9cByPcMMSLLQXnAP4RqaQplSu9uSwL8guJmqTt8
tI2EweKjfybSdg1xZkB/d8wz5rRigS8JWLKJNKxuozcj0hzoDDvd71zLrFupUdDUwbrP
2iztksWX+a4rOOdrLThp4iO7cer3InhOZitXNF2Pur8pfmZlfzlART9X5LwBdn+dVwOq
ELkw==
X-Gm-Message-State: AJIora/YzHJ9/Sr29LoYajY8ummHy+C02Q/Zhqk+uPpmDIEGeia7xqUA
E9EWlDHs8LHzvT1ANS2YEeErmqsnorr9za2DCQw=
X-Google-Smtp-Source: AGRyM1v2kpk8NFzYpn/aQDSYqDT1ceq/vn/jZtGJIycWIzIHOzWsFas7aiONkidXPB2JuZ/Sugl12/JoZFmH60rqvCA=
X-Received: by 2002:a5d:6608:0:b0:21a:374d:786a with SMTP id
n8-20020a5d6608000000b0021a374d786amr16682579wru.418.1655654054171; Sun, 19
Jun 2022 08:54:14 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
<CAHTn92zw_MaSKWiZGhGFqFYXJxv6kQ+7=XCHbRLim1jhtEsVVQ@mail.gmail.com>
<CAJowKgJ8GP4Ykzn5dMHZ7wsE04YmpOLgTpdc9tgfVng0qB0Jjg@mail.gmail.com>
<YqVfTU0M7XN8+Ybu@petertodd.org>
<Pwr9EFLSv2rU7nXRzqFuw2LPxpFo22g_qYy4reQzpMuSlgRzTG536uLjZCc9sI43olReGMA7BFgjnxJGKtZNtxU7qRy_-YYOnz6TeMy4h8Q=@protonmail.com>
<Yq77CnxOhr615ip8@petertodd.org>
In-Reply-To: <Yq77CnxOhr615ip8@petertodd.org>
From: Manuel Costa <manecosta@gmail.com>
Date: Sun, 19 Jun 2022 16:54:03 +0100
Message-ID: <CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c517b805e1ceff11"
X-Mailman-Approved-At: Sun, 19 Jun 2022 18:04:19 +0000
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
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: Sun, 19 Jun 2022 15:54:18 -0000
--000000000000c517b805e1ceff11
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
"Long time listener, first time caller". Just sharing my 2 sats:
While I find it stimulating, I think this discussion (and other similar
doom-like scenarios) is somewhat irrelevant in practice.
When the time comes and if we start seeing issues with block rewards being
too low to maintain acceptable security, we're going to have multiple
solutions being implemented for it, and definitely a hard fork to
indefinitely maintain some degree of block subsidy is going to be within
them.
If it is indeed confirmed that the original chain is now insecure,
consensus should eventually coalesce in one of the hard forks that can
actually keep moving forward with some degree of security assurance.
I feel like people sometimes think of these systems as when they fail
there's a full loss, but that's not the case as the history is not lost,
and so we can move forward from that history with multiple alternatives and
allow the social/economic consensus to dictate which one becomes the new
accepted chain.
The genie is out of the box, and some chain whose history is prefixed by
Bitcoin's current chain history will always exist.
The only type of problems we should truly be worrying about are ones that
might invalidate the security of the history itself, like a cryptographic
breakthrough (quantum computing for example) that would turn some or all
utxos into "anyone can spend".
Transitions might be disorderly and filled with drama and discussion as the
"block size wars" in 2017, but anyone who doesn't want to "vote", can
always just keep their utxos frozen in place while the drama sorts itself
out, and maintain whatever holdings they previously had on the new accepted
chain.
Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreveu
no dia domingo, 19/06/2022 =C3=A0(s) 11:32:
> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
> > Hi Peter,
> >
> > > Only because the block reward goes away. If it was made to continue
> > > indefinitely - most likely with an inflation hard fork - demand for
> block space
> > > would not be critical to Bitcoin's security.
> >
> >
> > I am not completely against your proposal although 100% sure this will
> not have "consensus" to be implemented. I think if bitcoin doesn't have
> enough demand for block space, it should die. I will be sad if bitcoin
> doesn't exist but it should be a lesson for all the people opposing soft
> forks based on drama and politics instead of technical review.
> >
> > I don't see anything wrong with users paying 100x fees for opening and
> closing LN channels.
>
> The PoW security of Bitcoin benefits all Bitcoin users, proportional to t=
he
> value of BTC they hold; if Bitcoin blocks aren't reliably created the
> value of
> *all* BTC goes down. It doesn't make sense for the entire cost of that
> security
> to be paid for on a per-tx basis. And there's a high chance paying for it
> on a
> per-tx basis won't work anyway due to lack of consistent demand.
>
> It would be extremely unfortunate if one of the very few decentralized
> ways to
> store value died simply because we couldn't find a way to pay to keep it
> secure.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000c517b805e1ceff11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"Long time listener, first time caller". Just sh=
aring my 2 sats:<br><br>While I find it stimulating, I think this discussio=
n (and other similar doom-like scenarios) is somewhat irrelevant in practic=
e.<div><br></div><div>When the time comes and if we start seeing issues wit=
h block rewards being too low to maintain acceptable security, we're go=
ing to have multiple solutions being implemented for it, and definitely a h=
ard fork to indefinitely maintain some degree of block subsidy is going to =
be within them.<br>If it is indeed confirmed that the original chain is now=
insecure, consensus should eventually coalesce=C2=A0in one of the hard for=
ks that can actually keep moving forward with some degree of security assur=
ance.</div><div><br></div><div>I feel like people sometimes think of these =
systems as when they fail there's a full loss, but that's not the c=
ase as the history is not lost, and so we can move forward from that histor=
y with multiple alternatives and allow the social/economic consensus to dic=
tate which one becomes the new accepted chain.<br>The genie is out of the b=
ox, and some chain whose history is prefixed by Bitcoin's current chain=
history will always exist.<br>The only type of problems we should truly be=
worrying about are ones that might invalidate the security of the history =
itself, like a cryptographic breakthrough (quantum computing for example) t=
hat would turn some or all utxos into "anyone can spend".<br><br>=
Transitions might be disorderly and filled with drama and discussion as the=
"block size wars" in 2017, but anyone who doesn't want to &q=
uot;vote", can always just keep their utxos frozen in place while the =
drama sorts itself out, and maintain whatever holdings they previously had =
on the new accepted chain.</div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Peter Todd via bitcoin-dev <<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat=
ion.org</a>> escreveu no dia domingo, 19/06/2022 =C3=A0(s) 11:32:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Jun 12, 2022 a=
t 07:16:49PM +0000, alicexbt wrote:<br>
> Hi Peter,<br>
> <br>
> > Only because the block reward goes away. If it was made to contin=
ue<br>
> > indefinitely - most likely with an inflation hard fork - demand f=
or block space<br>
> > would not be critical to Bitcoin's security.<br>
> <br>
> <br>
> I am not completely against your proposal although 100% sure this will=
not have "consensus" to be implemented. I think if bitcoin doesn=
't have enough demand for block space, it should die. I will be sad if =
bitcoin doesn't exist but it should be a lesson for all the people oppo=
sing soft forks based on drama and politics instead of technical review.<br=
>
> <br>
> I don't see anything wrong with users paying 100x fees for opening=
and closing LN channels.<br>
<br>
The PoW security of Bitcoin benefits all Bitcoin users, proportional to the=
<br>
value of BTC they hold; if Bitcoin blocks aren't reliably created the v=
alue of<br>
*all* BTC goes down. It doesn't make sense for the entire cost of that =
security<br>
to be paid for on a per-tx basis. And there's a high chance paying for =
it on a<br>
per-tx basis won't work anyway due to lack of consistent demand.<br>
<br>
It would be extremely unfortunate if one of the very few decentralized ways=
to<br>
store value died simply because we couldn't find a way to pay to keep i=
t<br>
secure.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000c517b805e1ceff11--
|
