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, a écrit : > 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 > (=?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?=) > > > ---------------------------------------------------------------------- > > 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: > gmail.com> > Content-Type: text/plain; charset="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% > 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 > 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=176108.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: attachments/20171019/d940fd4e/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 19 Oct 2017 15:41:51 +0200 > From: "=?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?=" > > 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=utf-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 > ******************************************* >