Topic: Testing so that opcodes can be re-enabled - page 2. (Read 3072 times)

Well, I wouldn't say nobody wants to research possible future versions of script. Gavin actually told me he wanted to brainstorm Script 2.0 at some point .... it's just that I already did a lot of research into ways of using our existing capabilities and almost none of it has been implemented. This leads to a kind of "death spiral" where the moment someone notices a problem or potential issue with some functionality, instead of getting fixed (hard) it gets disabled (easy), which can be justified because nobody uses the features. We lost tx replacement entirely that way, we lost opcodes that way, we'll lose more in future if we're not careful.

So before we invent new scripting languages, we need to reverse the decline in the existing one. That means instead of just researching and reporting DoS vulnerabilities or bugs, actually writing real fixes. It means creating compelling applications that use the feature set we have to ensure it can't be just switched off on the grounds that nobody uses it and it poses additional risk.

In other words, what we need is people writing code, lots of it. That's why I focused my own research on how to use the features designed by Satoshi and not on Bitcoin 2.0.

IIRC early versions of the scripting engine also gave access to the height of the blockchain. Theoretically you could do very interesting things if the script had access to the data in the blockchain, or at least to all ancestor transactions. Not all of these things would be good, taint-based policies come to mind as a bad example.

I have a hundred ideas of marvelous futuristic things that could be done with a rich script system, that can read the transaction inputs and the transaction outputs.

This is my wish list:
 PUSH_INPUT_AMOUNT / PUSH_INPUT_SCRIPT / PUSH_INPUT_COUNT (to control how money is used)
 PUSH_FEES / PUSH_OUTPUT_AMOUNT / PUSH_TOTAL_OUTPUT / PUSH_OUTPUT_COUNT (to control how money is spent)
 PUSH_BLOCK_DATE / PUSH_BLOCK_NUMBER / PUSH_BLOCK_HASH  (to control time, and random values)
 PARSE_SCRIPT_TOKEN (for previn/prevout parsing right in the script)
 PUSH_PREVTX_OUTPUT (for tx compression)

All these opcodes (maybe with the exception of PARSE_SCRIPT_TOKEN) are completely secure and it's impossible to mess things up implementing them.

You could do things like persistent transaction-sequences (inputs that are virally copied to outputs).

And once you have persistence, you can have autonomous transaction behavior, such as paying fees every month, limiting the spent amounts, etc.
These are like contracts that persist over time and over transactions.

I'm sure that if I tell you each one of my ideas you will be delighted to use them and you'll find ten more use cases that I didn't think of.

But there is this chicken-and-egg problem: because opcodes are not enabled (and probably won't be) nobody wants to research about them.

Best regards,
 Sergio.

Script has the advantage that it allows people to implement new features without needing central authorization.

Ideally, scripts should be made more general, or specific use case upgrades to the script system need to be supported.

yeah, it was stupid to disable these commands. there is no way to turn them back, cause that would make even more trouble
but at the other hand, who would need to use them anyway - bitcoin chain is not a calculator. nobody even uses ifs yet

The disabled opcodes could become more useful if they had more data to work with than the signature script. Not something that should happen any time soon, but thinking about it now can't hurt.

The most useful thing to reactivate would be tx replacement - re-adding opcodes is a hard forking change at this point and nobody has any use cases for them, whereas tx replacement is not a hard forking change and it'd be useful for some real things.

From here, Gavin says that re-enabling disabled opcode (and adding new ones) requires some kind of systematic testing framework.

Most of the opcodes were disabled with a "misc change" commit.

From here, the issues are listed.  However, no info is provided about what actually happened.

These are the ones that seem script based

- LSHIFT opcode could cause crash
- Some way to fool the script to allow transctions to be spent [ * ]
- Script executed to much processing

The success of disabling opcodes as a protection is shown by the fact that they are the first three issues and then script never caused a problem.

So, it looks like the main threats are client crashing, processor over usage and scripts mis-calculating the output.

Running the opcodes in a mini virtual machine should cover the processor problem and the crashing problem.

The virtual machine would do bounds testing on all arrays.

Each opcode would have to be given an estimate of how long it takes.  Each time an opcode completes, the processor usage is incremented by that amount.

There would a threshold for processor usage per output. 

The stack would have to be tested very carefully.  A maximum stack size could be set.

If is it working, then (many) opcode could be tested exhaustively.  If that is not possible, then they could be tested with a smaller search space and also with random instances.

A left shift opcode could have full test for 4 byte arrays and then random 32 byte arrays, for example.

It could also be tested with random stack settings.  The parts of the stack that are not affected would be checked to make sure they didn't change.