Testing so that opcodes can be re-enabled

[TierNolan]

isn't that the purpose for test net 3 bitcoins? why not try it out on them~~~

That sounds reason.  Re-enable all the opcodes for testnet?

[Peter Todd]

isn't that the purpose for test net 3 bitcoins? why not try it out on them~~~

That sounds reason.  Re-enable all the opcodes for testnet?

Testnet has to match mainnet, so the removed opcodes are still removed. By all other transaction types are valid - testnet doesn't use the IsStandard() tests.

If you want to test new opcodes on testnet, go right ahead. It'll just mean you get forked by the rest of testnet, not a big deal.

[gmaxwell]

Probably the most interesting thing in testing this stuff is coming up with uses for them. Doing so would guide which ones were more important to add. (and this is key: it should probably be thought of as _add_ not re-enable, since adding can be done as a soft fork, a lot easier and less risky)

[d'aniel]

A p2p prediction market would be a pretty cool use case.  This could also be used to hedge FX risk of holding bitcoins.  I guess it might work something like this:

An oracle publishes the hash of a secret, and the secret as well if a given event occurs before some expiry date.

With this setup, we want anyone (a writer) to be able to construct a tx with a txout (the contract) whose script allows only the buyer of the contract to spend it before the expiry date, and only if he can provide the secret.  Furthermore, we want only the writer to be able to spend the txout after the expiry date.  I think this only additionally requires the PUSH_BLOCK_DATE opcode that Sergio proposed above.  The writer would include a second txout that spends to him the price in bitcoins he's asking for the contract.  He would sign inputs that add up to the contract txout plus any tx fee, and the buyer would provide the rest of the inputs required.

It would be nice if trust could be spread across multiple oracles by requring m of n secrets for the buyer to spend the txout.  We don't have OP_AND or OP_OR, so I guess we'd need these or maybe a special opcode just for this purpose?

A really nice feature would be if the person buying this contract were able to spend it on the blockchain without requiring a signature from the person writing it.  Then we could have trust free (ignoring underlying trust in oracles) secondary markets for these contracts.  Could this be done using the transaction persistence you mentioned, Sergio?  I guess the condition for the buyer to be able to spend it before the expiry date, but without the secret(s), would be that the tx which spends it has a txout (the replacement contract) of greater or equal value, and with the same script, except with the original buyer's address replaced by the new buyer's.

[TierNolan]

Probably the most interesting thing in testing this stuff is coming up with uses for them. Doing so would guide which ones were more important to add. (and this is key: it should probably be thought of as _add_ not re-enable, since adding can be done as a soft fork, a lot easier and less risky)

You mean using nops?  My understanding is that a script containing a disabled opcode will fail.

Maybe it could work like the P2SH code.

Pub key:

<script - version> <ignore> <actual script> OP_EXECUTE OP_DROP OP_DROP OP_DUP OP_HASH160 <hash of address> OP_EQUAL_VERIFY OP_CHECKSIG

sig script
<hash of public key>
<signature>
<hashes for actual script>

This means that old clients won't allow spending unless you have the standard public key.

Colored coins would still want to make sure that the spend is authorized, so the <actual script> would .

New clients would run the actual script too.

The rules could be something like

- reject script if <script - version> of any output is not a network accepted version
- reject script if it has more than 1 OP_EXECUTE opcode
- run <actual script> with 2 + <ignore> items popped off the stack (2 + 2 in this case)
-- transaction is invalid if this script fails

This would need to be combined with a rule for updating the script number.  

For example, if 550 out of 1000 blocks have /SCV+<n>/ in their coinbase transactions, then from 2000 blocks later, scripts of that version would be allowed.  If there is 55 out 100 with </SCV-<n>/, then that disables that script version.

The rule for miners would be to not include any transactions that they cannot verify in their own blocks.  A warning would also be given recommending upgrading.

[Sergio_Demian_Lerner]

I have the following proposal:

Why don't we schedule a hard fork for 2014 to enable 50 additional opcodes that we know for sure that cannot have any semantic ambiguity or security flaw?

For example: OP_PUSH_BLOCK_DATE.

We also re-standarize small/fast arbitrary scripts (say no more than 10 ops, no more than 5 sigs)

So we give researchers and innovators a whole bunch of tools to try new ideas for real.

[Mike Hearn]

I think the first step would be to make a forked Bitcoin that implements them all (with unit tests), run a little testnet with them, and then write some cool apps that use them.

It's much easier to build consensus for big changes when there's an app everyone wants just sitting there, waiting to be activated ....

[jl2012]

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.

Why tx replacement is useful? There is no method to prevent miners mining a transaction with lower sequence.