Topic: Justification for keeping IsStandard and introducing new standard tx types (Read 5144 times)

You're right, I think even without blockexplorer Satoshi would've added the IsStandard() check.  There were a series of "oops, didn't think of that" moments that pushed him to disable a bunch, tighten up some requirements on existing opcodes, and add IsStandard().

In general, I believe in "whitelisting" instead of "blacklisting" to try to prevent harm. Enable functionality that you can prove (or convince yourself beyond a reasonable doubt) will not cause problems. I'm strongly influenced from watching web content systems that fail repeatedly trying to detect malicious HTML or CSS.

RE: allow non-standard transactions but give them a very low priority so they take a very long time to confirm:  I like that idea.  I'll have to think a little more about possible unintended consequences (will they tend to fill up transaction memory pools and crowd out low-priority standard transactions?  Do they need their own memory-limited pool?  etc)

The intent was always to relax the rules when SPV/headers-only mode was implemented and non-mining clients didn't need to download the entire block chain.  However, nobody tackled that work (it is on my TODO list, right after I tackle some testing framework work).

I'm respecting Gavin's request that the linked thread not involve discussions relating to IsStandard.


Firstly, let me say that I'm very grateful that we have theymos' blockexplorer to examine transaction history. I also have my own tools which even break when someone does something unusual but nonetheless "standard".

However, if blockexplorer had never been made, would Gavin dispense with IsStandard? I think not. Therefore, the risk of breaking blockexplorer is not the main reason.

Arbitrary non-standard transactions could be analyzed when they are redeemed in an improved blockexplorer by showing the evolution of the stack as the scriptPubKey+scriptSig concatenation are executed. The only thing that would be difficult to establish automatically is what scriptSig contents would be required to redeem a non-standard transaction.

I suspect that the main reason for keeping IsStandard is a justifiable feeling of anxiety that non-standard transactions may lead to unanticipated, unwelcome behaviour.

We need to look at technical solutions to allay this problem.

I suggest that non-standard transactions be allowed but (for the moment) take a very, very long time to confirm. This would be easy to implement and remove the "unpleasant urgent surprise" that a quickly confirming malicious non-standard transaction might bring.

Another solution requiring more engineering but minimising the potential damage still further would be for non-standard transactions not to be even incorporated into blocks until they had been manually checked out and approved in some fashion. This is just suggested to provoke discussion.

ByteCoin