BUIP098: Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork

“Run Bitcoin Unlimited to vote for compromise”​

Increase block size to 128MB



Re-activate additional opcodes (OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT)



Remove restriction on the number of instructions executed per script (currently 200)

Include OP_CHECKDATASIG



Limit transaction size to > 100 bytes (to solve a possible but expensive attack detailed here)



Lexical transaction ordering



Consensus enforcement that scriptsig (spend scripts) contain only data push instructions

Date: 22 August, 2018Proposer: Andrew StoneThere 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: ABC (official announcement ):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.