Christoph Bergmann said:



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. #1 / #2Thank 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 storyit 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. Click to expand...

Christoph Bergmann said: 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? Click to expand...

Christoph Bergmann said: 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. Click to expand...

Christoph Bergmann said: Is it possible to use this OP_code for a better multisig, for example? Or could it help making offchain-channels easier to implement? Click to expand...

Christoph Bergmann said: 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. Click to expand...

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.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.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.The opcode opens up a lot of interesting uses, I haven't had time to really think about all the possibilities.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.