path: root/0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6

Return-Path: <ilansky.sharkson@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 087F48D4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 17:24:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com
	[209.85.214.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F0161AD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 17:24:35 +0000 (UTC)
Received: by mail-it0-f51.google.com with SMTP id 72so14791802itl.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 10:24:35 -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; 
	bh=PPgcmoJtoJdc1+xF9s7U6dmbV7qMOxlCzrrRqy6Stkg=;
	b=YX9wrB7vbsrGVFbqW4Txpj5WXaQawXW/92efv8lRWpsJOiUxbnLDMdElnuYhHP8H0/
	PLWGnqSLqIDCxeZD+s33Q0bnBbgItOrrFM3dkUdXwj/xmIzUq4E3MUj0N9Mf4OfuC59L
	CSzmax8U/JUclht+8PGSobLmk96oV7bG6Qu2CECyPtmhh16Yj3TndwHVQXqL2fLel8f0
	5wwspyQRkUsm0QPC3VG/q1t5On0E+/Jtw+mGGIFHVBBAL4xbHr7AfLPf4v0fRGqgPPvA
	j/S8ocy+JRrseZ2ZbXrTIKJ4l3EPopqvauVZ080GCKfqWkGsYPC6GdcPFQ6no3DZYlsU
	5e9A==
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;
	bh=PPgcmoJtoJdc1+xF9s7U6dmbV7qMOxlCzrrRqy6Stkg=;
	b=mK4DSEJBGnSSfWbIbypvCp8JI0lLLICEfsfU0wNlPT7qj5YOoR7wzl7UE6uX21u5PQ
	/NbIY+nXacC6qpfuZxtsuADxWaq7Lxr3vgxeZuk0txUmUz+tzZmSaB6pC+BVy2MK6G0h
	ga+GLd/7spWCaBiXueAcESfqz2a1t3eKvP2AHetwpurCbVSmM6ceEoZVIKZrdT69fwyw
	y0ex+bMqen+s2plfJNXOY/qeKc7kscheKHF90uJAd2SnDwcWVWI9hxSlYEc+w9lhqJoJ
	foNS1Po07g2M19IOWjAUoSanNrSOQA1Zg7T61zyCLC4jlyn9tjqiHH/eR6mPHrTongR0
	v8cg==
X-Gm-Message-State: AMCzsaVI22JSC5uwXMSCb7+wXQ3OSzsk9NPh7NFIldzHzjHww8AV7w2u
	L+AZq01bK9KVvuFNNxjEKq41rwZq4Lurv/8S5QI=
X-Google-Smtp-Source: ABhQp+Sji1HE51gGQ4A8/ig/RUs3Gnlwj1MDNd+mMN1OAsZopUpfFVgrY2iXnQz5Zoujwmpqbz0ljEgb4gBsTGAc9Xo=
X-Received: by 10.36.245.11 with SMTP id k11mr3773177ith.0.1508520274608; Fri,
	20 Oct 2017 10:24:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.28.135 with HTTP; Fri, 20 Oct 2017 10:24:34 -0700 (PDT)
Received: by 10.2.28.135 with HTTP; Fri, 20 Oct 2017 10:24:34 -0700 (PDT)
In-Reply-To: <mailman.57.1508500809.30522.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.57.1508500809.30522.bitcoin-dev@lists.linuxfoundation.org>
From: Ilan Oh <ilansky.sharkson@gmail.com>
Date: Fri, 20 Oct 2017 19:24:34 +0200
Message-ID: <CALTsm7iy0Wh6e3SsE-OWj_+R=jhBGxXdhCaEMixzA_KD=TModw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="94eb2c035dba1ac576055bfdbf92"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 20 Oct 2017 17:33:23 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
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: Fri, 20 Oct 2017 17:24:37 -0000

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

The only blocktime reduction that would be a game changer, would be a 1
second blocktime or less, and by less I mean much less maybe 1000
blocks/second. Which would enable decentralized high frequency trading or
playing WoW on blockchain and other cool stuff.

But technology is not developped enough as far as I now, maybe with quantum
computers in the future, and it is even bitcoins goal?

Also there is a guy who wrote a script to avoid "sybil attack" from 2x
https://github.com/mariodian/ban-segshit8x-nodes

I don't know what it's worth, maybe check it out, I'm not huge support of
that kind of methods.

Ilansky


Le 20 oct. 2017 14:01, <bitcoin-dev-request@lists.linuxfoundation.org> a
=C3=A9crit :

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. Improving Scalability via Block Time Decrease (Jonathan Sterling)
>    2. Re: Improving Scalability via Block Time Decrease
>       (=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3Da1nchez_de_Pedro_Crespo?=3D)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Oct 2017 14:52:48 +0800
> From: Jonathan Sterling <jon@thancodes.com>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease
> Message-ID:
>         <CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ@mail.
> gmail.com>
> Content-Type: text/plain; charset=3D"utf-8"
>
> The current ten-minute block time was chosen by Satoshi as a tradeoff
> between confirmation time and the amount of work wasted due to chain
> splits. Is there not room for optimization in this number from:
>
> A. Advances in technology in the last 8-9 years
> B. A lack of any rigorous formula being used to determine what's the
> optimal rate
> C. The existence of similar chains that work at a much lower block times
>
> Whilst I think we can all agree that 10 second block times would result i=
n
> a lot of chain splits due to Bitcoins 12-13 second propagation time (to 9=
5%
> of nodes), I think we'll find that we can go lower than 10 minutes withou=
t
> much issue. Is this something that should be looked at or am I an idiot w=
ho
> needs to read more? If I'm an idiot, I apologize; kindly point me in the
> right direction.
>
> Things I've read on the subject:
> https://medium.facilelogin.com/the-mystery-behind-block-time-63351e35603a
> (section header "Why Bitcoin Block Time Is 10 Minutes ?")
> https://bitcointalk.org/index.php?topic=3D176108.0
> https://bitcoin.stackexchange.com/questions/1863/why-was-
> the-target-block-time-chosen-to-be-10-minutes
>
> Kind Regards,
>
> Jonathan Sterling
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20171019/d940fd4e/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Oct 2017 15:41:51 +0200
> From: "=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3Da1nchez_de_Pedro_Crespo?=3D"
>         <adan@stampery.co>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Improving Scalability via Block Time
>         Decrease
> Message-ID: <40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stampery.com>
> Content-Type: text/plain; charset=3Dutf-8
>
> Blockchains with fast confirmation times are currently believed to
> suffer from reduced security due to a high stale rate.
>
> As blocks take a certain time to propagate through the network, if miner
> A mines a block and then miner B happens to mine another block before
> miner A's block propagates to B, miner B's block will end up wasted and
> will not "contribute to network security".
>
> Furthermore, there is a centralization issue: if miner A is a mining
> pool with 30% hashpower and B has 10% hashpower, A will have a risk of
> producing a stale block 70% of the time (since the other 30% of the time
> A produced the last block and so will get mining data immediately)
> whereas B will have a risk of producing a stale block 90% of the time.
>
> Thus, if the block interval is short enough for the stale rate
> to be high, A will be substantially more efficient simply by virtue of
> its size. With these two effects combined, blockchains which produce
> blocks quickly are very likely to lead to one mining pool having a large
> enough percentage of the network hashpower to have de facto control over
> the mining process.
>
> Another possible implication of reducing the average block time is that
> block size should be reduced accordingly. In an hypothetical 5 minutes
> block size Bitcoin blockchain, there would be twice the block space
> available for miners to include transactions, which could lead to 2
> immediate consequences: (1) the blockchain could grow up to twice the
> rate, which is known to be bad for decentralization; and (2) transaction
> fees might go down, making it cheaper for spammers to bloat our beloved
> UTXO sets.
>
> There have been numerous proposals that tried to overcome the downsides
> of faster blocks, the most noteworthy probably being the "Greedy
> Heaviest Observed Subtree" (GHOST) protocol:
> http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_full.pdf
>
> Personally, I can't see why Bitcoin would need or how could it even
> benefit at all from faster blocks. Nevertheless, I would really love if
> someone in the list who has already run the numbers could bring some
> valid points on why 10 minutes is the optimal rate (other than "if it
> ain't broke, don't fix it").
>
> --
> Ad?n S?nchez de Pedro Crespo
> CTO, Stampery Inc.
> San Francisco - Madrid
>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 29, Issue 24
> *******************************************
>

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

<div dir=3D"auto">The only blocktime reduction that would be a game changer=
, would be a 1 second blocktime or less, and by less I mean much less maybe=
 1000 blocks/second. Which would enable decentralized high frequency tradin=
g or playing WoW on blockchain and other cool stuff.=C2=A0<div dir=3D"auto"=
><br></div><div dir=3D"auto">But technology is not developped enough as far=
 as I now, maybe with quantum computers in the future, and it is even bitco=
ins goal?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also there is =
a guy who wrote a script to avoid &quot;sybil attack&quot; from 2x</div><di=
v dir=3D"auto"><a href=3D"https://github.com/mariodian/ban-segshit8x-nodes"=
>https://github.com/mariodian/ban-segshit8x-nodes</a><br></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">I don&#39;t know what it&#39;s worth, may=
be check it out, I&#39;m not huge support of that kind of methods.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Ilansky</div><div dir=3D"auto"><=
br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">Le=
=C2=A020 oct. 2017 14:01,  &lt;<a href=3D"mailto:bitcoin-dev-request@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.<wbr>linux=
foundation.org</a>&gt; a =C3=A9crit=C2=A0:<br type=3D"attribution"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Send bitcoin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br=
>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org">bitcoin-dev-owner@lists.<wbr>linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. Improving Scalability via Block Time Decrease (Jonathan Ste=
rling)<br>
=C2=A0 =C2=A02. Re: Improving Scalability via Block Time Decrease<br>
=C2=A0 =C2=A0 =C2=A0 (=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3D<wbr>a1nchez_de_Pe=
dro_Crespo?=3D)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----=
-----<br>
<br>
Message: 1<br>
Date: Thu, 19 Oct 2017 14:52:48 +0800<br>
From: Jonathan Sterling &lt;<a href=3D"mailto:jon@thancodes.com">jon@thanco=
des.com</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CAH01uEtLhLEj5XOp_MDRii2d=
R8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com">CAH01uEtLhLEj5XOp_MDRii2dR8-<wbr=
>zUu4fUsCd25mzLDtpD_fwYQ@mail.<wbr>gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
The current ten-minute block time was chosen by Satoshi as a tradeoff<br>
between confirmation time and the amount of work wasted due to chain<br>
splits. Is there not room for optimization in this number from:<br>
<br>
A. Advances in technology in the last 8-9 years<br>
B. A lack of any rigorous formula being used to determine what&#39;s the<br=
>
optimal rate<br>
C. The existence of similar chains that work at a much lower block times<br=
>
<br>
Whilst I think we can all agree that 10 second block times would result in<=
br>
a lot of chain splits due to Bitcoins 12-13 second propagation time (to 95%=
<br>
of nodes), I think we&#39;ll find that we can go lower than 10 minutes with=
out<br>
much issue. Is this something that should be looked at or am I an idiot who=
<br>
needs to read more? If I&#39;m an idiot, I apologize; kindly point me in th=
e<br>
right direction.<br>
<br>
Things I&#39;ve read on the subject:<br>
<a href=3D"https://medium.facilelogin.com/the-mystery-behind-block-time-633=
51e35603a" rel=3D"noreferrer" target=3D"_blank">https://medium.facilelogin.=
<wbr>com/the-mystery-behind-block-<wbr>time-63351e35603a</a><br>
(section header &quot;Why Bitcoin Block Time Is 10 Minutes ?&quot;)<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D176108.0" rel=3D"noref=
errer" target=3D"_blank">https://bitcointalk.org/index.<wbr>php?topic=3D176=
108.0</a><br>
<a href=3D"https://bitcoin.stackexchange.com/questions/1863/why-was-the-tar=
get-block-time-chosen-to-be-10-minutes" rel=3D"noreferrer" target=3D"_blank=
">https://bitcoin.stackexchange.<wbr>com/questions/1863/why-was-<wbr>the-ta=
rget-block-time-chosen-<wbr>to-be-10-minutes</a><br>
<br>
Kind Regards,<br>
<br>
Jonathan Sterling<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20171019/d940fd4e/attachment-0001.html" rel=3D"noreferrer" targ=
et=3D"_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<=
wbr>attachments/20171019/d940fd4e/<wbr>attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 19 Oct 2017 15:41:51 +0200<br>
From: &quot;=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3D<wbr>a1nchez_de_Pedro_Crespo=
?=3D&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:adan@stampery.co">adan@st=
ampery.co</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Improving Scalability via Block Time<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Decrease<br>
Message-ID: &lt;<a href=3D"mailto:40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stam=
pery.com">40b6ef7b-f518-38cd-899a-<wbr>8f301bc7ac3a@stampery.com</a>&gt;<br=
>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
Blockchains with fast confirmation times are currently believed to<br>
suffer from reduced security due to a high stale rate.<br>
<br>
As blocks take a certain time to propagate through the network, if miner<br=
>
A mines a block and then miner B happens to mine another block before<br>
miner A&#39;s block propagates to B, miner B&#39;s block will end up wasted=
 and<br>
will not &quot;contribute to network security&quot;.<br>
<br>
Furthermore, there is a centralization issue: if miner A is a mining<br>
pool with 30% hashpower and B has 10% hashpower, A will have a risk of<br>
producing a stale block 70% of the time (since the other 30% of the time<br=
>
A produced the last block and so will get mining data immediately)<br>
whereas B will have a risk of producing a stale block 90% of the time.<br>
<br>
Thus, if the block interval is short enough for the stale rate<br>
to be high, A will be substantially more efficient simply by virtue of<br>
its size. With these two effects combined, blockchains which produce<br>
blocks quickly are very likely to lead to one mining pool having a large<br=
>
enough percentage of the network hashpower to have de facto control over<br=
>
the mining process.<br>
<br>
Another possible implication of reducing the average block time is that<br>
block size should be reduced accordingly. In an hypothetical 5 minutes<br>
block size Bitcoin blockchain, there would be twice the block space<br>
available for miners to include transactions, which could lead to 2<br>
immediate consequences: (1) the blockchain could grow up to twice the<br>
rate, which is known to be bad for decentralization; and (2) transaction<br=
>
fees might go down, making it cheaper for spammers to bloat our beloved<br>
UTXO sets.<br>
<br>
There have been numerous proposals that tried to overcome the downsides<br>
of faster blocks, the most noteworthy probably being the &quot;Greedy<br>
Heaviest Observed Subtree&quot; (GHOST) protocol:<br>
<a href=3D"http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_ful=
l.pdf" rel=3D"noreferrer" target=3D"_blank">http://www.cs.huji.ac.il/~<wbr>=
yoni_sompo/pubs/15/btc_<wbr>scalability_full.pdf</a><br>
<br>
Personally, I can&#39;t see why Bitcoin would need or how could it even<br>
benefit at all from faster blocks. Nevertheless, I would really love if<br>
someone in the list who has already run the numbers could bring some<br>
valid points on why 10 minutes is the optimal rate (other than &quot;if it<=
br>
ain&#39;t broke, don&#39;t fix it&quot;).<br>
<br>
--<br>
Ad?n S?nchez de Pedro Crespo<br>
CTO, Stampery Inc.<br>
San Francisco - Madrid<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.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-<wbr>dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 29, Issue 24<br>
******************************<wbr>*************<br>
</blockquote></div></div>

--94eb2c035dba1ac576055bfdbf92--