summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIlan Oh <ilansky.sharkson@gmail.com>2017-10-20 19:24:34 +0200
committerbitcoindev <bitcoindev@gnusha.org>2017-10-20 17:24:37 +0000
commit902f706aa08df793912737af875247c454d79204 (patch)
tree73d4a1f5ed9c16c008597fe8e13d667c67da5924
parent2bc8c59928ca5bf07c345c1cee5290c88de5aa4b (diff)
downloadpi-bitcoindev-902f706aa08df793912737af875247c454d79204.tar.gz
pi-bitcoindev-902f706aa08df793912737af875247c454d79204.zip
Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
-rw-r--r--0e/9f12e6799f3141618cc33c5ceec6d6d089d2e6438
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 &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--
+