Testing so that opcodes can be re-enabled

jl2012

legendary

Activity: 1792

Merit: 1122

Quote from: Mike Hearn on July 12, 2013, 12:07:00 PM

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.

Mike Hearn

legendary

Activity: 1526

Merit: 1136

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 ....

Sergio_Demian_Lerner

hero member

Activity: 555

Merit: 654

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.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: gmaxwell on July 14, 2013, 10:03:32 PM

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:

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