Topic: [RFC] On the usefulness of scripting (Read 2145 times)

+1 agreed

Sounds like a good initial plan.  Let me think about the best way to approach this in the client, as it involves multiple coordinating parties.

Making IsStandard() return true if fTestNet is a good idea.

The process for getting a new transaction type into bitcoin would be to test it thoroughly on the testnet, get general consensus on its API and/or GUI and that it is useful, safe, and unlikely to be abused, and work with the 'infrastucture' sites (like blockexplorer and bitcoinmonitor) to make sure the right APIs or hooks are in place so they can do something intelligent with the new transactions.

The first step to playing with interesting scripts is to re-enable non standard transactions on the testnet. I keep meaning to do this but have been busy with other things, like making the testnet-in-a-box.

It's disabled, so it's not a current vulnerability. From script.cpp:

These use cases don't use multi-in or multi-out.  They have multiple pubkeys on a single output.  This allows multiple parties to cooperate in a transaction.  There's no way to implement escrow and such without scripts.

I agree that there should be a careful security review, but I don't think it's that difficult.  The main thing is to do validation of length and bounds, and have multiple reviewers of the code.

I went over the code and I don't actually see that many disabled operations.  Unless I am missing something, currently all clients accept blocks with complex scripts.   They only reject mining them.  So a miner could insert complex scripts into the block chain.  The security of the system as it currently stands does depend on making sure the scripting system is secure.

One thing I do notice is that OP_MUL doesn't have a bounds check.  Clients can be crashed with a few OP_DUP + OP_MUL in an otherwise valid block.  This seems to currently be a security issue.  I can do a more thorough review in a few days.

That's an interesting idea. It would be much better than relying totally on a trusted third-party to handle it, since they can't steal your money in this case.

Many of the script ops (like OP_XOR and OP_MUL) were disabled when it was found that some of the arithmetic ones could be exploited to crash all Bitcoin nodes. Those need to have their security closely examined before they are enabled again.

I'm also strongly in favor of removing IsStandard restrictions, especially when relaying transactions. I modified my node to accept non-standard transactions, though I don't mine, so it doesn't matter much.

Because scripting is mostly disabled and difficult to get right in a secure way, I would rather just strip it out, for btc2.

You can do signed validation and multi-in, multi-out without a script engine.

I found scripting to be one of the more attractive features of bitcoin.  Standard transactions just check that the receiver signs using their pubkey.  But the scripting language can do much more interesting things.

However, the scripting language is currently mostly disabled.  Only two simple types of scripts are allowed in the standard client due to the implementation of ::IsStandard() and Solver() - script.cpp:967.  Any transactions with a different script form will not be relayed or mined.  A block with such a script will be accepted, so miners can choose to extend support.  But it would be ideal if some scripting is allowed for mining and relay in the standard client to allow for wider adoption.

Low trust escrow

The transaction script can be in the form of:


or even:


This allows the transaction to be finalized by a third party escrow and either the sender or receiver.  None of the parties have to be trusted with the coins.

Immediate transactions

The problem with using bitcoin in time sensitive settings is that it takes many minutes for transactions to be confirmed to achieve low probability of double spends.  It would be ideal for some applications (e.g. mobile payments) to have immediately verifiable transactions.  This can be achieved with a variant on the escrow script.  The funds are converted to "certified funds" ahead of time:


The funds can then be spent incrementally by having the sender and certifier collaborate to create a transaction.  The certifier is a trusted third party that guarantees no double spends using its reputation.  If it sees too much spends for the funds, it simply refuses to cooperate in the creation of the transaction.

So what would it take to re-enable more general scripting?