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
|
Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CA1DCA7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 23:01:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C8C123D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 23:01:17 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id m77so83680344lfe.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 16:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=p9s6QcEotuZPkICkk5/kgCUGF7TbvXsJituTxPgvtSk=;
b=OPeYbiIQ1qh9870T6LRnQMGdgG9w3KTQeBymes/BoKNWaay2onVwdTqHx+sXyCZGSl
FI6EA8TN0VxYS1tsJ0zr2DdGUIiaIJA2ZSOweogPT16ZwTVfLF2+I9WYZhDCdxeYCZQC
dNgzOOoKVHjcY5Of6PtWxH03TGZ/gqvigS4HbC1ECwiz8qD0l+MbQfWKh34I5b61F9Qu
BmUCktAUf3Kn2M7GmmXLJz1TzF0WQ7BZtS5QsBoRUzIxCCvz21whcJkFo/fJJseQVNW3
WusyMPfnUWhhNWrJHH97ENK4dCrKf2XbhCXTNGl//Amlkm5YTWyDtPmZao7BBz6Nss1M
iQ7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=p9s6QcEotuZPkICkk5/kgCUGF7TbvXsJituTxPgvtSk=;
b=hCNW2XENy+Ax0wmymjwI7rYyjiEKGyTnT6QVBCUERd1GfJIJ4+OT/brnhPSPNN2ote
wHosM31vT1kjUHsbX0JJMDujwsmWzT+aU8PFhh6qhwve+4TXRrseR8/PZJYGuowUyOpN
mFIhiwRZuNMpMqvYRGiwlh4hE+oHqyreaukZ2JusA3mXy2+KkswEO7D8UkSpD/RhciWa
caEQ1QmD/+RkBN4X0Lk3xVU8KFujL3IbMOMobTOsfnB5lTLKfS09hJc0eXs4994BH28V
Z4eyOj64v1BYiH1CxF+uN/16NTSuR5EN+192K0ZA9kNyfovw5DfQug55jxzwQYPEQQT+
GBpg==
X-Gm-Message-State: AKS2vOylIfcMgyPHRvZCpsK8ze1N8oixwe3MbUQsJcOKJHro+1OWAP0v
S1oFEb5wbqq0kpjWy+u2q/ms6M9KXA==
X-Received: by 10.46.88.78 with SMTP id x14mr8529208ljd.108.1497999675467;
Tue, 20 Jun 2017 16:01:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 16:01:14 -0700 (PDT)
In-Reply-To: <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
<CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
<CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
<BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
<CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Tue, 20 Jun 2017 19:01:14 -0400
Message-ID: <CAAUaCyiDhHtn0rHt6D+gLqe_-UArUwBzomOdYXp4MnkqVFgfgw@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="f403043878ec87b1ab05526c3aa5"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Wed, 21 Jun 2017 01:18:51 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
get segwit activated
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: Tue, 20 Jun 2017 23:01:18 -0000
--f403043878ec87b1ab05526c3aa5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit=
)
On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff <jacob.eliosoff@gmail.com>
wrote:
> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This ha=
s
> been updated at https://github.com/bitcoin/bips/blob/master/bip-0091.
> mediawiki.) So if 80% of hashpower is actually running that code and
> signaling on bit 4 by July 25 or so, then those 80+% will start orphaning
> non-bit-1 blocks before Aug 1, and we avoid a split.
>
> There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
> because they're mined by old BIP141 nodes. But it seems like very few
> miners won't be signaling either Segwit2x *or* BIP141 by then...
>
> Make sense?
>
>
> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> Why do you say activation by August 1st is likely? That would require an
>> entire difficulty adjustment period with >=3D95% bit1 signaling. That se=
ems a
>> tall order to organize in the scant few weeks remaining.
>>
>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If segwit is activated before Aug 1, as now seems likely, there will be
>> no split that day. But if activation is via Segwit2x (also likely), and=
at
>> least some nodes do & some don't follow through with the HF 3mo later
>> (again, likely), agreed w/ Greg that *then* we'll see a split - probably=
in
>> Sep/Oct. How those two chains will match up and how the split will play
>> out is anyone's guess...
>>
>>
>>
>> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > Ironically, it looks like most of the segwit2x signaling miners are
>> > faking it (because they're not signaling segwit which it requires).
>> > It'll be unfortunate if some aren't faking it and start orphaning
>> > their own blocks because they are failing to signal segwit.
>>
>> Well, they're doing some kind of "pre-signaling" in the coinbase at the
>> moment, because the segwit2x project is still in alpha-phase according t=
o
>> the timeline. They're just showing commitment.
>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> actually running a segwit2x node when the time comes.
>>
>>
>> > As far as prevent a chain split goes, all those things
>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> > don't think that holds.
>>
>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring all blocks to signal for segwit.
>> I don't believe there would be any long lasting chainsplit though
>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks i=
f
>> we get unlucky.
>>
>> Hampus
>>
>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org>:
>>
>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > Because a large percentage of miners are indifferent, right now miner=
s
>>> have
>>> > to choose between BIP148 and Segwit2x if they want to activate Segwit=
.
>>>
>>> Miners can simply continuing signaling segwit, which will leave them
>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>>> what "segwit2x" is since they keep changing the actual definition and
>>> do not have a specification; but last I saw the near-term behavior the
>>> same as BIP91 but with a radically reduced activation window, so the
>>> story would be the same there in the near term).
>>>
>>> Ironically, it looks like most of the segwit2x signaling miners are
>>> faking it (because they're not signaling segwit which it requires).
>>> It'll be unfortunate if some aren't faking it and start orphaning
>>> their own blocks because they are failing to signal segwit.
>>>
>>> I don't think the rejection of segwit2x from Bitcoin's developers
>>> could be any more resolute than what we've already seen:
>>> https://en.bitcoin.it/wiki/Segwit_support
>>>
>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > I think it is very na=C3=AFve to assume that any shift would be tempo=
rary.
>>> > We have a hard enough time getting miners to proactively upgrade to
>>> > recent versions of the reference bitcoin daemon. If miners interpret
>>> > the situation as being forced to run non-reference software in order
>>> > to prevent a chain split because a lack of support from Bitcoin Core,
>>> > that could be a one-way street.
>>>
>>> I think this is somewhat naive and sounds a lot like the repeat of the
>>> previously debunked "XT" and "Classic" hysteria.
>>>
>>> There is a reason that segwit2x is pretty much unanimously rejected by
>>> the technical community. And just like with XT/Classic/Unlimited
>>> you'll continue to see a strong correlation with people who are
>>> unwilling and unable to keep updating the software at an acceptable
>>> level of quality-- esp. because the very founding on their fork is
>>> predicated on discarding those properties.
>>>
>>> If miners want to go off and create an altcoin-- welp, thats something
>>> they can always do, and nothing about that will force anyone to go
>>> along with it.
>>>
>>> As far as prevent a chain split goes, all those things
>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>>> don't think that holds.
>>> _______________________________________________
>>> 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
>>
>>
>
--f403043878ec87b1ab05526c3aa5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">(That is: "...because they're mined by old non-Se=
gwit2x nodes that *aren't signaling bit 1 support*", ie, that supp=
ort neither Segwit2x nor old segwit)<br><div><br></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 2017 at 6:57 PM=
, Jacob Eliosoff <span dir=3D"ltr"><<a href=3D"mailto:jacob.eliosoff@gma=
il.com" target=3D"_blank">jacob.eliosoff@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I could be wrong, but the =
latest BIP91 implementation (also included in Segwit2x) cuts the activation=
period to 336 blocks (2.33 days). =C2=A0(This has been updated at <a href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki" target=
=3D"_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip-0091.<wbr>=
mediawiki</a>.) =C2=A0So if 80% of hashpower is actually running that code =
and signaling on bit 4 by July 25 or so, then those 80+% will start orphani=
ng non-bit-1 blocks before Aug 1, and we avoid a split.<div><br></div><div>=
There may still be a few non-bit-1 blocks that get orphaned after Aug 1, be=
cause they're mined by old BIP141 nodes.=C2=A0 But it seems like very f=
ew miners won't be signaling either Segwit2x *or* BIP141 by then...</di=
v><div><br></div><div>Make sense?</div><div><br></div></div><div class=3D"H=
OEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <span dir=3D"ltr"=
><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frieden=
bach.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto"><div>Why do you say activation by August 1st is likely? That woul=
d require an entire difficulty adjustment period with >=3D95% bit1 signa=
ling. That seems a tall order to organize in the scant few weeks remaining.=
=C2=A0<br></div><div><div class=3D"m_-2731151123077402917h5"><div><br>On Ju=
n 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfounda<wbr>tion.org</a>> wrote:<br><br></div><blockquote type=3D"=
cite"><div><div dir=3D"auto"><div>If segwit is activated before Aug 1, as n=
ow seems likely, there will be no split that day.=C2=A0 But if activation i=
s via Segwit2x (also likely), and at least some nodes do & some don'=
;t follow through with the HF 3mo later (again, likely), agreed w/ Greg tha=
t *then* we'll see a split - probably in Sep/Oct.=C2=A0 How those two c=
hains will match up and how the split will play out is anyone's guess..=
.<div dir=3D"auto"><br></div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bit=
coin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"m_-2731151123077402917m_6512=
25331209638612quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><div><div class=3D"m_-27311511=
23077402917m_651225331209638612quoted-text"><div>> Ironically, it looks =
like most of the segwit2x signaling miners are<br>> faking it (because t=
hey're not signaling segwit which it requires).<br>
> It'll be unfortunate if some aren't faking it and start orphan=
ing<br>
> their own blocks because they are failing to signal segwit.<br><br></d=
iv></div>Well, they're doing some kind of "pre-signaling" in =
the coinbase at the moment, because the segwit2x project is still in alpha-=
phase according to the timeline. They're just showing commitment.<br>I&=
#39;m sure they will begin signaling on version bit 4/BIP91 as well as actu=
ally running a segwit2x node when the time comes.<div class=3D"m_-273115112=
3077402917m_651225331209638612quoted-text"><br><br>> As far as prevent a=
chain split goes, all those things<br>> (148/91/segwit2x(per today)) ef=
fectively guarantee a chainsplit-- so I<br>> don't think that holds.=
<br><br></div></div> Segwit2x/BIP91/BIP148 will orphan miners that do not r=
un a Segwit2x (or BIP148) node, because they wouldn't have the new cons=
ensus rule of requiring all blocks to signal for segwit.<br></div>I don'=
;t believe there would be any long lasting chainsplit though (because of th=
e ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.=
<br><br></div>Hampus<br></div><div class=3D"m_-2731151123077402917m_6512253=
31209638612elided-text"><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>></span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span>On Tue, Jun 20, 2017 at 3:44 PM, Erik =
Aronesty via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
> Because a large percentage of miners are indifferent, right now miners=
have<br>
> to choose between BIP148 and Segwit2x if they want to activate Segwit.=
<br>
<br>
</span>Miners can simply continuing signaling segwit, which will leave them=
<br>
at least soft-fork compatible with BIP148 and BIP91 (and god knows<br>
what "segwit2x" is since they keep changing the actual definition=
and<br>
do not have a specification; but last I saw the near-term behavior the<br>
same as BIP91 but with a radically reduced activation window, so the<br>
story would be the same there in the near term).<br>
<br>
Ironically, it looks like most of the segwit2x signaling miners are<br>
faking it (because they're not signaling segwit which it requires).<br>
It'll be unfortunate if some aren't faking it and start orphaning<b=
r>
their own blocks because they are failing to signal segwit.<br>
<br>
I don't think the rejection of segwit2x from Bitcoin's developers<b=
r>
could be any more resolute than what we've already seen:<br>
<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" ta=
rget=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_support</a><br>
<br>
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
<span><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
> I think it is very na=C3=AFve to assume that any shift would be tempor=
ary.<br>
> We have a hard enough time getting miners to proactively upgrade to<br=
>
> recent versions of the reference bitcoin daemon. If miners interpret<b=
r>
> the situation as being forced to run non-reference software in order<b=
r>
> to prevent a chain split because a lack of support from Bitcoin Core,<=
br>
> that could be a one-way street.<br>
<br>
</span>I think this is somewhat naive and sounds a lot like the repeat of t=
he<br>
previously debunked "XT" and "Classic" hysteria.<br>
<br>
There is a reason that segwit2x is pretty much unanimously rejected by<br>
the technical community.=C2=A0 And just like with XT/Classic/Unlimited<br>
you'll continue to see a strong correlation with people who are<br>
unwilling and unable to keep updating the software at an acceptable<br>
level of quality-- esp. because the very founding on their fork is<br>
predicated on discarding those properties.<br>
<br>
If miners want to go off and create an altcoin-- welp, thats something<br>
they can always do,=C2=A0 and nothing about that will force anyone to go<br=
>
along with it.<br>
<br>
As far as prevent a chain split goes, all those things<br>
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br>
don't think that holds.<br>
<div class=3D"m_-2731151123077402917m_651225331209638612m_-1870741167812905=
09HOEnZb"><div class=3D"m_-2731151123077402917m_651225331209638612m_-187074=
116781290509h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>___________________=
___________<wbr>_________________</span><br><span>bitcoin-dev mailing list<=
/span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a></span><br><s=
pan><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listin=
fo/bitcoin-d<wbr>ev</a></span><br></div></blockquote></div></div></div></bl=
ockquote></div><br></div>
</div></div></blockquote></div><br></div>
--f403043878ec87b1ab05526c3aa5--
|