Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24

From: Mark Friedenbach <mark@friedenbach•org>
To: Ilan Oh <ilansky.sharkson@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
Date: Fri, 20 Oct 2017 20:55:55 +0200	[thread overview]
Message-ID: <0CA57198-C99E-4AFA-A67B-2DE29164D74C@friedenbach.org> (raw)
In-Reply-To: <CALTsm7iy0Wh6e3SsE-OWj_+R=jhBGxXdhCaEMixzA_KD=TModw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7435 bytes --]

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 <bitcoin-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 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, <bitcoin-dev-request@lists•linuxfoundation.org> 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 <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.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: <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: "=?UTF-8?Q?Ad=c3=a1n_S=c3=a1nchez_de_Pedro_Crespo?="
>>         <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=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

[-- Attachment #2: Type: text/html, Size: 10479 bytes --]