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
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BFD4C8D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 18:31:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25CDE170
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 18:31:37 +0000 (UTC)
Received: by igbdj2 with SMTP id dj2so1232119igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 11:31:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=F3r+aOTrAWZOCM0SyfTQPLL4Br+sjJ5HbFwCRtwLdzE=;
b=B+zQ0mImp+iOAs921+EYxP83nmu88ai6xUVAQfr5YGBZIn0qZjB0WYYOHEpePLNSyD
PEUPTaiQK+k5azdBspxm9/x7I9d9c2LpcIDeoC6HQiCSpLVCNN+Ts/0VIDdoDzasFqXJ
4wp0vQzMH6x4gcAt3MKbO/p8i+yiNr4Lj9SMjSTKDZhJ0242HFSt7J7frT2Gy7+HsYEy
HurK67IDykc+sEGnkEF2yLRVi1daoyNJC7qXfdaIIxJYPS0M5P/3LHzBkph26pscdDh3
SRgsullpMeYoGDaDAedmBJZmUHReuX8cffo3jwY9CZOcNWNZ7po/nV4uCnY9MtPINcHS
fLfg==
X-Gm-Message-State: ALoCoQluZqn9jBE1FkXt+bnX/e38bnGP+Mu1V+UfrNc1ZTm6LrNddmvpIWdGJ3L0HXaCBbuETKOJ
X-Received: by 10.50.73.196 with SMTP id n4mr453691igv.46.1444933896542; Thu,
15 Oct 2015 11:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.171.5 with HTTP; Thu, 15 Oct 2015 11:31:17 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>
References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au>
<20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au>
<CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com>
<CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com>
<CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 15 Oct 2015 11:31:17 -0700
Message-ID: <CAOG=w-uhA+2EduF5rAHJwv7aHXd3VBAJrcxEsHh-+EF2x-u=CA@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e01182526a0fd6e052228e347
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
motivate the change
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 15 Oct 2015 18:31:38 -0000
--089e01182526a0fd6e052228e347
Content-Type: text/plain; charset=UTF-8
Adam, there is really no justification I can see to lower the interblock
interval on the Bitcoin blockchain, primarily due to the effects of network
latency. Lowering the interblock interval and raising the block size are
not equal alternatives - you can always get more throughput in bitcoin by
raising the block size than by lowering the interblock time. And that's
without considering the effect shorter intervals would have on e.g. SPV
client bandwidth or sidechain connectivity proofs. So I find it very
unlikely that such granularity would ever be needed on the Bitcoin block
chain, although if were to happen then extra bits from nSequence could be
used in a soft-fork compatible way.
However it is true that various sidechains such as Liquid will have a much
shorter interblock interval than 10min, as well as customer demand for
protocols with shorter timeouts. It would be nice if such systems did not
HAVE to resort to complex bit shifting to support more precision, and if
protocols written for bitcoin could be reused on such systems with minimal
or no modification.
To that end, it might be preferable to move the flag bit indicating use of
seconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22
to provide higher granularity in a sidechain environment. This keeps the
size of a stack push to 3 bytes while also keeping sufficient room for
high-order bits of relative lock-time in a sidechain that supports shorter
block intervals.
Another alternative is to put the units flag in the least significant bit,
which has the advantage of allowing both units of lock-time to make use of
1-2 byte pushes, but the disadvantage of making lock times of 64..127
2-bytes instead of 1-byte.
Thoughts?
On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Does that pre-judge that block interval would never change from
> 10mins? Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> > * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
> >
> > /* In order to use the same number of bits to encode roughly the
> > * same wall-clock duration, and because blocks are naturally
> > * limited to occur every 600s on average, the minimum granularity
> > * for time-based relative lock-time is fixed at 512 seconds.
> > * Converting from CTxIn::nSequence to seconds is performed by
> > * multiplying by 512 = 2^9, or equivalently shifting up by
> > * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete@petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks! It's good to have such ideas as a compass. PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK. We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> _______________________________________________
> >>> 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
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e01182526a0fd6e052228e347
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>Adam, there is really no justification=
I can see to lower the interblock interval on the Bitcoin blockchain, prim=
arily due to the effects of network latency. Lowering the interblock interv=
al and raising the block size are not equal alternatives - you can always g=
et more throughput in bitcoin by raising the block size than by lowering th=
e interblock time. And that's without considering the effect shorter in=
tervals would have on e.g. SPV client bandwidth or sidechain connectivity p=
roofs. So I find it very unlikely that such granularity would ever be neede=
d on the Bitcoin block chain, although if were to happen then extra bits fr=
om nSequence could be used in a soft-fork compatible way.<br><br></div>Howe=
ver it is true that various sidechains such as Liquid will have a much shor=
ter interblock interval than 10min, as well as customer demand for protocol=
s with shorter timeouts. It would be nice if such systems did not HAVE to r=
esort to complex bit shifting to support more precision, and if protocols w=
ritten for bitcoin could be reused on such systems with minimal or no modif=
ication.<br><br></div>To that end, it might be preferable to move the flag =
bit indicating use of seconds from bit 16 to bit 23 and (by convention only=
) reserve bits 17..22 to provide higher granularity in a sidechain environm=
ent. This keeps the size of a stack push to 3 bytes while also keeping suff=
icient room for high-order bits of relative lock-time in a sidechain that s=
upports shorter block intervals.<br><br></div>Another alternative is to put=
the units flag in the least significant bit, which has the advantage of al=
lowing both units of lock-time to make use of 1-2 byte pushes, but the disa=
dvantage of making lock times of 64..127 2-bytes instead of 1-byte.<br><br>=
</div>Thoughts?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Does that pre-judge that block interval wo=
uld never change from<br>
10mins?=C2=A0 Eg say with IBLT or fountain codes etc and security arguments=
<br>
for the current limitations of them are found, such that orphan rates<br>
can remain low in a decentralised way with 1min blocks, then the<br>
locktime granularity would be coarse relative to the block interval<br>
(with 512s locktime granularity.<br>
<br>
Adam<br>
<br>
On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev<br>
<div class=3D"HOEnZb"><div class=3D"h5"><<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wro=
te:<br>
> Alex,<br>
><br>
> I am sorry for not communicating more clearly. Mark and I discussed yo=
ur<br>
> concerns from the last meeting and he made the change. The BIP text st=
ill<br>
> needs to be updated, but the discussed change was added to the PR, alb=
eit<br>
> squashed making it more non-obvious. BIP68 now explicitly uses 16 bits=
with<br>
> a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and<br>
> SEQUENCE_LOCKTIME_GRANULARITY in the PR<br>
> <a href=3D"https://github.com/bitcoin/bitcoin/pull/6312" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6312</a>.<b=
r>
><br>
>=C2=A0 =C2=A0 =C2=A0/* If CTxIn::nSequence encodes a relative lock-time=
, this mask is<br>
>=C2=A0 =C2=A0 =C2=A0 * applied to extract that lock-time from the seque=
nce field. */<br>
>=C2=A0 =C2=A0 =C2=A0static const uint32_t SEQUENCE_LOCKTIME_MASK =3D 0x=
0000ffff;<br>
><br>
>=C2=A0 =C2=A0 =C2=A0/* In order to use the same number of bits to encod=
e roughly the<br>
>=C2=A0 =C2=A0 =C2=A0 * same wall-clock duration, and because blocks are=
naturally<br>
>=C2=A0 =C2=A0 =C2=A0 * limited to occur every 600s on average, the mini=
mum granularity<br>
>=C2=A0 =C2=A0 =C2=A0 * for time-based relative lock-time is fixed at 51=
2 seconds.<br>
>=C2=A0 =C2=A0 =C2=A0 * Converting from CTxIn::nSequence to seconds is p=
erformed by<br>
>=C2=A0 =C2=A0 =C2=A0 * multiplying by 512 =3D 2^9, or equivalently shif=
ting up by<br>
>=C2=A0 =C2=A0 =C2=A0 * 9 bits. */<br>
>=C2=A0 =C2=A0 =C2=A0static const int SEQUENCE_LOCKTIME_GRANULARITY =3D =
9;<br>
><br>
> I am also much happier with this last tightening up of the specificati=
on<br>
> because it removes ambiguity. 512s granularity makes sense within the<=
br>
> context of the 10 minute block target.<br>
><br>
> Thank you for spending so much time carefully considering this BIP and=
<br>
> reference implementation and please let me know if there there are any=
<br>
> remaining nits so we can get those addressed.<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br>
>><br>
>> Mark,<br>
>><br>
>> You seemed interested in changing BIP 68 to use 16 bits for sequen=
ce<br>
>> number in both the block and time versions, making time based sequ=
ence<br>
>> numbers have a resolution of 512 seconds.<br>
>><br>
>> I'm in favor of this approach because it leaves aside 14 bits =
for further<br>
>> soft forks within the semantics of BIP 68.<br>
>><br>
>> It would be nice to know if you're planning this change, and p=
erhaps<br>
>> people can hold off on review until things are finalized.<br>
>><br>
>> I'd cast my "vote" against BIP 68 without this chang=
e, but am also open to<br>
>> being convinced otherwise.<br>
>><br>
>> What are other peoples opinions on this?<br>
>><br>
>> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br>
>>><br>
>>> Peter Todd <<a href=3D"mailto:pete@petertodd.org">pete@pete=
rtodd.org</a>> writes:<br>
>>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell w=
rote:<br>
>>> >> Peter Todd via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>><br>
>>> >> writes:<br>
>>> >> > However I don't think we've done a good =
job showing why we need to<br>
>>> >> > implement this feature via nSequence.<br>
>>> >><br>
>>> >> It could be implemented in other ways, but nSequence =
is the neatest<br>
>>> >> and<br>
>>> >> most straightforward I've seen.<br>
>>> >><br>
>>> >> - I'm not aware of any other (even vague) proposa=
l for its use?<br>
>>> >> Enlighten?<br>
>>> ><br>
>>> > There's three that immediately come to mind:<br>
>>> ><br>
>>> > Gregory Maxwell has proposed it as a way of discouraging =
miners from<br>
>>> > reorging chains, by including some of the low-order bits =
of a previous<br>
>>> > block header in nSequence.<br>
>>> ><br>
>>> > A few people have proposed implementing proof-of-stake bl=
ocksize voting<br>
>>> > with nSequence.<br>
>>><br>
>>> Excellent, thanks!=C2=A0 It's good to have such ideas as a=
compass.=C2=A0 PoS<br>
>>> voting seems like it won't be a problem in 5 bits.<br>
>>><br>
>>> The "prevbits" idea would want more bits; naively 64=
would be good, but<br>
>>> I think there are some tricks we can use to make 32 work OK.=
=C2=A0 We would<br>
>>> have to then split between nLocktime (if available) and multip=
le<br>
>>> nSequence fields, and it would weaken it for some txs.<br>
>>><br>
>>> There is one easy solution: change the BIP wording from:<br>
>>><br>
>>> -For transactions with an nVersion of 2 or greater,<br>
>>> +For transactions with an nVersion of 2,<br>
>>><br>
>>> And on every tx bump, we decide whether to keep this scheme (m=
empool<br>
>>> would enforce it always).<br>
>>><br>
>>> Cheers,<br>
>>> Rusty.<br>
>>> _______________________________________________<br>
>>> bitcoin-dev mailing list<br>
>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-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.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.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=
/mailman/listinfo/bitcoin-dev</a><br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
</div></div></blockquote></div><br></div>
--089e01182526a0fd6e052228e347--
|