public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
       [not found] <mailman.57.1508500809.30522.bitcoin-dev@lists.linuxfoundation.org>
@ 2017-10-20 17:24 ` Ilan Oh
  2017-10-20 18:55   ` Mark Friedenbach
  0 siblings, 1 reply; 2+ messages in thread
From: Ilan Oh @ 2017-10-20 17:24 UTC (permalink / raw)
  To: bitcoin-dev

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

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
> *******************************************
>

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24
  2017-10-20 17:24 ` [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24 Ilan Oh
@ 2017-10-20 18:55   ` Mark Friedenbach
  0 siblings, 0 replies; 2+ messages in thread
From: Mark Friedenbach @ 2017-10-20 18:55 UTC (permalink / raw)
  To: Ilan Oh, Bitcoin Protocol Discussion

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-10-20 18:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.57.1508500809.30522.bitcoin-dev@lists.linuxfoundation.org>
2017-10-20 17:24 ` [bitcoin-dev] bitcoin-dev Digest, Vol 29, Issue 24 Ilan Oh
2017-10-20 18:55   ` Mark Friedenbach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox