BUIP078: (passed) Enable Binary Contracts in Bitcoin Cash via OP_DATASIGVERIFY

[theZerg]

BUIP078: Enable Binary Contracts in Bitcoin Cash via OP_DATASIGVERIFY

This BUIP proposes that BU implement the OP_DATASIGVERIFY opcode, and reenable selected string and integer manipulation opcodes as described here: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-decision-based-spending-8e7b93d7bdb9

OP_DATASIGVERIFY allows a script to validate the signature on arbitrary data using the same ECDSA algorithm (and code) used to validate the signature on Bitcoin transactions. This opcode therefore enables the use of an external "oracle", which is a very important too to enable external information to be imported into a transaction. Once the data is part of a transaction it is useful to be able to manipulate it to check various conditions on that data. This requires the re-enabling of certain opcodes.

I believe that these opcodes were originally disabled when Bitcoin was the only cryptocurrency because the potential of Bitcoin as a simple payment system was too great to risk a setback due to and exploit in an immature code base for a secondary use case. However, now that cryptocurrencies are well established, it is time for some of these seconondary uses cases to be reenabled.

This additional feature will drive use and therefore adoption of Bitcoin Cash.


Specifically this BUIP authorizes us to:

1. Implement OP_DATASIGVERIFY, including all tests etc required to ensure the correctness and safety of the change.
2. Re-enable necessary string and integer opcodes, and clean up any issues with them.
3. Enable these opcodes on the BU "nol" network.
4. Work with the Bitcoin Cash community to enable these opcodes via hard fork on the Bitcoin Cash blockchain

 

[AdrianX]

I'm in support of enabling this opcode, but I would like to see BU move away from the build it they will come mentality I've seen with Core.

For feature BUIPs of this nature I'd:

1. like to vote to develop it (funded separately if required) test the development and see how it evolves.

2.Once the test results are in and any economic ramifications exposed then vote to have it merged into the main BU implementation.

I feel development and deployment are 2 separate functions. Not everything developed is worth deploying unless it is relatively simple to understand. Nothing really is, smart people developed and deployed segregated witness because they could, not because it was the correct thing to do.

I object to committing to decisions made before one can fully test and measure empirically the ramifications of one's choices.

If I commit to making a cake and I make a bad cake I don't need to eat it if it tastes bad. I can't know before I make it. We need more space to make mistakes and we need the space to learn from them and not be committed to following through with them.

 

[theZerg]

I and the other clients are not going to commit something bad into bitcoin cash. When you vote yes for this proposal i feel that it basically means "provided that the feature works as described".

Too many votes results in voter apathy and disengagemental which is why we try to vote for the big stuff.

 

[todu]

> which is a very important too to

I assume you mean "tool" and not "too".

> I believe that these opcodes were originally disabled when Bitcoin was the only cryptocurrency because the potential of Bitcoin as a simple payment system was too great to risk a setback due to and exploit in an immature code base for a secondary use case.

I think you mean "to an exploit" and not "to and exploit".

 

[AdrianX]

I and the other clients are not going to commit something bad into bitcoin cash. When you vote yes for this proposal i feel that it basically means "provided that the feature works as described".

I also dot want to get bogged down with bureaucracy but the development and the deployment function should be quite distinct and separate. I want to encourage creativity and experimentation and be ultra liberal on the R&D side, but when it comes to actually changeling bitcoin I want to be ultra conservative and very sure. Developers developing and testing can not give me the surety one needs to make pull requests to the main client. I want the protocol to be hard to change, but we may need more than a few weeks to actually make the commitment to change it.

This is not a matter of trust, I trust you @theZerg almost implicitly, more than any remaining Core developer today the problem is, if the feature works as described.

eg. I thought Segwit was actually a good idea when it was first described. The implementation did what it said on the box, but only after a lot of thinking about it did realize I don't wan't it to be committed to the bitcoin implementation and if it's is committed, I think it should be committed on the precursor that it should only be committed if we have a transaction capacity limit is above the actual transaction demand.

On reflection I would never have said no to the development but I would have said no to implementation under the existing circumstances.

 

[theZerg]

@AdrianX Please recall that you can always issue a blocking BUIP that says "let's NOT do X". If such a BUIP is written, the release is blocked until the BUIP is voted on.

Its really easy to thoughtlessly encourage other people to go off and waste a huge amount of their time. There are no negative consequences to you. So why vote "no" for any pure-research proposal?

Before I go off and waste that huge amount of time, I want people to actually think about this feature. After its all implemented, and works as described, I don't want people saying "oops changed my mind sorry, I don't want binary contracts in bitcoin cash". On the other hand, its fine to say something like "this implementation isn't what we voted for", "something much better came along", "there are a lot of issues/side effects with this idea/implementation that were not clear when the project started" (write a blocking BUIP).

So to get people thinking now, I want people to commit to a "blue-sky scenario" which ends in deployment into the Bitcoin Cash blockchain.
[doublepost=1511206626][/doublepost]

> which is a very important too to

I assume you mean "tool" and not "too".

> I believe that these opcodes were originally disabled when Bitcoin was the only cryptocurrency because the potential of Bitcoin as a simple payment system was too great to risk a setback due to and exploit in an immature code base for a secondary use case.

I think you mean "to an exploit" and not "to and exploit".

Sorry! I have typing issues lately. I'm not sure if its batteries that are low, the logitech wireless connector distance, firefox not responding quickly, me fat-fingering (due to switching keyboards), or all of the above.

 

[Christoph Bergmann]

Can you explain
- what possible exploits this opcode had?
- why the exploits are gone?
- what can this opcode enable? Just a simple example, because it is hard to imagine how and for what it can be used.

 

[theZerg]

question #1:
OP_DATASIGVERIFY is a new opcode so no prior exploits. But to implement binary contracts some disabled opcodes are also needed, and its those that I'm referring to when I say exploits.

The exploits in these opcodes mostly created scripts that consumed a lot of resources (CPU or memory) to execute, because the input data did not have boundary checking. For example, here is an exploit using the "if" opcode: https://bitslog.wordpress.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/ and a PR that solves it:
https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/842/commits/27d0a0657489b322daf89d9f41ff004c9203a56e

For example, OP_CAT concatenates two strings, and OP_DUP duplicates the top stack item.
So let's examine this script:

16, "this is data...." (push this on the stack)
OP_DUP (so stack is 2 elements: "this is data....","this is data....")
OP_CAT (stack is 1 element: "this is data....this is data...."
OP_DUP (stack is 2 elements: "this is data....this is data....", "this is data....this is data...."
OP_CAT (stack is 1 element: "this is data....this is data....this is data....this is data...."
.... (fill the entire 100k transaction)
OP_DUP
OP_CAT
16, 45894589734893
OP_MOD

So the OP_DUP and OP_CAT double the length of the stack item. Since OP_DUP, OP_CAT uses just 2 bytes, we can double the length 51183 times. This requires 2^51183 bytes of memory which going to crash all computers.

And then just to torture the CPU, we try to find the remainder of this incredibly long number divided by some constant.

Basically, reasonable bounds checking will allow us to re-enable these opcodes.

#2:
Exploits may still exist. Part of this effort is to fix them.


#3:
Binary contracts (AKA betting). For example, some independent authority posts cryptographically signed statements of daily stock closing prices, and another authority posts similarly signed statements containing sports results. These statements can be posted to any public place. If 2 people (potentially anonymous) who don't trust each other DO trust the authority then they can make a bet on the blockchain about the future price of a stock or the outcome of a sporting event.

Note that the authority who is posting signed statements is not involved in, or needs to be aware of, the bet -- it is simply exercising free speech, an activity that is legal in almost all jurisdictions.

Also, unlike escrowed bets, no third party ever has control or partial control over the funds.

 

[Christoph Bergmann]

#1 / #2

Thank you for your answer.

If I understand correct, you want to activate OP_Datasigverify plus some disabled opcodes on the NOL-testnet to search for bugs and exploits, and later activate it on BCH.

Do you have a solution for the OP_DUB and OP_CAT exploit?

If I think that

"OP_DATASIGVERIFY allows a script to validate the signature on arbitrary data using the same ECDSA algorithm (and code) used to validate the signature on Bitcoin transactions."

And remember this story

https://www.reddit.com/r/btc/comments/6zg1gp/those_large_bitcoin_cash_transactions_are_not/

it seems likely for me, that validating arbitrary data with ECDSA could cause heavy exploits. But maybe I just know not enough, and maybe limiting the size of data would effectively kill any attack.

What I wonder: Currently the client verifies arbitrary Data with the same ECDSA algorithm used to validate the signature on Bitcoin transactions, when it verifies a messsage, right? Is OP_DATASIGVERIFY just the same, but as part of onchain consensus rules? So it should be well and easily be tested?

#3

Cool! I think I get it, this could be a door-opener to a large variety of new blockchain applications, and what you essentially do, with this and with OP_Group, is to aim to make Bitcoin competible with Ethereum.

Is it possible to use this OP_code for a better multisig, for example? Or could it help making offchain-channels easier to implement?

--

After all, I think your recent work + the integration of public notes in BU is an indicator of a goalshift in Bitcoin Unlimited, less scaling, more smart contracts, right? Is there some background info about this shift - does it have something to do with the cooperation with nChain?

I'm all for starting this route, but I see some dangers in it, so I suggest to be very diligent with integrating those new OP_Codes + doing strong tests before implementing.

 

[satoshis_sockpuppet]

less scaling, more smart contracts, right?

Scaling and "smart contracts" aren't opposed. Store of value and cash aren't opposed. Bitcoin can do everything. The onchain scaling "roadmap" for BCH seems to be "uncontentious" and as BU is working on parallelisation etc. I don't see a "paradigm shift" here.

Personally I am all for a very cautious approach to changes in Bitcoin and I think a lot of "smart contract" ideas are more a nerd fetish than a real world need that needs to be fulfilled. But this BUIP looks good. It should enable a huge amount of easy contracts that actually are useful without a lot of overhead.

Most important, it would be very good for "marketing". BCH is the third most valuable cryptocurrency.
It beats No. 1 in it's own game, being a store of value and being a cash system.
And it will beat No. 2 in it's own game in allowing actually useful smart contracts without the Ethereum bullshit.

 

[theZerg]

#1 / #2

Thank you for your answer.

If I understand correct, you want to activate OP_Datasigverify plus some disabled opcodes on the NOL-testnet to search for bugs and exploits, and later activate it on BCH.

Do you have a solution for the OP_DUB and OP_CAT exploit?

If I think that

"OP_DATASIGVERIFY allows a script to validate the signature on arbitrary data using the same ECDSA algorithm (and code) used to validate the signature on Bitcoin transactions."

And remember this story

https://www.reddit.com/r/btc/comments/6zg1gp/those_large_bitcoin_cash_transactions_are_not/

it seems likely for me, that validating arbitrary data with ECDSA could cause heavy exploits. But maybe I just know not enough, and maybe limiting the size of data would effectively kill any attack.

Just like a transaction the data would be hashed and then the signature is validated on the hash. Yes, limiting the data size would solve these attacks... its possible that its already solved for my OP_DUP and OP_CAT script, I just made that up on the spot.

WRT the "spam" if he paid the TX fee I think that he can put junk in the blockchain. It'll just drive the fee up to the point where doing so doesn't make sense.

What I wonder: Currently the client verifies arbitrary Data with the same ECDSA algorithm used to validate the signature on Bitcoin transactions, when it verifies a messsage, right? Is OP_DATASIGVERIFY just the same, but as part of onchain consensus rules? So it should be well and easily be tested?

Yes, the OP_DATASIGVERIFY will call the already-existing and well tested signature validation code. And the oracle that generates the signed data can use the arbitrary message signing capability of bitcoind or of other bitcoin libraries.

You can actually do the same with OP_MOD and other crypto signature systems I'm told... but using the existing ECDSA makes it super simple for users and implementers.

Cool! I think I get it, this could be a door-opener to a large variety of new blockchain applications, and what you essentially do, with this and with OP_Group, is to aim to make Bitcoin competible with Ethereum.

Not really to compete. More like delivering the most useful 90% of the functionality at 1% of the risk. There's no reason you should have to make complex programmable contracts just to issue stock on the blockchain.

Is it possible to use this OP_code for a better multisig, for example? Or could it help making offchain-channels easier to implement?

The opcode opens up a lot of interesting uses, I haven't had time to really think about all the possibilities.

After all, I think your recent work + the integration of public notes in BU is an indicator of a goalshift in Bitcoin Unlimited, less scaling, more smart contracts, right? Is there some background info about this shift - does it have something to do with the cooperation with nChain?

I'm all for starting this route, but I see some dangers in it, so I suggest to be very diligent with integrating those new OP_Codes + doing strong tests before implementing.

Hmm, I wouldn't really call it a goal shift. The point of scaling is to allow all the awesome stuff that was promised us back in the inspirational talks of 2011 and 2012. The goal is and has always been to realize Satoshi's vision in all of its facets. Scaling was just the most immediate concern, but non-trivial scripts was always part of Satoshi's vision (otherwise why have scripts at all?). Also we need this awesome stuff to drive adoption of BCH. Without adoption our scaling work is wasted.

This and OP_GROUP is my own thinking and initiative -- it was not suggested by anyone.

However, subsequent to publication I realized that nChain is also interested in re-enabling the original opcodes. So we have a common purpose there.

 

[Christoph Bergmann]

Thank you for the answers. I'm excited to see how this turns out in reality and hope you get the support of the BU community. I'm all for it

 

[Mengerian]

Similar comment to BUIP077, I voted for the BUIP, but I want the developer to use his judgement for whatever best fulfils the goals of the BUIP, and not be bound by the technical details described here.

 

[Christoph Bergmann]

I agree with Mengerian and vote yes for BUIP078

Signed message:
BUIP078: Yes!

Signature
H5FAva6ZSPvuMJ6waeLLkeP7c1pyZmL2hsaADw9SZPazCrg0JOpnaqCwTDaIu+C4DYgweBXX6pDcDHUgA8uTKcw=