path: root/cf/918d3e22f316e7a200e3bf37d8fe9a7a362046

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 B0394BC8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 18:56:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
	[209.85.223.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 650174EC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 18:56:00 +0000 (UTC)
Received: by mail-io0-f169.google.com with SMTP id i38so14225984iod.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 20 Oct 2017 11:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=from:content-transfer-encoding:mime-version:date:subject:message-id
	:references:in-reply-to:to;
	bh=mpE61sc4Zy8nZiu97o5nHaFmqOeDKWPzAlF+lrrhVnM=;
	b=I9ZbmB2L8s7wSxIiIzWDb94L2iEZdIPxZvIsaQCJxQfsFliXEdvswiS5WJMg21EGN3
	QPyyQtauJnAzZsUO8QhOleEKN4764TJN0EZYdrymG+L0kL+jpMwwWIWyKRYrS+ottFfw
	wovMHktfx3tpkp8aABbUmc+A/TVgmpprIQGXOIuaDOxUHYIQw2wLtjDojitvsnM3aMPs
	jme3nFg5pMsHbHXDYjNovGBN3ZwkDq4HeHvw7CULQRGcbduOTX1ps7fPAVgDAuF/k7kX
	kgn+kOWjBXEUAfWybM6Oh5Ke+fmBc4dG9f3GYOrMk1e3JzdVIOiOrNYiOuOZArp+/oJD
	7NGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:content-transfer-encoding:mime-version:date
	:subject:message-id:references:in-reply-to:to;
	bh=mpE61sc4Zy8nZiu97o5nHaFmqOeDKWPzAlF+lrrhVnM=;
	b=bvncDp82lTSAsSoZadQ1AGULwMoOpeqwdiccruNeE94FW+N8JeXq4+eKJ1mTI9lsYA
	ZWSyPUMhAcdOmRfOL3TH9KKnIrl2FwnuHjJew3ebeLgRfvuq//8mlKxQIhql0m367o8f
	PyEjae1kP060kNzw5z9MX4rZWHkXabL+K8Jp+q3gCjvfQpIGLxdSJrbWRSdVh7DDqg4b
	sZ/UI7HLTZAnXNGKq41d7pbHiNiJalwZL8iW9o0w1sqEC2UPaRB976Lx9VjGUQ5N+NOE
	QvBiEwC5r7awtwSQrT3txS/h7yYk7GYdaxRd4kx4j4teVqhCaZmTiqn5j6J9sSWfUzHl
	QDgw==
X-Gm-Message-State: AMCzsaUOCJa9cImbPkRmIba8nm3RucDMiTaQ5Y4TiVn5rQaVnrHIhj0P
	FgI1Y+XCXRG0QMIKCql20Q8ogw==
X-Google-Smtp-Source: ABhQp+Spu/L1+4YCDhL97nhgBhbU5uECxySLdpKz05JmAz2498tSscw1W3Z1Ia9YJBfyjFc+ixnlgw==
X-Received: by 10.107.20.209 with SMTP id 200mr7447673iou.219.1508525759611;
	Fri, 20 Oct 2017 11:55:59 -0700 (PDT)
Received: from [100.90.69.188] ([172.56.12.32])
	by smtp.gmail.com with ESMTPSA id v4sm598171iod.17.2017.10.20.11.55.57
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 20 Oct 2017 11:55:58 -0700 (PDT)
From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-D71EB5FF-FC54-4CD3-BD0C-ABCE31E222E4
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Fri, 20 Oct 2017 20:55:55 +0200
Message-Id: <0CA57198-C99E-4AFA-A67B-2DE29164D74C@friedenbach.org>
References: <mailman.57.1508500809.30522.bitcoin-dev@lists.linuxfoundation.org>
	<CALTsm7iy0Wh6e3SsE-OWj_+R=jhBGxXdhCaEMixzA_KD=TModw@mail.gmail.com>
In-Reply-To: <CALTsm7iy0Wh6e3SsE-OWj_+R=jhBGxXdhCaEMixzA_KD=TModw@mail.gmail.com>
To: Ilan Oh <ilansky.sharkson@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (15A432)
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,MIME_QP_LONG_LINE,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
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 18:56:01 -0000


--Apple-Mail-D71EB5FF-FC54-4CD3-BD0C-ABCE31E222E4
Content-Type: text/plain;
	charset=gb2312
Content-Transfer-Encoding: quoted-printable

You could do that today, with one of the 3 interoperable Lightning implement=
ations available. Lowering the block interval on the other hand comes with a=
 large number of centralizing downsides documented elsewhere. And getting do=
wn to 1sec or less on a global network is simply impossible due to the speed=
 of light.=20

If you want point of sale support, I suggest looking into the excellent work=
 the Lightning teams have done.

> On Oct 20, 2017, at 7:24 PM, Ilan Oh via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>=20
> The only blocktime reduction that would be a game changer, would be a 1 se=
cond blocktime or less, and by less I mean much less maybe 1000 blocks/secon=
d. Which would enable decentralized high frequency trading or playing WoW on=
 blockchain and other cool stuff.=20
>=20
> But technology is not developped enough as far as I now, maybe with quantu=
m computers in the future, and it is even bitcoins goal?
>=20
> Also there is a guy who wrote a script to avoid "sybil attack" from 2x
> https://github.com/mariodian/ban-segshit8x-nodes
>=20
> I don't know what it's worth, maybe check it out, I'm not huge support of t=
hat kind of methods.
>=20
> Ilansky
>=20
>=20
> Le 20 oct. 2017 14:01, <bitcoin-dev-request@lists.linuxfoundation.org> a =A8=
=A6crit :
>> Send bitcoin-dev mailing list submissions to
>>         bitcoin-dev@lists.linuxfoundation.org
>>=20
>> 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
>>=20
>> You can reach the person managing the list at
>>         bitcoin-dev-owner@lists.linuxfoundation.org
>>=20
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>=20
>>=20
>> Today's Topics:
>>=20
>>    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)
>>=20
>>=20
>> ----------------------------------------------------------------------
>>=20
>> 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.c=
om>
>> Content-Type: text/plain; charset=3D"utf-8"
>>=20
>> 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:
>>=20
>> 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
>>=20
>> 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.
>>=20
>> 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
>>=20
>> Kind Regards,
>>=20
>> Jonathan Sterling
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20171019/d940fd4e/attachment-0001.html>
>>=20
>> ------------------------------
>>=20
>> 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
>>=20
>> Blockchains with fast confirmation times are currently believed to
>> suffer from reduced security due to a high stale rate.
>>=20
>> 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".
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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
>>=20
>> 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").
>>=20
>> --
>> Ad?n S?nchez de Pedro Crespo
>> CTO, Stampery Inc.
>> San Francisco - Madrid
>>=20
>>=20
>> ------------------------------
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>>=20
>> End of bitcoin-dev Digest, Vol 29, Issue 24
>> *******************************************
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-D71EB5FF-FC54-4CD3-BD0C-ABCE31E222E4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">You could do that today, with one of the 3 i=
nteroperable Lightning implementations available. Lowering the block interva=
l on the other hand comes with a large number of centralizing downsides docu=
mented elsewhere. And getting down to 1sec or less on a global network is si=
mply impossible due to the speed of light.&nbsp;<div><br><div>If you want po=
int of sale support, I suggest looking into the excellent work the Lightning=
 teams have done.</div><div><br>On Oct 20, 2017, at 7:24 PM, Ilan Oh via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote type=
=3D"cite"><div><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 muc=
h less maybe 1000 blocks/second. Which would enable decentralized high frequ=
ency trading or playing WoW on blockchain and other cool stuff.&nbsp;<div di=
r=3D"auto"><br></div><div dir=3D"auto">But technology is not developped enou=
gh as far as I now, maybe with quantum computers in the future, and it is ev=
en bitcoins goal?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also th=
ere is a guy who wrote a script to avoid "sybil attack" from 2x</div><div di=
r=3D"auto"><a href=3D"https://github.com/mariodian/ban-segshit8x-nodes">http=
s://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, maybe check it out=
, I'm not huge support of that kind of methods.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Ilansky</div><div dir=3D"auto"><br></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">Le&nbsp;20 oct. 2017 14:=
01,  &lt;<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a>&gt; a=
 =C3=A9crit&nbsp;:<br type=3D"attribution"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sen=
d bitcoin-dev mailing list submissions to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"https://lists.linuxfoundation.org/mai=
lman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://list=
s.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"mailto:bitcoin-dev-request@lists.linu=
xfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"mailto:bitcoin-dev-owner@lists.linuxf=
oundation.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>
&nbsp; &nbsp;1. Improving Scalability via Block Time Decrease (Jonathan Ster=
ling)<br>
&nbsp; &nbsp;2. Re: Improving Scalability via Block Time Decrease<br>
&nbsp; &nbsp; &nbsp; (=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3D<wbr>a1nchez_de_Ped=
ro_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@thancod=
es.com</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.<wbr>linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href=3D"mailto:CAH01uEtLhLEj5XOp_MDRii2dR=
8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com">CAH01uEtLhLEj5XOp_MDRii2dR8-<wbr>z=
Uu4fUsCd25mzLDtpD_fwYQ@mail.<wbr>gmail.com</a>&gt;<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<b=
r>
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 without<b=
r>
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 the<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-6335=
1e35603a" rel=3D"noreferrer" target=3D"_blank">https://medium.facilelogin.<w=
br>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"norefe=
rrer" target=3D"_blank">https://bitcointalk.org/index.<wbr>php?topic=3D17610=
8.0</a><br>
<a href=3D"https://bitcoin.stackexchange.com/questions/1863/why-was-the-targ=
et-block-time-chosen-to-be-10-minutes" rel=3D"noreferrer" target=3D"_blank">=
https://bitcoin.stackexchange.<wbr>com/questions/1863/why-was-<wbr>the-targe=
t-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/a=
ttachments/20171019/d940fd4e/attachment-0001.html" rel=3D"noreferrer" target=
=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: "=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3D<wbr>a1nchez_de_Pedro_Crespo?=3D"<=
br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href=3D"mailto:adan@stampery.co">adan@sta=
mpery.co</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Improving Scalability via Block Time<br>
&nbsp; &nbsp; &nbsp; &nbsp; Decrease<br>
Message-ID: &lt;<a href=3D"mailto:40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stamp=
ery.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'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_full=
.pdf" rel=3D"noreferrer" target=3D"_blank">http://www.cs.huji.ac.il/~<wbr>yo=
ni_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" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 29, Issue 24<br>
******************************<wbr>*************<br>
</blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></b=
ody></html>=

--Apple-Mail-D71EB5FF-FC54-4CD3-BD0C-ABCE31E222E4--