Topic: Reliance upon transactions .vs. reactions to incidents (Read 1568 times)

Because they can be made not a security risk by the construction of a proper testing framework which can validate them. Most of the opcodes can be exhaustively tested, except for the ones that do crypto operations because the input spaces are too big, and those can be exhaustively tested by converting them to dummy versions with smaller input spaces (e.g. all even valued sig inputs validate as passing, all false fail).

If/when someone does the work to create such a testing framework and uses it to validate the opcodes, I think that would be a good argument for re-enabling them.

Script will never be changed in ways that cause many blocks to become invalid. If a script op needs to be disabled in the future and past transactions use it, the transactions will need to all be whitelisted.

But probably no more script ops will be disabled if there's any chance they can be fixed. Those ops that have been disabled were disabled when there was probably less than a thousand Bitcoin users. It was safer at that time.

Today I've learned how the transactions are encoded, which are actually scripts in a forth-like language.  The scripts are "executed" to validate the transactions.  The lack of tight regulation of how a "standard" transaction is to be encoded, allows for many different possible encodings (or forms of expressing) one and the same transaction.

The language is described here: https://en.bitcoin.it/wiki/Script and in fact near the bottom of the page is an interesting example of how to take advantage of the language to achieve a "non-standard" transaction (to a hidden receiver address).  The universal encoding by scripts potentially allows for many other cool features to be implemented.

However, I've also stumbled across a description of past incidents that required addressing by modifications to the client software. It's at https://en.bitcoin.it/wiki/Incidents and most notable is the last paragraph talking about LSHIFT and RETURN bugs.  Apparently, some script commands have been abused to induce errors into the clients.  As reaction, the commands have been disabled (instead of merely been fixed).  Moreso, many other "currently unused" commands have been disabled as well, "for security reasons".

I understand that script engines pose a security risk.

But there are two fundamental questions that immediately form in my mind.

1) If script engines are a security risk, then why is the majority of it still enabled even after reacting to the incident?  Wouldn't it be "safer" to enforce a fixed straight-forward encoding for every single desired form of transaction and do away with the scripts alltogether?  A smooth transition can be achieved easily (I can elaborate if desired).  It would make future incidents impossible, improving security of the software.

2) If on the other hand, scripting is desireable for the purpose of enabling non-standard ways of transacting to be supported by all clients, then it is already broken!  After all, a once "legal" scripting command like OP_XOR is "forbidden" today.  If I had implemented earlier something like "send to hidden receiver address" using OP_XOR, the transaction would not verify anymore in todays client.  It would stop at the illegal instruction, and ignore all further history of the coin (although previos versions of the same software would have accepted it!).

As a programmer, I cannot rely on using ANY scripting command, because I cannot know which may become disabled tomorrow.  Except maybe those which are generated by the majority of the clients in everyday transactions.  And even those could become invalid in the future (for example if scripts are being done away with).  The precedent is here already.

Therefore I ask:  How much can I rely on scripting?  Can I trust that any command that I use in a confirmed transaction, will not be blacklisted in the future?

I also ask:  Can the receiver of my bits rely on my cleverly scripted transaction to be un-revokable?  There's a spin on this, beware!  Let me give you an example.  Bitcoin buries transactions in the blockchain, making it harder to doublespend as time passes.  If I were malicious, I could find a new bug in a script command.  I could use the command to form a harmless transaction (not triggering the bug).  It would work fine in the existing clients and make it into the blockchain.  It would give ownership of my money to somebody else, and it would be confirmed after a certain time.  The receiver of the coin would believe that I cannot undo the transaction.  But possibly I can?   I could publish an evil exploit based on the command that I used in my transaction, and encourage the developpers to disable the command just like they disabled OP_XOR.  The new (fixed) clients would not be able to parse the transaction anymore.  The coin would fall back to me RETROACTIVELY, as I am the last legitimate owner (by the now changed rules).  The validity of the chain of transactions would break at my special script, and I could start a new valid branch by spending the coin again (using valid script commands).

I am aware that this is an example taken to the extreme, but it serves to show how either decisions about scripting security can have unexpected sideeffects.

Opinions on this post?  Or maybe even comments from those involved in the decision of disabling commands?