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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B61B5CD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jun 2019 18:07:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 865397FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jun 2019 18:07:37 +0000 (UTC)
Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com
[209.85.208.42]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5OI7YFv013037
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jun 2019 14:07:35 -0400
Received: by mail-ed1-f42.google.com with SMTP id a14so22991052edv.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jun 2019 11:07:35 -0700 (PDT)
X-Gm-Message-State: APjAAAVrPmlBJ4sTp3JN50vknQe3Ltu13vVvnnSkaVVlskDZK0FBcNAD
9ZQDYF77Y4LiMdib/UZNKER7L7uw2jnd48pqQR0=
X-Google-Smtp-Source: APXvYqzxWCRhg7cHAbLkhMuXDoYzUGnlHfP79Ar7/m8mYELpRYdVpU84shg9B0rDyMbtiNsMjrGau5GBstJ1ZefgKDM=
X-Received: by 2002:a50:a5e7:: with SMTP id
b36mr139329678edc.301.1561399654191;
Mon, 24 Jun 2019 11:07:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
<20190605093039.xfo7lcylqkhsfncv@erisian.com.au>
<im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com>
<CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
<CAD5xwhj8o8Vbrk2KADBOFGfkD3fW3eMZo5aHJytGAj_5LLhYCg@mail.gmail.com>
<CAMZUoKkPUn01V7WruMqoYtwJ__ai-QPvD81ceoYC7j4+hC99gg@mail.gmail.com>
In-Reply-To: <CAMZUoKkPUn01V7WruMqoYtwJ__ai-QPvD81ceoYC7j4+hC99gg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 24 Jun 2019 11:07:20 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi6QU5OZwSGMp4P3q7OYZMMZRUZgd2YOiUnv5tqgJxPSA@mail.gmail.com>
Message-ID: <CAD5xwhi6QU5OZwSGMp4P3q7OYZMMZRUZgd2YOiUnv5tqgJxPSA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>
Content-Type: multipart/alternative; boundary="000000000000bd959f058c15afb1"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 25 Jun 2019 17:26:58 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 24 Jun 2019 18:07:38 -0000
--000000000000bd959f058c15afb1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Do you think the following hypothesis is more or less true:
H: There is no set of pure extensions* to script E such that enabling E and
OP_SECURETHEBAG as proposed enables recursive covenants, but E alone does
not enable recursive covenants?
* Of course there are things that specifically are specifically designed to
switch on if OP_SECURETHEBAG, so pure means normal things like OP_CAT that
are a function of the arguments on the stack or hashed txn data.
This is the main draw of the design I proposed, it should be highly
improbable or impossible to accidentally introduce more behavior than
intended with a new opcode.
I think that given that H is not true for the stack reading version of the
opcode, we should avoid doing it unless strongly motivated, so as to permit
more flexibility for which opcodes we can add in the future without
introducing recursion unless it is explicitly intended.
On Mon, Jun 24, 2019, 7:35 AM Russell O'Connor <roconnor@blockstream.io>
wrote:
> OP_SECURETHEBAG doesn't include the script being executed (i.e the
> scriptPubKey specified in the output that is redeemed by this input) in i=
ts
> hash like ordinary signatures do
> <https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cp=
p#L1271>.
> Of course, this ScriptPubKey is indirectly committed to through the input=
's
> prevoutpoint. However Script isn't able to reconstruct this script being
> executed from the prevoutpoint in tapscript without an implementation of
> public key tweeking in Bitcoin Script.
>
> On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin <jeremy.l.rubin@gmail.com>
> wrote:
>
>> Can you clarify this comment?
>>
>> We do in fact commit to the script and scriptsig itself (not the witness
>> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>>
>> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style
>>> of covenants if it pulled data from the stack, the OP_SECURETHEBAG
>>> probably cannot create covenants even if it were to pull the data from =
the
>>> stack unless some OP_TWEEKPUBKEY operation is added to Script because t=
he
>>> "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
>>>
>>> So with regards to OP_SECURETHEBAG, I am also "not really seeing any
>>> reason to complicate the spec to ensure the digest is precommitted as p=
art
>>> of the opcode."
>>>
>>> On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Good morning aj,
>>>>
>>>>
>>>> Sent with ProtonMail Secure Email.
>>>>
>>>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin=
al Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>>>> On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>> > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev
>>>> wrote:
>>>> >
>>>> > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG=
*.
>>>> >
>>>> > I think you could generalise that slightly and make it fit in
>>>> > with the existing opcode naming by calling it something like
>>>> > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
>>>> > consisting of a sha256 hash and a sighash-byte, and adding a new
>>>> sighash
>>>> > value corresponding to the set of info you want to include in the
>>>> hash,
>>>> > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT |
>>>> SIGHASH_ALL"
>>>> >
>>>> > FWIW, I'm not really seeing any reason to complicate the spec to
>>>> ensure
>>>> > the digest is precommitted as part of the opcode.
>>>> >
>>>>
>>>> I believe in combination with `OP_LEFT` and `OP_CAT` this allows
>>>> Turing-complete smart contracts, in much the same way as
>>>> `OP_CHECKSIGFROMSTACK`?
>>>>
>>>> Pass in the spent transaction (serialised for txid) and the spending
>>>> transaction (serialised for sighash) as part of the witness of the spe=
nding
>>>> transaction.
>>>>
>>>> Script verifies that the spending transaction witness value is indeed
>>>> the spending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT
>>>> OP_CHECKTXDIGESTVERIFY`.
>>>> Script verifies the spent transaction witness value is indeed the spen=
t
>>>> transaction by hashing it, then splitting up the hash with `OP_LEFT` i=
nto
>>>> bytes, and comparing the bytes to the bytes in the input of the spendi=
ng
>>>> transaction witness value (txid being the bytes in reversed order).
>>>>
>>>> Then the Script can extract a commitment of itself by extracting the
>>>> output of the spent transaction.
>>>> This lets the Script check that the spending transaction also pays to
>>>> the same script.
>>>>
>>>> The Script can then access a state value, for example from an
>>>> `OP_RETURN` output of the spent transaction, and enforce that a correc=
t
>>>> next-state is used in the spending transaction.
>>>> If the state is too large to fit in a standard `OP_RETURN`, then the
>>>> current state can be passed in as a witness and validated against a ha=
sh
>>>> commitment in an `OP_RETURN` output.
>>>>
>>>> I believe this is the primary reason against not pulling data from the
>>>> stack.
>>>>
>>>> Regards,
>>>> ZmnSCPxj
>>>> _______________________________________________
>>>> 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
>>>
>>
--000000000000bd959f058c15afb1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto">Do you think the following hypothesis i=
s more or less true:</div><div dir=3D"auto"><br></div><div dir=3D"auto">H: =
There is no set of pure extensions* to script E such that enabling E and OP=
_SECURETHEBAG as proposed enables recursive covenants, but E alone does not=
enable recursive covenants?</div><div dir=3D"auto">=C2=A0</div>* Of course=
there are things that specifically are specifically designed to switch on =
if OP_SECURETHEBAG, so pure means normal things like OP_CAT that are a func=
tion of the arguments on the stack or hashed txn data.=C2=A0<div dir=3D"aut=
o"><br></div><div dir=3D"auto">This is the main draw of the design I propos=
ed, it should be highly improbable or impossible to accidentally introduce =
more behavior than intended with a new opcode.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">I think that given that H is not true for the stack =
reading version of the opcode, we should avoid doing it unless strongly mot=
ivated, so as to permit more flexibility for which opcodes we can add in th=
e future without introducing recursion unless it is explicitly intended.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br><br><div class=
=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Mon,=
Jun 24, 2019, 7:35 AM Russell O'Connor <<a href=3D"mailto:roconnor@=
blockstream.io">roconnor@blockstream.io</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><span class=3D"m_2250=
439416008956349gmail-m_7434839216018036533m_-216577082455711303m_2651264282=
820171888gmail-im"><span class=3D"m_2250439416008956349gmail-m_743483921601=
8036533m_-216577082455711303m_2651264282820171888gmail-im">OP_SECURETHEBAG =
doesn't include the script being executed (i.e the scriptPubKey specifi=
ed in the output that is redeemed by this input) in its hash like <a href=
=3D"https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.c=
pp#L1271" target=3D"_blank" rel=3D"noreferrer">ordinary signatures do</a>.=
=C2=A0 Of course, this ScriptPubKey is indirectly committed to through the =
input's prevoutpoint.=C2=A0 However Script isn't able to reconstruc=
t this script being executed from the <span class=3D"m_2250439416008956349g=
mail-m_7434839216018036533m_-216577082455711303m_2651264282820171888gmail-i=
m"><span class=3D"m_2250439416008956349gmail-m_7434839216018036533m_-216577=
082455711303m_2651264282820171888gmail-im">prevoutpoint in tapscript withou=
t an implementation of public key tweeking in Bitcoin Script.<br></span></s=
pan></span></span></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin <<a href=
=3D"mailto:jeremy.l.rubin@gmail.com" target=3D"_blank" rel=3D"noreferrer">j=
eremy.l.rubin@gmail.com</a>> 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"><div dir=3D"ltr"><div dir=3D"auto"><div>Can you clar=
ify this comment?</div><div><br></div><div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">We do in fact commit=
to the script and scriptsig itself (not the witness stack) in OP_SECURETHE=
BAG (unless I'm missing what you meant)?</div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 20, 2019, 10:59 AM =
Russell O'Connor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>Just to be clear, while <span c=
lass=3D"m_2250439416008956349gmail-m_7434839216018036533m_-2165770824557113=
03m_2651264282820171888gmail-im">OP_CHECKTXDIGESTVERIFY would enable this s=
tyle of covenants if it pulled data from the stack, the <span class=3D"m_22=
50439416008956349gmail-m_7434839216018036533m_-216577082455711303m_26512642=
82820171888gmail-im">OP_SECURETHEBAG probably cannot create covenants even =
if it were to pull the data from the stack unless some OP_TWEEKPUBKEY opera=
tion is added to Script because the "commitment of the script itself&q=
uot; isn't part of the OP_SECURETHEBAG.</span></span></div><div><span c=
lass=3D"m_2250439416008956349gmail-m_7434839216018036533m_-2165770824557113=
03m_2651264282820171888gmail-im"><span class=3D"m_2250439416008956349gmail-=
m_7434839216018036533m_-216577082455711303m_2651264282820171888gmail-im"><b=
r></span></span></div><div><span class=3D"m_2250439416008956349gmail-m_7434=
839216018036533m_-216577082455711303m_2651264282820171888gmail-im"><span cl=
ass=3D"m_2250439416008956349gmail-m_7434839216018036533m_-21657708245571130=
3m_2651264282820171888gmail-im">So with regards to OP_SECURETHEBAG, I am al=
so<span class=3D"m_2250439416008956349gmail-m_7434839216018036533m_-2165770=
82455711303m_2651264282820171888gmail-im"> "not really seeing any reas=
on to complicate the spec to ensure the digest is precommitted as part of t=
he opcode."</span></span></span></div><div><span class=3D"m_2250439416=
008956349gmail-m_7434839216018036533m_-216577082455711303m_2651264282820171=
888gmail-im"><span class=3D"m_2250439416008956349gmail-m_743483921601803653=
3m_-216577082455711303m_2651264282820171888gmail-im"></span></span></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noreferrer" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> 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">Good morning aj,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br>
On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noref=
errer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrot=
e:<br>
<br>
> On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote=
:<br>
><br>
> > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBA=
G*.<br>
><br>
> I think you could generalise that slightly and make it fit in<br>
> with the existing opcode naming by calling it something like<br>
> "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the s=
tack,<br>
> consisting of a sha256 hash and a sighash-byte, and adding a new sigha=
sh<br>
> value corresponding to the set of info you want to include in the hash=
,<br>
> which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGH=
ASH_ALL"<br>
><br>
> FWIW, I'm not really seeing any reason to complicate the spec to e=
nsure<br>
> the digest is precommitted as part of the opcode.<br>
><br>
<br>
I believe in combination with `OP_LEFT` and `OP_CAT` this allows Turing-com=
plete smart contracts, in much the same way as `OP_CHECKSIGFROMSTACK`?<br>
<br>
Pass in the spent transaction (serialised for txid) and the spending transa=
ction (serialised for sighash) as part of the witness of the spending trans=
action.<br>
<br>
Script verifies that the spending transaction witness value is indeed the s=
pending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT OP_CHE=
CKTXDIGESTVERIFY`.<br>
Script verifies the spent transaction witness value is indeed the spent tra=
nsaction by hashing it, then splitting up the hash with `OP_LEFT` into byte=
s, and comparing the bytes to the bytes in the input of the spending transa=
ction witness value (txid being the bytes in reversed order).<br>
<br>
Then the Script can extract a commitment of itself by extracting the output=
of the spent transaction.<br>
This lets the Script check that the spending transaction also pays to the s=
ame script.<br>
<br>
The Script can then access a state value, for example from an `OP_RETURN` o=
utput of the spent transaction, and enforce that a correct next-state is us=
ed in the spending transaction.<br>
If the state is too large to fit in a standard `OP_RETURN`, then the curren=
t state can be passed in as a witness and validated against a hash commitme=
nt in an `OP_RETURN` output.<br>
<br>
I believe this is the primary reason against not pulling data from the stac=
k.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
</div>
</blockquote></div></div>
</blockquote></div></div></div>
--000000000000bd959f058c15afb1--
|