<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">You could do that today, with one of the 3 interoperable Lightning implementations available. Lowering the block interval on the other hand comes with a large number of centralizing downsides documented elsewhere. And getting down to 1sec or less on a global network is simply impossible due to the speed of light. <div><br><div>If you want point 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 bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="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 trading or playing WoW on blockchain and other cool stuff. <div dir="auto"><br></div><div dir="auto">But technology is not developped enough as far as I now, maybe with quantum computers in the future, and it is even bitcoins goal?</div><div dir="auto"><br></div><div dir="auto">Also there is a guy who wrote a script to avoid "sybil attack" from 2x</div><div dir="auto"><a href="https://github.com/mariodian/ban-segshit8x-nodes">https://github.com/mariodian/ban-segshit8x-nodes</a><br></div><div dir="auto"><br></div><div dir="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="auto"><br></div><div dir="auto">Ilansky</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 20 oct. 2017 14:01, <<a href="mailto:bitcoin-dev-request@lists.linuxfoundation.org" target="_blank">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send bitcoin-dev mailing list submissions to<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bitcoin-dev-owner@lists.linuxfoundation.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>
1. Improving Scalability via Block Time Decrease (Jonathan Sterling)<br>
2. Re: Improving Scalability via Block Time Decrease<br>
(=?UTF-8?Q?Ad=c3=a1n_S=c3=<wbr>a1nchez_de_Pedro_Crespo?=)<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="mailto:jon@thancodes.com">jon@thancodes.com</a>><br>
To: <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease<br>
Message-ID:<br>
<<a href="mailto:CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ@mail.gmail.com">CAH01uEtLhLEj5XOp_MDRii2dR8-<wbr>zUu4fUsCd25mzLDtpD_fwYQ@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="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 without<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 the<br>
right direction.<br>
<br>
Things I've read on the subject:<br>
<a href="https://medium.facilelogin.com/the-mystery-behind-block-time-63351e35603a" rel="noreferrer" target="_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="https://bitcointalk.org/index.php?topic=176108.0" rel="noreferrer" target="_blank">https://bitcointalk.org/index.<wbr>php?topic=176108.0</a><br>
<a href="https://bitcoin.stackexchange.com/questions/1863/why-was-the-target-block-time-chosen-to-be-10-minutes" rel="noreferrer" target="_blank">https://bitcoin.stackexchange.<wbr>com/questions/1863/why-was-<wbr>the-target-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="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171019/d940fd4e/attachment-0001.html" rel="noreferrer" target="_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: "=?UTF-8?Q?Ad=c3=a1n_S=c3=<wbr>a1nchez_de_Pedro_Crespo?="<br>
<<a href="mailto:adan@stampery.co">adan@stampery.co</a>><br>
To: <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Improving Scalability via Block Time<br>
Decrease<br>
Message-ID: <<a href="mailto:40b6ef7b-f518-38cd-899a-8f301bc7ac3a@stampery.com">40b6ef7b-f518-38cd-899a-<wbr>8f301bc7ac3a@stampery.com</a>><br>
Content-Type: text/plain; charset=utf-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="http://www.cs.huji.ac.il/~yoni_sompo/pubs/15/btc_scalability_full.pdf" rel="noreferrer" target="_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="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></body></html>