BUIP095: (passed) BCH November upgrade - CHECKDATASIG & CHECKDATASIGVERIFY

[solex]

BUIP095: BCH November upgrade - CHECKDATASIG & CHECKDATASIGVERIFY
Date: 14 August 2018
Proposer: solex

Motivation
Bitcoin Cash is advancing through decentralized development. Perhaps this was easier early-on, but now the dust has settled from the fork and a year has passed, there are many different voices pushing and pulling development priorities. The upcoming 15 November 2018 general upgrade is a major event, hence it would help if Bitcoin Unlimited, as an organization, had an official position on the major elements of the upgrade. This position is determined by the membership.

Objective

The purpose of the BUIP is to determine whether the BU membership supports creating the following new op codes in the scheduled November upgrade (this is a forking change).

Summary of Proposed Changes

Create new op codes:

OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY

For further information, specification link:
edit2: link added for further info
https://github.com/bitcoincashorg/b...959697a133f93da0c89d7/spec/op_checkdatasig.md
edit1: link added for further info
https://www.yours.org/content/the-story-of-op_checkdatasig-f79679d52b23

For previous community discussion see https://www.reddit.com/r/btc/comments/96fxvy/op_checkdatasig_is_copying_blockstream_and_is/?utm_term=30719111134&utm_medium=comment_embed&utm_source=embed&utm_name=null&utm_content=more

Budget

N/A

Impact

This BUIP has the potential to fork BU off the BCH blockchain. This BUIP is not intended to facilitate a chain split. BU does not desire unintended forks in the BCH blockchain, so the BU client will remain compatible with the final specification of the November upgrade.

 

[AdrianX]

Impact

BU will not fork itself off the BCH blockchain, so the BU client will remain compatible with the final specification of the November upgrade.

This disclaimer does take a bit of weight out of our position. I think I'd like to see it stated like this:

Impact

This BUIP has the potential to fork BU off the BCH blockchain. This BUIP is not intended to facilitate a chain split. Should the BU client be incompatible with the final specification as a result of the November upgrade, an additional BUIP will be put forward as to whether or not BU will push forward with the outcome of the vote.

 

[solex]

@AdrianX
Thanks for your input. I would also like some other opinions here. The intention of these BUIPs are to determine the collective view of the BU membership, but also not to make a decision which implies a forking risk. The BUIPs are intended to bring more clarity to the debate while the November specification is still on the drawing board.

 

[AdrianX]

Thanks @solex I agree my original attempt may have sounded a bit confrontational maybe just the first sentence could suffice.

Impact

This BUIP has the potential to fork BU off the BCH blockchain. This BUIP is not intended to facilitate a chain split.

We don't need to disclose we intend to fold before all the bets are on the table.

 

[solex]

Link added to @Mengerian's article on yours.org
https://www.yours.org/content/the-story-of-op_checkdatasig-f79679d52b23

 

[sickpig]

@solex this is the temporary specification link: https://github.com/bitcoincashorg/bitcoincash.org/blob/0c098537b9aa3f812fa959697a133f93da0c89d7/spec/op_checkdatasig.md

once the PR about CDSV specification will be merged we need to change it.

 

[torusJKL]

Could we implement it but give miners the choice to deactivate them?
(Together with signaling what they did opt-in/out)

BU stands for unlimited coices and whether one wan'ts to support op codes or not should be a choice made by the one running the software.

 

[torusJKL]

@theZerg has written BUIP098 which addresses exactly the above.

 

[Roy Badami]

Could anyone point me at a description of the security vulnerability associated with accepting data without running it through a hash function? Just curious, and my Google-fu is failing me today.

(The Yours article mentions that the opcode has to hash the data because doing otherwise would be dangerous. I don't doubt this is true - and the single hash proposal presented here is clearly an elegant solution to hashing the data without impacting important use cases. I'm just curious as to the security issue.)

 

[theZerg]

I am going to vote "no" for this and expect that BUIP098 passes. But in general, I support the addition of these opcodes. Today, we have a general purpose scripting language but no access to external data. Yes, since we have a general purpose scripting language, it may be possible to implement something similar to this opcode in BCH script. However, this will result in extremely long scripts. We can implement multiply via if statement and addition, but that would be dumb. Its a better choice to provide useful opcodes...

BCH right now is like having a computer without internet -- its useful, but extremely limited compared to a device that HAS access to external data.

 

[Roy Badami]

@theZerg I don't see why voting "yes" is inconsistent with supporting BUIP098. Whether BU as a project is broadly in favour or against any particular change, we are (hopefully) all in favour of miner choice.

You've just expressed your personal opinion as being in favour of the change - why would you be against BU expressing it's collective opinion likewise (if indeed that turns out to be the collective opinion of the Members)?

 

[theZerg]

@Roy Badami Its a bit of a mess. I should have issued BUIP098 as a "counter-BUIP" to these to force the vote to happen at the same time, and to force one to win and the other to lose.

The reason I am voting "no" is because I want it to be completely clear that the HF changes can be implemented in a manner that allows the node operator and miner choice (as per BUIP098). It is definitely ambiguous but I am afraid that someone might argue that passage of one of these BUIPs means that I must accept a pull request that forces the feature on at the point of the Nov hard fork, rather than allowing it to be configurable. Best just to clear them out as "no" and vote "yes" for 098 when voting happens for that.

 

[Roy Badami]

To answer my own question, I guess this is the reason why ECDSA-without-hashing is considered a risk to the unwary (and why the proposal we're voting on therefore hashes the data).

https://crypto.stackexchange.com/questions/44862/ecdsa-signature-without-hashing-or-with-offloaded-hash

Basically, ECDSA (and DSA) don't have the expected properties of a signature scheme when used without a hash function. A hashless signature opcode would therefore be a trap for the unwary script author if they thought that, given their data would fit within 256 bits, they had no need to hash it. (Unless, of course they fully understood the limitations, and are confident that in their use case the optimization of omitting the hash function is safe. But such subtlty is asking for trouble - and the fragility of such optimizations is in any case, arguably, poor cryptographic design.)

(Read the question but particularly also the featured answer)

 

[Roy Badami]

@theZerg I think there is little to worry about, given the rider "BU does not desire unintended forks in the BCH blockchain, so the BU client will remain compatible with the final specification of the November upgrade". Even in the event that BUIP098 is not passed in time for the November fork, I still don't see this BUIP as harmful.

I guess it's all down to interpretation though, and I respect your decision (even though I personally think you're being overly cautious).