PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)

[chrisrico]

Could this be tested on testnet before it becomes mandatory in prodnet? Isn't that a good place to test potentially forking changes?

[1713919730]

1713919730

[1713919730]

1713919730

[1713919730]

1713919730

[1713919730]

1713919730

[finway]

Could this be tested on testnet before it becomes mandatory in prodnet? Isn't that a good place to test potentially forking changes?

It has.

[Stefan Thomas]

It basically makes a special-case out of a specific template. This is like saying "if you see a program that does X, instead of executing it, execute something else instead".

True! But this is a valid way to get backwards compatibility when extending a syntax. For example, C preprocessor directives like "#ifdef" are actually comments, but when a compliant preprocessor is present, they are executed before the actual code is compiled. Now, Alan Snyder, when he pushed for the addition of the preprocessor could have instead opted to add "eval" to C or he could have added special operators or keywords. But arguably, using a preprocessor with a backwards compatible syntax for this situation was a better choice.

I don't follow the argument that it's somehow best to solve the issue of moving the script from scriptPubKey to scriptSig on the scripting language level.

The reason we get these awkward domain-specific proposals (OP_DOSOMETHINGVERYSPECIFIC) or ultra-powerful proposals (OP_EVAL) is precisely because it's not generally the job of a programming language to move its own code from one place to another.

For example, to implement OP_CODEHASHCHECK we would need to change EvalScript to know about where scriptSig ends and scriptPubKey begins. The scripting language is not meant to be aware of the block chain, it is meant to be a simple, stack-based language.

P2SH does not require any change to EvalScript. That's because P2SH is not a change to the scripting language at all. It is a backwards compatible change to the block chain, allowing for a hash to reside in the transaction output and for the script to be executed to reside in the corresponding input. That strikes me as much cleaner than meta-opcodes which hack into the interpreter to move code around.

To clarify: I'm not arguing that implementation concerns should guide our protocol-level decisions, but what I am saying is that in this case the implementation hacks hint at a design-level problem. Namely that we are trying to make a scripting language do a preprocessor's job.

Finally, this provides a very pragmatic reason for P2SH. Because it doesn't change EvalScript, it doesn't require nearly as much testing as the other proposals. I'm ok with Luke's idea (in fact I suggested to roconnor that he drop backward compatibility from his OP_CODEHASH proposal and that would have been CHC/CHV), but I prefer P2SH and I would request a much longer testing period if CHC/CHV was accepted.

[piuk]

Gavin,

I just wanted to double check that it has been considered what would happen if the serialised script itself matches the P2SH template. From the wording of the BIP it's sounds like it probably has been considered:

only considered standard if the serialized script is, itself, one of the other standard transaction types.

Otherwise there might be dos potential in a script of the following format:

scriptSig: <sig> <serializedScriptA> <serializedScriptB>
scriptPubKey: OP_HASH160 <scriptBHash> OP_EQUAL

Where <serializedScriptB> deserializes to "OP_HASH160 <scriptAHash> OP_EQUAL".

If only <serializedScriptB> was checked as being standard then a potentially malicious script could be hidden in <serializedScriptA>i.e. <serializedScriptA> could contain hundreds of OP_CHECKSIG's
 

[Stefan Thomas]

If only <serializedScriptB> was checked as being standard then a potentially malicious script could be hidden in <serializedScriptA>i.e. you could <serializedScriptA> could contain hundreds of OP_CHECKSIG's

serializedScriptA would never be executed, so it can contain whatever it wants. To the script interpreter it would be just a piece of data. P2SH only transposes the last stack item.

[piuk]

P2SH only transposes the last stack item.

Agreed but in my understanding the initial scriptPubKey would transpose <serializedScriptB> into another scriptPubKey that if allowed would transpose <serializedScriptA>. If it isn't already an exception needs to be made so that the scriptPubKey resulting from deserializing <serializedScriptB> it can no longer be interpreted as a P2SH scriptPubKey.

[Stefan Thomas]

Agreed but in my understanding the initial scriptPubKey would transpose <serializedScriptA> into another scriptPubKey that if allowed would transpose <serializedScriptB>. If it isn't already an exception needs to be made so that when the scriptPubKey is deserialized from<serializedScriptA> it can no longer be interpreted as a P2SH scriptPubKey.

No, the preprocessor only runs once, so there is no recursion.

[Brunic]

Hey guys,

Your work is really crucial, and this modification seems really important. But saying that I understood at least half of it is a lie. At the moment, understanding girls seems easier than what you're talking about.  If you want to have at least 55% of the miners to understand this, explain it clearly and simply.

I was asking an explanation as I were your grandmother.

My grandmother also want to understand. Please, explain to us the big picture if you want the modification to happen. And if you're against, what do you suggest instead (again, in a simple way)?

Thanks!

[ByteCoin]

Please, explain to us the big picture if you want the modification to happen.

At this stage in the proceedings, with the resources out there to educate yourself, if you don't understand what's being discussed, your opinion is not relevant.

ByteCoin

[piuk]

Never mind, i'm an idiot. Proposal withdrawn.

[Brunic]

Please, explain to us the big picture if you want the modification to happen.

At this stage in the proceedings, with the resources out there to educate yourself, if you don't understand what's being discussed, your opinion is not relevant.

ByteCoin

I know my opinion is not relevant on that case, you learn me nothing new. My job is to mine, not to code and discuss Bitcoin scripts about OP_WHOCARES. But my GHash are relevant in that situation, and that's the same for all the miners out there.

I just came here to know about the situation, and help you to inform other miners about this if it worth it. I taught that having a simple message about the modification, so you can convince around 6 THash to adopt this could be a good idea.

But hey, if you don't give a **** about it, that's fine. I'm going to make the extra step in February to be sure that my workers don't support that modification. Seems Luke don't support it, so I'll ask him for any advice if I need them.

Thanks!

[notme]

Your opinion matters, but like he said, all the information is out there.  A clear explanation will be given when a new client is released with one of these features if you can't bother to get up to speed to contribute to the decision of which route to take.

[notme]

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius 

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

[teflone]

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius  

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

From what little I gather

p2sh requires a change that is incompatible with the current chain and way of doing things..It ultimatly requires everyone to upgrade..
Which is fine for me, because progress is being made..

Other people are suggesting other ways to allow multiple signatures using the current chain, and not needing an upgrade.

Please please correct me if Im wrong..

I have faith in Gavin.. plain and simple.

[notme]

i dont understand how this thing works, i wont support this because is way to geek for me, since we vote with hashing power i will point my workers to eligius  

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

From what little I gather

p2sh requires a change that is incompatible with the current chain and way of doing things..It ultimatly requires everyone to upgrade..
Which is fine for me, because progress is being made..

Other people are suggesting other ways to allow multiple signatures using the current chain, and not needing an upgrade.

Please please correct me if Im wrong..

I have faith in Gavin.. plain and simple.

Every proposal will require upgrade.  That's not the issue.  The question I asked gets at it I believe, hopefully someone more knowledgeable will answer me.  It boils down to adding an OP code vs tainting the scripting system with a special case template.  Gavin just wants to be done with this functionality as this is the second attempt at implementation.  Luke-Jr isn't convinced it's the correct solution and has provided a simpler alternative that extends the protocol with an OP code instead of changing block validation rules.

[piuk]

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack.

[notme]

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack. I hope they will both take a look at https://en.bitcoin.it/wiki/BIP_0017_DRAFT - It could be a good compromise.

Thanks for the clarification... I was thinking of OP_NO_SKIP, but I got it confused with the proposal in Luke-Jr's thread.  Would it be possible to create a pull request to make it easy to see just the OP_NO_SKIP changes from github.

[Pieter Wuille]

I commented on OP_NO_SKIP here: https://en.bitcoin.it/wiki/Talk:BIP_0017_DRAFT

This will not work. You demand from the txin (the one claiming the output) to do his own verification, by requiring the OP_NO_SKIP to be in the input. Verification should be enforced by the output. What your standard transaction output does is only check that a particular script was pushed on the stack. It does not require its execution.

[kjj]

Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.

scriptPubKey: OP_P2SH OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack.

OP_P2SH doesn't have to be OP_EVAL.  See here.

[piuk]

This will not work. You demand from the txin (the one claiming the output) to do his own verification, by requiring the OP_NO_SKIP to be in the input. Verification should be enforced by the output. What your standard transaction output does is only check that a particular script was pushed on the stack. It does not require its execution.

Yes I caught this mistake after I posted it. Thanks for taking a look anyway.

One more attempt before I give up https://en.bitcoin.it/wiki/BIP_UNOFFICIAL_DRAFT