From: Erik Aronesty <erik@q32•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] High consensus fork system for scaling without limits
Date: Wed, 8 Mar 2017 14:42:11 -0500 [thread overview]
Message-ID: <CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]
I woudl like to propose a BIP that works something like this:
1. Allow users to signal readiness by publishing an EB. This EB is an
absolute upper bound, and cannot be overridden by miners. Current EB is
1MB, the status-quo. Maybe EB can be configured in a config file, not a
UI, since it's an "advanced" feature.
2. Miners can also signal readiness by publishing their own EB in a block.
3. If 95% of blocks within a one month signalling period contain an EB
greater than the previous consensus EB, a fork date is triggered at 6
months using the smallest 5th percentile EB published. (Other times can be
selected, but these are fairly conservative, looking for feedback here).
Miner signalling is ignored during the waiting period.
4. Block heights used for timing
5. After 6 months, any users which already have the new EB or greater begin
actually using it to validate transactions. Users use the EB or the latest
95% consensus triggered value - whichever is less. This means that the
portion of users that originally signaled for the increase do not have to
upgrade their software to participate in the hard fork.
6. Core can (optionally) ship a version with a default EB in-line with
their own perceived consensus.
7. Some sort of versioning system is used to ensure that the two networks
(old and new) are incompatible... blocks hashed in one cannot be used in
the other.
Any users which don't already have the new EB or greater should update
their EB within the 6 month period - or they will be excluded from the
majority fork.
It would be in the best interests of major exchanges and users would to
publicly announce their EB's.
Users are free to safely set very high EB levels, based on their current
hardware and network speeds. These EB levels don't cause those users to
accept invalid blocks ever. They are safe because block size transitions
behave like normal hard forks with high miner consensus (95%).
No code changes will be needed to fork the network as many times as both
users and miners feel the need to do so. (Bitcoin core is off the hook for
"scaling" issues...forever!)
If a smaller block size is needed, a reduced size can also be published and
agreed upon by *both* users and miners using a the same mechanism, but the
largest 5th percentile is used. In other words... the requires broad
consensus to deviate from status quo and fork.
Any new node can simply follow these rules to validate all the blocks in a
chain... even if the sizes changes a lot (at most twice per year).
[-- Attachment #2: Type: text/html, Size: 2734 bytes --]
next reply other threads:[~2017-03-08 19:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 19:42 Erik Aronesty [this message]
2017-03-08 21:21 ` Andrew Chow
2017-03-09 15:29 ` Erik Aronesty
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=CAJowKgL5Vyy-an54gWtpbxZdgMsNdixgyXD92OBnMoWN1bw_fA@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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