Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B0394BC8 for ; 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 ; Fri, 20 Oct 2017 18:56:00 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id i38so14225984iod.2 for ; 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 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: In-Reply-To: To: Ilan Oh , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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, 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 >> To: bitcoin-dev@lists.linuxfoundation.org >> Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease >> Message-ID: >> >> 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: >>=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" >> >> 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 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. 

If you want po= int 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 bit= coin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

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. 

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?

Also th= ere is a guy who wrote a script to avoid "sybil attack" from 2x
=
I don't know what it's worth, maybe check it out= , I'm not huge support of that kind of methods.

<= /div>
Ilansky


Le 20 oct. 2017 14:= 01, <bitcoin-dev-request@lists.linuxfoundation.org> a= =C3=A9crit :
Sen= d bitcoin-dev mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://list= s.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 Ster= ling)
   2. Re: Improving Scalability via Block Time Decrease
      (=3D?UTF-8?Q?Ad=3Dc3=3Da1n_S=3Dc3=3Da1nchez_de_Ped= ro_Crespo?=3D)


------------------------------------------------------------------= ----

Message: 1
Date: Thu, 19 Oct 2017 14:52:48 +0800
From: Jonathan Sterling <jon@thancod= es.com>
To: bitcoin-dev@lis= ts.linuxfoundation.org
Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease
Message-ID:
        <CAH01uEtLhLEj5XOp_MDRii2dR8-z= Uu4fUsCd25mzLDtpD_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 in 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 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
= 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=3D17610= 8.0
= https://bitcoin.stackexchange.com/questions/1863/why-was-the-targe= t-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"<= br>         <adan@sta= mpery.co>
To: bitcoin-dev@lis= ts.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/~yo= ni_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.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


End of bitcoin-dev Digest, Vol 29, Issue 24
*******************************************
____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-D71EB5FF-FC54-4CD3-BD0C-ABCE31E222E4--