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. 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: > > 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: >> >> 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: >> >> ------------------------------ >> >> 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 >> ******************************************* > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev