BUIP098: Bitcoin Unlimited's Strategy for the November 2018 Hard Fork Proposer: Andrew Stone (@theZerg) Submitted on: 2018-08-21 Status: draft
There are 2 changesets proposed for the November 2018 hard fork that
have a variety of supporters but can be summarized as coming from
Bitcoin ABC and nChain. To review:
It is ironic that these changesets are mutually compatible, yet both
groups reject the other’s changes. There may be some specific critiques
(see Appendix B) of various proposals, but the core the rationale behind
the rejections seem to be the same used to block Group tokenization –
fewer changes are better because every change introduces risk.
Additionally, there is concern that the blocking of certain features is
happening due to undisclosed patented technologies that compete with the
proposed features. By blocking the feature, the patent remains valuable.
Representatives of Bitcoin Unlimited have explored the idea of
compromise with representatives from both groups with no success so far,
even the smallest changes (like changing a constant to one better
suited) have been rejected. Given the “no changes, no matter how
reasonable, except mine” strategy being pursued by both of these
organizations, I can only sadly conclude that this is again about power
and ego not about technical merit and end user adoption.
I believe that the proponents of Bitcoin Cash need to stick together and
come to a compromise, rather than fork and face another dispersion of
economic activity. This is the essential conclusion of Metcalfe’s law.
With the 30 day median block size at 36.6Kb, I invite you to examine the
above feature list and identify those whose inclusion will compensate
for splitting the community due to the dramatic and rapid increase in
adoption that the feature enables.
When I proposed the original plan of hard forks every 6 months the
intention was to onboard as many people as possible by including many
use cases, and accept the risk these changes implied. This strategy has
been a failure. The periodic hard fork has not been used to activate any
feature that resulted in significant new consumer-focused use cases.
Such changes may modify just a few lines of code, but have large
ramifications on the use of the blockchain and the community is
concerned about this. Instead the periodic hard fork is being used to
“bundle” individual organizations’ favorite features into a single
“swallow the sweet with the bitter” package.
I would like to propose a strategy for Bitcoin Unlimited for the near
future. In essence, our message will be “run Bitcoin Unlimited to vote
for compromise”. The Bitcoin Unlimited client will incorporate features
from both organizations and allow these features to either be activated
via BIP135 (a generalized form of BIP9 miner voting via version bits),
explicit configuration, or (development time and feasibility permitting)
emergent consensus. By allowing BIP135, we move to a miner voting
process that allows individual features to gain agreement before
activation. By allowing explicit configuration – that is, allowing a
user to force the feature “on” or “off” – people running the BUcash
full node can quickly react to any hash-power surprises.
is a superset of BIP9. BIP9 has hard-coded activation thresholds and
times and these are quite optimistic. For example, it proposed a 95%
activation threshold, yet during the fight for larger blocks it became
clear that well over 5% of the hash power actually had much larger
investments in alt-coin hashing
Although the economic model of Bitcoin assumes that 51% of the hash
power wants what is “best” for the currency, its is a flawed to assume
that for 100% of the hash power.
BIP135 allows activation thresholds and times to be configured. Note
that these can be configured with the BIP9 values to make a particular
activation bit backwards compatible with BIP9-only full nodes.
Note that BIP135 allows for a grace period after a feature is “locked
in” and before it actually activates on mainnet. This period is used to
allow clients that have not implemented the feature to actually
BIP135 also defines an end to the voting process, so failed initiatives
can be removed from clients that pre-implemented them. It is our
expectation that part of a reasonable path forward would be a common
understanding that version bits voting should be used when at least one
implementation has the corresponding feature set available and
Finally, note that BIP135 implicitly allows feature obsolescence and
removal some time after activation. The removal of a something can
itself be defined as a “feature” and assigned a bit.
Note: I don’t necessarily agree or disagree with any of the arguments
presented here. This is a general summary of arguments [and rebuttals
in brackets] that I have heard. Actually, I think that quite a few of
them are invalid, but make up your own mind. Please comment if you would
like another argument or rebuttal added.