Topic: (Unrelated to block size) Hardfork/P3SH proposal: OP_RETURNTRUE (Read 1397 times)

As a minor aside, it might be better to use the following


This means that old nodes would still check the signature.  If the signature is wrong, it fails due to OP_CHECKSIGVERIFY.

It then checks the locktime and old nodes just assume that the locktime is OK.

This isn't critical though, the assumption is that a soft-fork is safe due to >95% miner acceptance.

Thanks. I'd like to show it by OP_CLTV

In BIP65, OP_NOP2 is redefined as OP_CLTV. A simple CLTV scriptPubKey would be like this:


For upgraded nodes, OP_CLTV will check whether the locktime is greater than . If not, the script fails immediately. If yes, OP_CLTV will do nothing, and OP_DROP will drop the from the stack, and the OP_CHECKSIG will verify the signature.

For old nodes, OP_CLTV is just OP_NOP2 and is ignored. It will then drop and verify the signature.

Since the new rule is more stringent than the old one, this is a softfork.

-----------------------

With OP_RETURNTRUE, the scriptPubKey would become:

Code:

 OP_CLTV  OP_CHECKSIG

For upgraded nodes, OP_CLTV will check whether the locktime is greater than . If not, the script fails immediately. If yes, OP_CLTV will drop the from the stack, and the OP_CHECKSIG will verify the signature.

For old nodes, OP_CLTV is just OP_RETURNTRUE which automatically declares the script as valid.

Again, since the new rule is more stringent than the old one, this is a softfork.

----------------------

The difference may not be obvious in the OP_CLTV example. But for OP_CAT, it is not possible by simply redefining OP_NOP 

If having a hardfork is too scary, we can introduce OP_RETURNTRUE with the P3SH softfork.

OK. You say that hardfork is something "bad". It would be better to use softforks instead the hardforks.
Right?
So, the solution is: let us create one big hardfork now for several future improvements instead of several future hardforks.
But I doubt: is one big hardfork is better than several small ones?
I do not see any difference in general.

Well right.  I meant that new features could be added without another hard fork.


A soft fork can already be used to modify the scripting language.  A soft fork could be added to require all outputs use something like P2SH but with entirely new rules.

There are suggestions for "P3SH" which adds new sighash rules and the "MAST" system which allows merkle trees to be used to define new output scripts.

This system would allow new opcodes to be added in a cleaner fashion.  Nodes which don't understand the opcodes would just accept the script.

Not me, but majority of hashpower.
But majority can do everything whenever.
Majority can not be stopped by any rule, protocol change and hardfork risk.

Right.  That is how soft forks work.

The 95% threshold is to make sure (almost) all miners have upgraded. 

Once 95% of miners agree, they will reject any transactions/block which violates the new rules.

Legacy nodes might accept unconfirmed invalid transactions, but they would never be accepted by the network.

If they wait for the transactions to be confirmed, then the risk is avoided.

If they want to confirm all the transactions themselves, then they have to upgrade.

Legacy nodes don't have to actually use the new opcodes.  If the transaction doesn't have the new opcodes, then it works the same way as previous ones.

The safest plan would be to give a warning if one of the inputs used the new opcodes and the warning would go away once the transaction was confirmed.


It is to allow soft forks to add new functions.  If old nodes hit those opcodes, they just accept the transaction. 

That means that you can add anything you want.

So, it can be used against old nodes (especially miner nodes)

scriptPubkey:redeeming script:is evaluated by old node as `true` because of OP_RETURNTRUE1

I still do not understand the problem you are trying to solve with new behavior of opcodes.

His proposal is to add some OP_RETURNTRUE opcodes.

Since it is a hard fork, new opcodes could be used.

• 186: OP_RETURNTRUE1
• 187: OP_RETURNTRUE2
• ...
• 195: OP_RETURNTRUE10

Once these opcodes are added, then you can use any of them to instantly mark a transaction as valid.

This means that you can add new features that do pretty much anything.

The example given was OP_CAT.  This means take the top 2 items on the stack and combine them into a single array.

An output could be created with the following scriptPubKey.


To spend this you need to push two arrays onto the stack that concatenate to the given array.  You could push two 4 byte arrays.


New nodes would be able to process the new opcode fully and check the script is valid.  Miners would run the new software.

In the example, OP_CAT is only of the OP_RETURNTRUE opcodes.  Ild nodes would see the scriptPubKey as


When they process the transaction, they will first push the two four byte arrays onto the stack and then execute the scriptPubKey.  The first opcode says return true, so they will accept the script as valid.

The key point is that they allow soft forks to have opcodes with any functionality.  If an old node hits one of these opcodes, it just says "I don't understand this opcode, so will accept the script".

How do you want to change "OP_CLTV OP_DROP" to one "OP_RETURNTRUE"? Please write an usecase.

Anyway, do you want to save a couple of bytes in several transactions?
I do not see significant reasons here for hardfork and changing scripting engine.
There are a lot of possibilities to save a couple of bytes in each transaction (for example, DER-encoding signature takes 72 bytes but we can encode it to 64)

Technically no because you can always introduce a new version of P2SH, but with OP_RETURNTRUE things become more efficient

Take BIP65 CLTV as example. It currently takes 2 bytes: OP_CLTV OP_DROP. If we had OP_RETURNTRUE, only 1 byte is enough.


I'm pushing this proposal only if we have a block size hardfork

My understanding of the proposal is that the main motivation is exactly to avoid costly hard forks in the future.  I. e., if a hard fork has to be done anyway for some reason, this change can be included.  The advantage of the redefinition of the opcodes is then that some changes that are hard forks now can be implemented as soft forks in the future.

Hard forking bitcoin is a difficult process requiring significant costs in terms of discussion, community outreach, and testing (particularly, switching to the hardfork). The functionality provided by this opcode appears to be esoteric at best (unless I'm missing something?), so I don't think it's worth the trouble. (Good thing about this: it shouldn't be controversial). It might be appropriate for a scripting-focused sidechain however.

I don't think this is worth a hard fork but it is an interesting idea.  

It would have been useful if half the nops were "do nothing" and half were "return valid".  I assume the rule would be that OP_RETURNTRUE would not be allowed in the sigScript.

If a small set of low-risk hard forks could be combined together, then maybe they could all be implemented as a single omnibus hard fork.

They would have to be low risk of causing bugs and non-disruptive.  Non-disruptive means that it doesn't alter the balance of power of the system.  

Under that definition, a block size change would be disruptive, since it shifts the balance between store of value and transaction volume advocates (or off-chain vs on-chain transaction advocates).

I think forks that meet this definition could be implemented by 1 year notice period and no need for miner votes.

On the list fixing the "off by one" bug was suggested as a hard fork that was worth fixing.

I think adding an auxiliary header would be worth doing.

aux_header_hash = Hash(header[80:N-1])

block_merkle_root = Hash(transaction_merkle_root | aux_header_hash)

The auxiliary header length could be limited based on the block version.  If a node doesn't know the block version, then it would accept auxiliary headers of any length.

This means that adding fields to the aux header would require a soft fork.

This can be used for various commitments, UTXO set and the sum trees.

Are there any cases with this opcode which we can not perform with the current scripting?

In the upcoming block size hardfork, I would propose to have a relatively simple change by introducing a new OP code: OP_RETURNTRUE

When the script engine reads an OP_RETURNTRUE, it will evaluate the script as valid immediately, regardless of what happens after that.

OP_RETURNTRUE is a "non-push OP code" in BIP62. Putting a bare (non P2SH) OP_RETURNTRUE in the scriptSig will immediately invalidate the script.

We may have OP_RETURNTRUE1, OP_RETURNTRUE2, OP_RETURNTRUE3, etc as long as we have enough unassigned OP code.

------------

OP_RETURNTRUE is useful if we want to introduce new OP code to manipulate the stake. For example, if we want to reintroduce OP_CAT, it is not possible to do it with OP_NOP because it doesn't allow rewriting of the stake content. Currently, the only way to introduce OP_CAT is by a new version of P2SH.

With OP_RETURNTURE, we can directly redefine it as OP_CAT, and it will instruct the script to concat the top 2 stake items. Since the new OP_CAT does not return a true directly, this must be a softfork by definition.

We may even redefine those unused OP_NOPs into OP_RETURNTUREs. Because OP_RETURNTURE can do everything that an OP_NOP may do. (We can turn an OP_RETURNTURE into OP_NOP with a softfork, for example)

-------------

If this OP_RETURNTURE reminds us the nightmare of CVE-2010-5141 (http://bitcoin.stackexchange.com/questions/25225/what-was-the-vulnerability-in-v0-3-4-that-allowed-an-attacker-to-steal-coins), I would suggest to turn those unassigned OP codes into OP_NOPs (still a hardfork). It will defer the needs of using double bytes OP codes

-------------

EDIT (2015-Sept-1): This could be a softfork, if we put it into "P3SH". This will defer the needs to have a new version of P2SH every time we want a new stack manipulating OP code.