Discussion:
[bitcoin-dev] High consensus fork system for scaling without limits
Erik Aronesty via bitcoin-dev
2017-03-08 19:42:11 UTC
Permalink
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).
Andrew Chow via bitcoin-dev
2017-03-08 21:21:15 UTC
Permalink
Hi Erik,

I have left you some comments below.

Some general questions:
How will you deal with excessive sighashing (i.e. massive transactions
that include a lot of signature verification)?
Presumably the sigops limit will increase proportionally?
Post by Erik Aronesty via bitcoin-dev
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.
What does EB stand for?

What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with
fake nodes publishing EBs?

How do users publish an EB? Do they use a transaction? Or is it
something that goes into the User Agent?

How high can the EB go? What is its maximum?
Post by Erik Aronesty via bitcoin-dev
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.
So anyone who does not change their EB are forked off of the network? If
the EB is an "advanced feature", then most users are going to be leaving
it at the default shipped with the software. That means that they will
then be forked off of the network when they don't change the EB because
it is an "advanced feature" that is more difficult to access.
Post by Erik Aronesty via bitcoin-dev
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.
I think this would require a soft fork beforehand in order to implement
such a system.
Post by Erik Aronesty via bitcoin-dev
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.
Why?
Post by Erik Aronesty via bitcoin-dev
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!)
"Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.
Post by Erik Aronesty via bitcoin-dev
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).
What if the EB of a new node is set to be smaller than the current block
size?
Post by Erik Aronesty via bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-03-09 15:29:07 UTC
Permalink
Post by Erik Aronesty via bitcoin-dev
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.
Post by Erik Aronesty via bitcoin-dev
What does EB stand for?
Excessive block size.
Post by Erik Aronesty via bitcoin-dev
What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with fake
nodes publishing EBs?

You can't trivially fake coinbase's full node, or gemini's, etc. Large
users would also be encouraged to report their EB's publically as well.
Post by Erik Aronesty via bitcoin-dev
How do users publish an EB? Do they use a transaction? Or is it something
that goes into the User Agent?

Same way a version string is published by a node. Maybe *in* the version
string.
Post by Erik Aronesty via bitcoin-dev
How high can the EB go? What is its maximum?
Maybe 4MB for now? Seems fine. Trivial to change it later, since it's
not a fork to do so.
Post by Erik Aronesty via bitcoin-dev
6. Core can (optionally) ship a version with a default EB in-line with
their own perceived consensus.

I would say that Core /should/ ship new versions with new default EB's
in-line with both miner and the economic majority after a 95% consensus
fork.
Post by Erik Aronesty via bitcoin-dev
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.
Post by Erik Aronesty via bitcoin-dev
I think this would require a soft fork beforehand in order to implement
such a system.

I thought versionbits could handle this? Can't they? ALP pointed out
that it was important for a fork to be fully incompatible.
Post by Erik Aronesty via bitcoin-dev
It would be in the best interests of major exchanges and users would to
publicly announce their EB's.
Post by Erik Aronesty via bitcoin-dev
Why?
So miners can have a more reliable signal to go on. No reasonable miner
would start mining signal for a fork unless they were confident that they
are doing so in-line with users and exchanges.
Post by Erik Aronesty via bitcoin-dev
"Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.

Yes, which is why I used air-quotes. The primary idea is to remove a
political issue from affecting core developers. There is a perception
among some people that "if only core would....". Plus, fees are
*inherently* political because it is a barrier for low-net-worth
individuals transacting using this technology. Even if lightning worked
perfectly, how can a small business in Africa afford to set up a full node
and being to participate as a hub if fees are $50? OMG blame core.

Miners and users should be free to wrangle each other over fees any time
they want without the involvement of developers. I suspect the status quo
would be even *more* stable in that scenario... not less.
Post by Erik Aronesty via bitcoin-dev
What if the EB of a new node is set to be smaller than the current block
size?

Then it is only used for signal unless a fork occurs that results in a
reduction <= EB... in which case the EB becomes a hard upper bound, just
like any other. When an EB is set by a user a block-height needs to be
recorded along with it, so it can be handled correctly. EB set to <
active seems to me to be a special case. Likewise the percentile shoudl
be the upper 5% in the case of EB < active.

This essentially partitions signalling into "< active" and "> active".
Loading...