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

[theZerg]

BUIP098: Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork
“Run Bitcoin Unlimited to vote for compromise”​

Date: 22 August, 2018
Proposer: Andrew Stone

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:

nChain:

1. Increase block size to 128MB
   
   
2. Re-activate additional opcodes (OP_MUL, OP_LSHIFT, OP_RSHIFT, OP_INVERT)
   
   
3. Remove restriction on the number of instructions executed per script (currently 200)

ABC (official announcement):

1. Include OP_CHECKDATASIG
   
   
2. Limit transaction size to > 100 bytes (to solve a possible but expensive attack detailed here)
   
   
3. Lexical transaction ordering
   
   
4. Consensus enforcement that scriptsig (spend scripts) contain only data push instructions

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.

 

[theZerg]

Appendix A: A few notes on BIP135

BIP135 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 hardware. 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 implement it.

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 well-tested.

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.


Appendix B: General Arguments Against Various Features & BU Specific Notes

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.

1. 128MB block size increase:
   
   
   1. There is no need at this time. Blocks are not even close to 1MB! It’s just for marketing. [when adoption comes it will be a tsunami]
      
      
   2. Dangerous. We have not even exercised 32MB blocks on mainnet. No pool has mined a block > 8MB.
      
      
   3. BU note: We already support 128MB blocks
      
2. Re-activation of opcodes
   
   
   1. Proposal came too late -- it missed the generally-agreed upon spec and code deadlines. [but spec and code does seem to be available within the date]
      
      
   2. BU note: Code here:
      1. D1592 - Add SCRIPT_ENABLE_MAGNETIC_OPCODES flag - https://reviews.bitcoinabc.org/D1592
      2. D1593 - Expand IsOpcodeDisabled() - https://reviews.bitcoinabc.org/D1593
      3. D1594 - rename monolith_opcodes.cpp to … - https://reviews.bitcoinabc.org/D1594
      4. D1631 - enable magnetic opcodes in .. - https://reviews.bitcoinabc.org/D1631
      5. D1598 - OP_MUL implementation - https://reviews.bitcoinabc.org/D1598
      6. D1606 - OP_INVERT implementation - https://reviews.bitcoinabc.org/D1606
      7. D1638 - OP_LSHIFT & OP_RSHIFT - https://reviews.bitcoinabc.org/D1638
      8. D1631 - enable magnetic upgrade in tests - https://reviews.bitcoinabc.org/D1631
         
3. Removal of instruction execution count restrictions
   
   
   1. Significant time is needed for people to think about attack scripts, consuming too much CPU or memory, for example.
   2. no use cases
      
   3. provided use cases can be done off chain with zero knowledge proofs
   4. The idea of freezing the instruction set and then using hundreds or thousands of instructions to implement general purpose primitives like EC multiplication is incredibly wasteful of UTXO and blockchain history space
      
      
   5. BU note: small LOC change (nchain commit: b47906926fe5b71549d1b422f2219ccdd10a5a0d)
      
4. OP_CHECKDATASIG
   
   
   1. Is not part of Bitcoin’s original instruction set [we have already diverged from the original instruction set. Limiting changes to restoring the original set is the authority (nostalgia?) fallacy]
      
      
   2. Can be used to enable wagering which may be illegal in some jurisdictions [bitcoin itself is illegal in some jurisdictions, information is not generally illegal, and the blockchain should not and realistically cannot enforce legality on its participants just like cars cannot and do not enforce speed limits]
      
      
   3. BU note: We have significant experience here and can implement quickly
      
5. Limit transaction size to > 100 bytes (fixes this)
   
   
   1. Transaction != 64 bytes fixes the problem, why choose 100?
      
      
   2. Attack is extremely expensive and only tricks SPV wallets [but SPV wallet access is very important for bitcoin cash, and the attack will become cheaper]
      
      
   3. There may be a change to the MERKLEBLOCK protocol message that also fixes the problem -- that is, a non-consensus fix may exist (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016298.html)
      
      
   4. BU note: small LOC change
      
6. Make scriptsig contain only data push instructions
   
   
   1. This is already enforced at the network level, so probably not contentious, yet not in the nChain list
      
7. Lexical Transaction Ordering
   
   
   1. All the value is available through voluntary, non-consensus-enforced, transaction ordering. [But by enforcing it, we ensure that the most efficient is always used]
      
      
   2. The stated original purpose (to enable parallel validation) is actually a feature of removing dependency ordering, not adding lexical ordering, and it even turns out that that’s not true -- the proposed parallel validation algorithm can be implemented to efficiently verify dependency ordering.
      
      
   3. It is a major change, for little to no impact. [it prepares us for huge 1GB+ future blocks]
      
      
   4. There is no spec, just marketing documents
      
      
   5. There is no rush, so let’s defer and investigate the possibilities (https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions)

 

[torusJKL]

I'm fully behind the BIP135 voting strategy and think it is the best way forward.
It also is what BU stands for meaning giving unlimited options to those who run the software.

Thanks @theZerg for writting this up and summarizing the arguments in Appendix B.

 

[checksum0]

As a miner, I fully support implementing BIP135 or similar voting strategy, STAT.

 

[Tom Zander]

Can you clarify something?

Is the intention to have one voting bit per feature (so 7 total)?

 

[freetrader]

I completely support this BUIP in its approach, I think it's great that BU is remaining true to its mission of offering choice to its users. At no time has this need been more evident.

But I think the slogan “Run Bitcoin Unlimited to vote for compromise” downplays the benefit of this proposal and should be changed, for it sends a bit of a weak message.
I'd prefer if we emphasized that it gives BU operators greater freedom of choice to determine the future of Bitcoin Cash.

@Tom Zander : I have a similar question - at least the DATASIGVERIFY changes might differentiate between the BU proposal and the ABC proposal through different bits, unless BU has finally decided to unite behind ABC's implementation of these opcodes.

 

[theZerg]

@Tom Zander yes
@freetrader, Maybe “Run Bitcoin Unlimited to vote for unity”? But I think that the idea of compromise is important in this climate. Come up with something...

 

[freetrader]

Ok, since I want to emphasize that this can lead to a better outcome:

"Run Bitcoin Unlimited for optimal choice"

Obv. I think there's a whole big field of non-consensus changes where BU has a tradition of offering its users more choice than other clients, and that's what I see as one of the big strong points of the project.

EDIT: this is theZerg commenting: Please "like" this reply if you prefer it as the motto

 

[79b79aa8]

simply to add that it seems appropriate to ask @SanchoPanza, author of BIP135, for input regarding deployment of his proposal.

 

[torusJKL]

Another word for compromise is the mathematical term "greatest common divisor".

With a BIP135 voting for all the new features, miners will find the greatest common divisor and can match their votes until they are congruent.
And with that the network would upgraded without a split.

Thus my vote would be for "Run BU and support an harmonious upgrade"*.

*English is not my mother tongue so there might be better words to describe what I'm trying to say here.

 

[dgenr8]

I love this BUIP. You nailed it. Now let me take a look at the BIP135 implementation...

 

[SanchoPanza]

Thanks to BU for integrating BIP135, especially to @theZerg, @sickpig and @Peter Tschipper for review and most of all @Peter Tschipper for addressing review comments when I was indisposed. I appreciate any further review and feedback, @dgenr8 !

Also, theZerg did a great summary of why the BIP was created. I would be delighted if other clients would also include this, after all it is a drop-in replacement for BIP9 which only provides more flexibility.
I hope @deadalnix will consider it for ABC.

As for using it for deployment of this proposal, I will first offer general remarks that will apply to anyone who wants to use this scheme to deploy one or more features.

1. Decide on a selection of currently unused bits to to match the grouping of features you wish to deploy. To my knowledge, all voting bits are currently unused on the Bitcoin Cash chain, so it seems no problem to find enough. I'd agree that to get a bit, a feature should be well-specified and preferably have at least one example implementation .
   
   
2. Either publish and discuss this proposed assignment of bits first, or implement it directly and release. The "discuss first" option seems safer to get community feedback, avoid conflicts or wasted effort in case pools have other plans. It is also an opportunity to negotiate on the other parameters, such as the tallying time window (as some have pointed out these might have to made larger than usual to account for the possibility of hostile hash coming in from BTC in attempts to distort the voting on BCH chain), required percentage, grace periods and expiration time for the bits.
   
   
3. If there is external community contention about what parameters to use for the deployments, put those options to a vote in the BU membership in a separate BUIP, and implement what the membership deems the best option. Other projects which do not have a voting like BU would use their own ways of deciding on the parameters they want to use, so they could skip step 3.
   
   
4. Implement the deployments as decided and release the features!

I'm hoping that BU will get through this process relatively quickly, since the possible features have been very well described by theZerg.

 

[Christoph Bergmann]

Love This! Thank u Andrew for extending the debate with sanity.

One important question: Does accepted depth cover non-blocksize changes too?

Please say yes

 

[dgenr8]

@SanchoPanza Regarding BIP135 deployment parameters, along with the features themselves, for BCH this will become the focus of cross-implementation meetings and must include miners along the way.

 

[Norway]

This is what Bitcoin Unlimited is all about. Great work!

 

[RollieMe]

"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."​

Apologies if this is not the place to ask this question: Assuming this BUIP had already been implemented, if I as a someone who runs the BU node software explicitly configure my node to activate/consider all features valid, what happens if the chain splits during the November hardfork? Will my node just follow the longest chain - whether that be BitcoinSV or BitcoinABC's rules? That's kind of ideally what I want it to do - I don't want to be in the game of forecasting which ruleset will win in a hash war and I also don't want to make myself incompatible with the winner by having my node configured to support the losing side's features.

Edit: I'm not a miner in case that's relevant.

 

[solex]

Hi @RollieMe
Yes, you understand the essence of the proposal.
To be clear though, this BUIP is not yet approved by the BU membership, and therefore the software is hypothetical at present, and unavailable.
BU would put out notifications on social media: twitter, reddit, here and our website, should this BUIP be passed and the proposed full-node release becomes available.

 

[Francis GASCHET]

Hi all,
Thanks to theZerg for this detailed analyse.

IMHO it's always good to be more flexible and adaptive. I feel that BIP135 goes this way.
So it's a progress.

Regarding the fight of the two clans :
"I can only sadly conclude that this is again about power and ego not about technical merit and end user adoption"
Unfortunately this is a strong trend in many human beings. Both their ego and desire for power push them to progress, but as soon as they have got a bit of power in their hands, it becomes a horrible defect and a source of problems for the community. This was already the case with BTC Core (and still be !). If I believed in god, I would say "God protect us from reliving that" ! But I don't, so I just hope that people will become reasonable !!! Yes I know : it's a dream...
Anyway I have even more good reasons to keep running BU nodes.

If it comes to the motto, I'd say "By running Bitcoin Unlimited you vote for freedom of choice and the best future for Bitcoin."

 

[painlord2k]

I think UL must follow the branch with most PoW post fork.

But I also support the idea of miners voting on individual features introduced (or eliminated) affecting the consensus rules.

In the future we should avoid scheduled dates for Hard Forks and just introduce features and allow the miners to vote them with their blocks. Consulting other devs. is nice and good, to get insight, asking or giving them support or permission it is no good.

If a features get and keep the majority of the daily blocks it get activated after a set amount of time. If it get the majority of the daily (maybe weekly) blocks, the node accept new blocks following the new rule but doesn't build them first.

It will start building them after a set period of blocks.
Set some "safe" default threshold like (60% of daily blocks) and some safe "grace" period and allows miners to modify them as they feel fit (in the User Interface, if possible)

In this way, we stop media wars, PR wars, etc. This is the "permissionless" in Bitcoin.
Developers permissionless put out stuff and the miners permissionless adopt them, if they wish.

 

[Emil Oldenburg]

What exactly are we voting on here?