summaryrefslogtreecommitdiff
path: root/88/8ca4f0b0d0fb31a4276ec328b8fbd07064f433
blob: c30a564afa02f73161292c6b794307959a6c1027 (plain)
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
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
Return-Path: <aubergemediale@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 31776C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EA93641842
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EA93641842
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=OQZrbKYW
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C28d2KHNpwnN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:22 +0000 (UTC)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com
 [IPv6:2a00:1450:4864:20::633])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2721C40360
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Nov 2023 22:32:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2721C40360
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-9e213f198dfso243771866b.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 09 Nov 2023 14:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1699569140; x=1700173940;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=HRz2/qwDEX2YZ/VMEDeBmvXMY1ijpbyIH9E4AwEX/o4=;
 b=OQZrbKYWixs7n0jssy9KG6REHFu9qPE7CZfkgIC1QfJJopqFRrHskPjxQtVvo73r8Z
 YM7rU5sRQZBgA2NVNexxmE0GSnDAJ9kxo/ybqpVodYHAktruo8fw8U0fEFeoqiZfIFuf
 r+X72gdT02rZ0QFC7pGY7pFxdL/Oltyg7tuyMMZVpmFNmzrgA6KyuZF5VM9vwEQmiyuU
 FcfEgagJQiwUklTLwYRPmCrGnkohzcKMcAJ/CD0S2ajCaadNVXnvEwoiBq8RKVskLZvU
 eXa9IvYIsCYW5hhC+NkAUqMF4adt/pCAuymBVUdmfaUKTXHqzpQVSB+QAp9bO2iEYTaP
 onZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699569140; x=1700173940;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=HRz2/qwDEX2YZ/VMEDeBmvXMY1ijpbyIH9E4AwEX/o4=;
 b=rXf9U+Z+gRPv9cbJdgbPYn5d6Wf3h0vWN3QTI4u9tF9n4bS6449dE4DCGcpzDleDqn
 qnhKsSc8SNBW9UInF0NFrYQNxaYUtDzkA/ispQNexwpXW04ZmAzO/sTbci1wfw+vD+Z8
 sPoa8+e8GdgC+S5HiWiharzxBy/OBUCLa76dC6VOqvCvNAl2Ya/p3RvnN+YVLJrnfmAa
 CB7EU8y/crLbl17Rp+dzlxe8EBqdgQrhjt3FFwvFWk4vwAfGwRjI10wDNarrtLXgRbNn
 18SnHzZcWw0kOpZsQKT//P+LRzuAis5rPMCZCBCjIoWpXPa3os4moOd1oZ4tIlWZDOBh
 vKiA==
X-Gm-Message-State: AOJu0YzMXdHPFQ3EXcLXyIxovlXQtTXqNB4Ghc+9MgQ6VT9re5wdTn7e
 NYSJRJqwXJhSYrVfZ9t+xHaaEEylFxWUL4Mon8qGW1Z8
X-Google-Smtp-Source: AGHT+IFs6Q3bAoqaItbbG0v4NCEyPw9VcU3XEeSd/mOP0XGEycXpdQIJwccAlr2haSRakrRJ2hJkNZjbN6JbotiKoww=
X-Received: by 2002:a17:906:fe02:b0:9c7:58cd:b57 with SMTP id
 wy2-20020a170906fe0200b009c758cd0b57mr5133223ejb.37.1699569139960; Thu, 09
 Nov 2023 14:32:19 -0800 (PST)
MIME-Version: 1.0
References: <CANLPe+OQBsPiTrLEfz=SMxU8TkM_1XNfJQeq8gt2V6vDu=+Zxw@mail.gmail.com>
 <ZTaSwtvctmIiF74k@petertodd.org> <ZTawwRqGN4XUUu8C@camus>
 <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org>
 <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>
In-Reply-To: <CANLPe+NAd4imuGji7+o+Y3bWtC4aeTMNj0RrJw0Pu4=e6TEdeQ@mail.gmail.com>
From: Claus Ehrenberg <aubergemediale@gmail.com>
Date: Thu, 9 Nov 2023 23:32:10 +0100
Message-ID: <CANPykMqq-1Xh5WcHpKPeyfi6YAfjP2gJsO863K=D0yr2McT4aQ@mail.gmail.com>
To: Casey Rodarmor <casey@rodarmor.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dbd0bd0609bfc6d9"
X-Mailman-Approved-At: Thu, 09 Nov 2023 23:03:12 +0000
Subject: Re: [bitcoin-dev] Ordinals BIP PR
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: Thu, 09 Nov 2023 22:32:24 -0000

--000000000000dbd0bd0609bfc6d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I have developed nodes/wallets for Bitcoin and Bitcoin-derived Altcoins.
3rd-party Bitcoin developers take BIPs very seriously, basically as
must-implement/must-comply features.

Therefore, I think it would be best to restrict BIPs to the minimum
necessary to implement a complying node/wallet.

Cheers!

Claus

On Thu, Nov 9, 2023 at 1:43=E2=80=AFPM Casey Rodarmor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Luke is definitely entitled to his opinions about ordinals, and I
> certainly understand why people may not like ordinals and inscriptions.
>
> I don't think that ordinals are "nonsense", an "attack on Bitcoin", or
> that I'm dishonest, as Luke implies, or that my actions are an attempt to
> "harm/destroy Bitcoin".
>
> I think that whether or not ordinals are good is something about which
> reasonable people do and will disagree, and that an impartial BIP editor
> would recognize this above their own personal feelings about the matter.
>
> Also, regarding:
>
> > There is a debate on the PR whether the "technically unsound, ..., or
> not in keeping with the Bitcoin philosophy." or "must represent a net
> improvement." clauses (BIP 2) are relevant.
>
> As I said in my initial email, I think these standards are being applied
> in a way that they have not been to previous BIPs, which include all mann=
er
> of things, including changes to bitcoin which are nearly unanimously
> thought to be quite harmful if adopted.
>
> Best,
> Casey
>
> On Mon, Oct 23, 2023 at 11:35=E2=80=AFAM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Everything standardized between Bitcoin software is eligible to be and
>> should be a BIP. I completely disagree with the claim that it's used for
>> too many things.
>>
>> SLIPs exist for altcoin stuff. They shouldn't be used for things related
>> to Bitcoin.
>>
>> BOLTs also shouldn't have ever been a separate process and should really
>> just get merged into BIPs. But at this point, that will probably take
>> quite a bit of effort, and obviously cooperation and active involvement
>> from the Lightning development community.
>>
>> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time
>> to keep up. There are several PRs far more important than Ordinals
>> nonsense that need to be triaged and probably merged.
>>
>> The issue with Ordinals is that it is actually unclear if it's eligible
>> to be a BIP at all, since it is an attack on Bitcoin rather than a
>> proposed improvement. There is a debate on the PR whether the
>> "technically unsound, ..., or not in keeping with the Bitcoin
>> philosophy." or "must represent a net improvement." clauses (BIP 2) are
>> relevant. Those issues need to be resolved somehow before it could be
>> merged. I have already commented to this effect and given my own
>> opinions on the PR, and simply pretending the issues don't exist won't
>> make them go away. (Nor is it worth the time of honest people to help
>> Casey resolve this just so he can further try to harm/destroy Bitcoin.)
>>
>> Luke
>>
>>
>> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:
>> > On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev
>> wrote:
>> >> I have _not_ requested a BIP for OpenTimestamps, even though it is of
>> much
>> >> wider relevance to Bitcoin users than Ordinals by virtue of the fact
>> that much
>> >> of the commonly used software, including Bitcoin Core, is timestamped
>> with OTS.
>> >> I have not, because there is no need to document every single little
>> protocol
>> >> that happens to use Bitcoin with a BIP.
>> >>
>> >> Frankly we've been using BIPs for too many things. There is no
>> avoiding the act
>> >> that BIP assignment and acceptance is a mark of approval for a
>> protocol. Thus
>> >> we should limit BIP assignment to the minimum possible: _extremely_
>> widespread
>> >> standards used by the _entire_ Bitcoin community, for the core missio=
n
>> of
>> >> Bitcoin.
>> >>
>> > This would eliminate most wallet-related protocols e.g. BIP69 (sorted
>> > keys), ypubs, zpubs, etc. I don't particularly like any of those but i=
f
>> > they can't be BIPs then they'd need to find another spec repository
>> > where they wouldn't be lost and where updates could be tracked.
>> >
>> > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not
>> a BIP
>> > in part because of perceived friction and exclusivity of the BIPs repo=
.
>> > But I'm not thrilled with this situation.
>> >
>> > In fact, I would prefer that OpenTimestamps were a BIP :).
>> >
>> >> It's notable that Lightning is _not_ standardized via the BIP process=
.
>> I think
>> >> that's a good thing. While it's arguably of wide enough use to warren=
t
>> BIPs,
>> >> Lightning doesn't need the approval of Core maintainers, and using
>> their
>> >> separate BOLT process makes that clear.
>> >>
>> > Well, LN is a bit special because it's so big that it can have its own
>> > spec repo which is actively maintained and used.
>> >
>> > While it's technically true that BIPs need "approval of Core
>> maintainers"
>> > to be merged, the text of BIP2 suggests that this approval should be a
>> > functionary role and be pretty-much automatic. And not require the BIP
>> > be relevant or interesting or desireable to Core developers.
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Hello,<div><br></div><div>I have developed nodes/wallets f=
or Bitcoin and Bitcoin-derived Altcoins. 3rd-party Bitcoin developers take =
BIPs very seriously, basically as must-implement/must-comply features.</div=
><div><br></div><div>Therefore, I think it would be best to restrict BIPs t=
o the minimum necessary to implement a complying node/wallet.</div><div><br=
></div><div>Cheers!</div><div><br></div><div>Claus</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 9, 2023=
 at 1:43=E2=80=AFPM Casey Rodarmor via bitcoin-dev &lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif">Hi all,<br><br>Luke is definitely entitled to his opinio=
ns about ordinals, and I certainly understand why people may not like ordin=
als and inscriptions.<br><br>I don&#39;t think that ordinals are &quot;nons=
ense&quot;, an &quot;attack on Bitcoin&quot;, or that I&#39;m dishonest, as=
 Luke implies, or that my actions are an attempt to &quot;harm/destroy Bitc=
oin&quot;.<br><br>I think that whether or not ordinals are good is somethin=
g about which reasonable people do and will disagree, and that an impartial=
 BIP editor would recognize this above their own personal feelings about th=
e matter.<br><br>Also, regarding:<br><br>&gt; There is a debate on the PR w=
hether the &quot;technically unsound, ..., or not in keeping with the Bitco=
in philosophy.&quot; or &quot;must represent a net improvement.&quot; claus=
es (BIP 2) are relevant. <br><br>As I said in my initial email, I think the=
se standards are being applied in a way that they have not been to previous=
 BIPs, which include all manner of things, including changes to bitcoin whi=
ch are nearly unanimously thought to be quite harmful if adopted.<br><br>Be=
st,<br>Casey<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Mon, Oct 23, 2023 at 11:35=E2=80=AFAM Luke Dashjr =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<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">Everything standar=
dized between Bitcoin software is eligible to be and <br>
should be a BIP. I completely disagree with the claim that it&#39;s used fo=
r <br>
too many things.<br>
<br>
SLIPs exist for altcoin stuff. They shouldn&#39;t be used for things relate=
d <br>
to Bitcoin.<br>
<br>
BOLTs also shouldn&#39;t have ever been a separate process and should reall=
y <br>
just get merged into BIPs. But at this point, that will probably take <br>
quite a bit of effort, and obviously cooperation and active involvement <br=
>
from the Lightning development community.<br>
<br>
Maybe we need a 3rd BIP editor. Both Kalle and myself haven&#39;t had time =
<br>
to keep up. There are several PRs far more important than Ordinals <br>
nonsense that need to be triaged and probably merged.<br>
<br>
The issue with Ordinals is that it is actually unclear if it&#39;s eligible=
 <br>
to be a BIP at all, since it is an attack on Bitcoin rather than a <br>
proposed improvement. There is a debate on the PR whether the <br>
&quot;technically unsound, ..., or not in keeping with the Bitcoin <br>
philosophy.&quot; or &quot;must represent a net improvement.&quot; clauses =
(BIP 2) are <br>
relevant. Those issues need to be resolved somehow before it could be <br>
merged. I have already commented to this effect and given my own <br>
opinions on the PR, and simply pretending the issues don&#39;t exist won&#3=
9;t <br>
make them go away. (Nor is it worth the time of honest people to help <br>
Casey resolve this just so he can further try to harm/destroy Bitcoin.)<br>
<br>
Luke<br>
<br>
<br>
On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote:<br>
&gt; On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev w=
rote:<br>
&gt;&gt; I have _not_ requested a BIP for OpenTimestamps, even though it is=
 of much<br>
&gt;&gt; wider relevance to Bitcoin users than Ordinals by virtue of the fa=
ct that much<br>
&gt;&gt; of the commonly used software, including Bitcoin Core, is timestam=
ped with OTS.<br>
&gt;&gt; I have not, because there is no need to document every single litt=
le protocol<br>
&gt;&gt; that happens to use Bitcoin with a BIP.<br>
&gt;&gt;<br>
&gt;&gt; Frankly we&#39;ve been using BIPs for too many things. There is no=
 avoiding the act<br>
&gt;&gt; that BIP assignment and acceptance is a mark of approval for a pro=
tocol. Thus<br>
&gt;&gt; we should limit BIP assignment to the minimum possible: _extremely=
_ widespread<br>
&gt;&gt; standards used by the _entire_ Bitcoin community, for the core mis=
sion of<br>
&gt;&gt; Bitcoin.<br>
&gt;&gt;<br>
&gt; This would eliminate most wallet-related protocols e.g. BIP69 (sorted<=
br>
&gt; keys), ypubs, zpubs, etc. I don&#39;t particularly like any of those b=
ut if<br>
&gt; they can&#39;t be BIPs then they&#39;d need to find another spec repos=
itory<br>
&gt; where they wouldn&#39;t be lost and where updates could be tracked.<br=
>
&gt;<br>
&gt; The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not=
 a BIP<br>
&gt; in part because of perceived friction and exclusivity of the BIPs repo=
.<br>
&gt; But I&#39;m not thrilled with this situation.<br>
&gt;<br>
&gt; In fact, I would prefer that OpenTimestamps were a BIP :).<br>
&gt;<br>
&gt;&gt; It&#39;s notable that Lightning is _not_ standardized via the BIP =
process. I think<br>
&gt;&gt; that&#39;s a good thing. While it&#39;s arguably of wide enough us=
e to warrent BIPs,<br>
&gt;&gt; Lightning doesn&#39;t need the approval of Core maintainers, and u=
sing their<br>
&gt;&gt; separate BOLT process makes that clear.<br>
&gt;&gt;<br>
&gt; Well, LN is a bit special because it&#39;s so big that it can have its=
 own<br>
&gt; spec repo which is actively maintained and used.<br>
&gt;<br>
&gt; While it&#39;s technically true that BIPs need &quot;approval of Core =
maintainers&quot;<br>
&gt; to be merged, the text of BIP2 suggests that this approval should be a=
<br>
&gt; functionary role and be pretty-much automatic. And not require the BIP=
<br>
&gt; be relevant or interesting or desireable to Core developers.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</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>
_______________________________________________<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>

--000000000000dbd0bd0609bfc6d9--