From: Pieter Wuille <pieter.wuille@gmail•com>
To: jl2012@xbt•hk
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal
Date: Sat, 1 Aug 2015 22:45:24 +0200 [thread overview]
Message-ID: <CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com> (raw)
In-Reply-To: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of 750 out of the last
> 1000 blocks. The "hardfork bit" mechanism might be used:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>
This is fine, I think. I believe we shouldn't proceed with a hardfork
without having reasonable expectation that it will be deployed by everyone
in time, while we can only measure miner acceptance. Still, as a
belt-and-suspenders this won't hurt.
> 2. Starting date: 30 days after 75% miner support, but not before
> 2016-01-12 00:00 UTC
>
> Rationale: A 30-day grace period is given to make sure everyone has enough
> time to follow. This is a compromise between 14 day in BIP101 and 1 year in
> BIP103. I tend to agree with BIP101. Even 1 year is given, people will just
> do it on the 364th day if they opt to procrastinate.
>
Given the time recent softforks have taken to deploy, I think that's too
soon.
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China.
> Most pool operators and devs should be back from new year holiday and not
> sleeping. (If the initiation is delayed, we may require that it must be UTC
> Tuesday midnight).
>
That's an interesting thing to take into account.
> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by
> 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on
> 2017-05-11.
>
> Rationale: Instead of jumping to 8MB, I suggest to increase it gradually
> to 8MB in 16 months. 8MB should not be particularly painful to run even
> with current equipment (you may see my earlier post on bitctointalk:
> https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed by
> Chinese miners, who control >60% of the network.
>
I have considered suggesting a faster ramp-up in the beginning, but I don't
think there is indisputable evidence that we can currently deal with
significantly larger blocks. I don't think "painful" is the right criterion
either; I'm sure my equipment can "handle" 20 MB blocks too, but with a
huge impact on network propagation speed, and even more people choosing the
outsource their full nodes.
Regarding "reasonable", I have a theory. What if we would have had 8 MB
blocks from the start? My guess is that some more people would have decided
to run their high-transaction-rate use cases on chain, that we'd regularly
see 4-6 MB blocks, there would be more complaints about low full node
counts, maybe 90% instead of 60% of the hash rate would be have SPV mining
agreements with each other, we'd somehow have accepted that even worse
reality, but people would still be complaining about the measly 25
transactions per second that Bitcoin could handle on-chain, and be
demanding a faster rampup to a more "reasonable" 64 MB block size as well.
>
> 4. After 8MB is reached, the block size will be increased by 6.714% every
> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
> 2042-11-17.
>
> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
> p.a. of BIP101. This will take us almost 8 years from now just to go back
> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>
> SSD price is expected to drop by >50%/year in the coming years. In 2020,
> we will only need to pay 2% of current price for SSD. 98% price reduction
> is enough for 40 years of 27.67% growth.
> Source:
> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>
I know many technologies have had faster growth, but I believe that global
bandwidth accessibility is the bottleneck, so the growth rate in my
proposal is based on that.
> Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
> should be safe at least for the coming 10 years.
> Source:
> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>
I'd rather be conservative here. My primary purpose is trying to create an
uncontroversial proposal that introduces an expectation of growth with
technology.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 6147 bytes --]
next prev parent reply other threads:[~2015-08-01 20:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 8:39 jl2012
2015-07-31 10:16 ` Adam Back
2015-07-31 13:07 ` jl2012
2015-07-31 13:17 ` Adam Back
2015-07-31 16:22 ` Dave Scotese
2015-07-31 18:04 ` G. Andrew Stone
2015-07-31 13:12 ` Ivan Brightly
2015-08-01 20:45 ` Pieter Wuille [this message]
2015-08-01 23:57 ` Tom Harding
2015-08-02 7:16 ` jl2012
2015-08-02 8:03 ` odinn
2015-08-02 10:32 ` Pieter Wuille
2015-08-02 10:38 ` Venzen Khaosan
2015-08-02 22:07 ` Dave Scotese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox