diff options
author | Ilan Oh <ilansky.sharkson@gmail.com> | 2017-10-20 19:24:34 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-10-20 17:24:37 +0000 |
commit | 902f706aa08df793912737af875247c454d79204 (patch) | |
tree | 73d4a1f5ed9c16c008597fe8e13d667c67da5924 | |
parent | 2bc8c59928ca5bf07c345c1cee5290c88de5aa4b (diff) | |
download | pi-bitcoindev-902f706aa08df793912737af875247c454d79204.tar.gz pi-bitcoindev-902f706aa08df793912737af875247c454d79204.zip |
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
-rw-r--r-- | 0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6 | 438 |
1 files changed, 438 insertions, 0 deletions
diff --git a/0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6 b/0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6 new file mode 100644 index 000000000..8aa404a7f --- /dev/null +++ b/0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6 @@ -0,0 +1,438 @@ +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 "sybil attack" 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't know what it's worth, may= +be check it out, I'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, <<a href=3D"mailto:bitcoin-dev-request@lists.= +linuxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.<wbr>linux= +foundation.org</a>> 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 'help' 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 "Re: Contents of bitcoin-dev digest..."<br> +<br> +<br> +Today'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 <<a href=3D"mailto:jon@thancodes.com">jon@thanco= +des.com</a>><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 <<a href=3D"mailto:CAH01uEtLhLEj5XOp_MDRii2d= +R8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com">CAH01uEtLhLEj5XOp_MDRii2dR8-<wbr= +>zUu4fUsCd25mzLDtpD_fwYQ@mail.<wbr>gmail.com</a>><br> +Content-Type: text/plain; charset=3D"utf-8"<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'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'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'm an idiot, I apologize; kindly point me in th= +e<br> +right direction.<br> +<br> +Things I'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 "Why Bitcoin Block Time Is 10 Minutes ?")<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: <<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>><br> +<br> +------------------------------<br> +<br> +Message: 2<br> +Date: Thu, 19 Oct 2017 15:41:51 +0200<br> +From: "=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3D<wbr>a1nchez_de_Pedro_Crespo= +?=3D"<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:adan@stampery.co">adan@st= +ampery.co</a>><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: <<a href=3D"mailto:40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stam= +pery.com">40b6ef7b-f518-38cd-899a-<wbr>8f301bc7ac3a@stampery.com</a>><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's block propagates to B, miner B's block will end up wasted= + and<br> +will not "contribute to network security".<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 "Greedy<br> +Heaviest Observed Subtree" (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'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 "if it<= +br> +ain't broke, don't fix it").<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-- + |