Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2017-10-20 📝 Original message:You could do that today, ...
📅 Original date posted:2017-10-20
📝 Original message: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 at 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 at lists.linuxfoundation.org> a écrit :
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at 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 at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at 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 at thancodes.com>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease
>> Message-ID:
>> <CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ at 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 at stampery.co>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Improving Scalability via Block Time
>> Decrease
>> Message-ID: <40b6ef7b-f518-38cd-899a-8f301bc7ac3a at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171020/065c4aa9/attachment-0001.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org> a écrit :
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev at 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 at lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-owner at 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 at thancodes.com>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: [bitcoin-dev] Improving Scalability via Block Time Decrease
>> Message-ID:
>> <CAH01uEtLhLEj5XOp_MDRii2dR8-zUu4fUsCd25mzLDtpD_fwYQ at 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 at stampery.co>
>> To: bitcoin-dev at lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Improving Scalability via Block Time
>> Decrease
>> Message-ID: <40b6ef7b-f518-38cd-899a-8f301bc7ac3a at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171020/065c4aa9/attachment-0001.html>;