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

* 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