Old P2SH debate thread

[notme]

With code that make sense, does it work? 
Dose is solve the "Special Case" problem?  does it cause a split?

Hey look... an explanation of what the code does earlier in the thread:

I still haven't figured out how OP_CODEHASHCHECK is intended to work, so I wouldn't say that I'm a convert exactly.

Here is my explanation of luke's proposal as I understand it. Standard script template for a single key would be:

scriptPubKey: <scriptHash> OP_CHECKHASHVERIFY
scriptSig: <sig> OP_CODESEPARATOR <pubKey> OP_CHECKSIG

1) Combine ScriptSig & ScriptPubKey

   <sig> OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

2) <sig> is pushed onto the stack
   
   OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

3) OP_CODESEPARATOR marks the beginning of the data to be hashed

   <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

4) <pubKey> is pushed onto the stack

   OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

5) OP_CHECKSIG validates <sig> and <pubkey> as normal

   <scriptHash> OP_CHECKHASHVERIFY

6) <scriptHash> is pushed onto the stack

   OP_CHECKHASHVERIFY

7) Everything from the marker that was set at OP_CODESEPARATOR up to stack -1 is hashed and compared with the top stack item e.g. <scriptHash>. If equal the script is valid.

Advantages
- Like P2SH hash enables "pay to script" functionality - transfers multiSig fees from sender to receiver & reduces muliSig blockchain bloat.
- The script interprets as a script, no magic code path based on template matching.
- Static analysis without deserializing anything.
- Fairly simple, should be just as fast to get it in use as P2SH. Luke has coded it already.

Disadvantages
- Old clients validate almost nothing, with P2SH they at least check the <scriptHash> matches the <script>
- Requires redefinition of an op code

As far as I understand, old clients (miners at least) will need to be upgraded with any of these methods to ensure they don't create blocks the new code considers invalid.

[1714176323]

1714176323

[1714176323]

1714176323

[1714176323]

1714176323

[1714176323]

1714176323

[1714176323]

1714176323

[Gavin Andresen]

RE: Why OP_CODEHASHVERIFY is bad:

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.

Part of the fix was to make executing the scriptSig completely independent of executing the scriptPubKey (see commit 7f7f07 in the tree if you're really interested).

Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out.

Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails.  So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL.

Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic.  OP_CODEHASHVERIFY is almost as risky as OP_EVAL.

Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey.  I think he is just trying to do whatever he can to cause trouble and confusion.

strikethrough added:  I read through his code again and his code is a joke for a different reason than I thought at first glance (I missed the vchLastScript nonsense).

[finway]

RE: Why OP_CODEHASHVERIFY is bad:

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.

Part of the fix was to make executing the scriptSig completely independent of executing the scriptPubKey (see commit 7f7f07 in the tree if you're really interested).

Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out.

Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails.  So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL.

Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic.  OP_CODEHASHVERIFY is almost as risky as OP_EVAL.

Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey.  I think he is just trying to do whatever he can to cause trouble and confusion.

^ this.

[jimrandomh]

I previously wrote "CODEHASHCHECK is arguably better, but only slightly". After reading Gavin's comment and the linked patch, I take that back. Introducing a non-stack interaction between scriptSig and scriptPubKey is a bad idea and a big deal, much moreso than special-case matching a script is.

[DeathAndTaxes]

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

[piuk]

RE: Why OP_CODEHASHVERIFY is bad:

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

This may have been a problem with my interpretation but scriptSig and scriptPubkey would not actually need to be combined if OP_CODEHASHVERIFY hashed only up to the end of scriptSig (not stack -1 as I worded it)?

[finway]

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

I think luke just made these two options to ignore them.

[jake262144]

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

Now now, DAT, implementing either P2SH or OP_CODEHASHVERIFY will hardly make the system less complex, would you agree?
Other than that, you're right on point.

I never even partook in this discussion because it's over my head as a mere miner.
Unless someone takes the time to study the code and do extensive formal algorithm analysis (we're talking of a huge amount of time here), the intricacies of changing the protocol are far over their head.
The concept of that poll is therefore laughable.

I don't like seeing Luke go crying wolf and turn to the general forum populace⁽¹⁾ for support of his cause.


(1) why else would he post this in Mining instead of Development & Technical Discussion?

[Luke-Jr]

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

Yeah, I basically added those as a control for the poll. Their results tell me the poll is worthless.

(1) why else would he post this in Mining instead of Development & Technical Discussion?

Because it's the miners who are voting and in control of the situation. Yet somehow they're being kept in the dark and forced to vote a specific way...

[DeepBit]

The insane thing is 28% of voters picked the first two options.
Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

Yeah, I basically added those as a control for the poll. Their results tell me the poll is worthless.

I'm sure that many readers don't even realize how this scripting thing is related to phone/hw authentication.

Actually I think that there should be another, better solution for multisig TXes.

[Luke-Jr]

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

No, it doesn't.

Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out.

Much more likely there's a subtle bug in the more complicated BIP 16.

Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails.

That's what I thought, but I didn't see that implemented in the code. In any case, it's not relevant to CHV.

So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL.

It is inconsistent with the other opcodes, but that is required to remain backward compatible: it either makes the script fail entirely, or it functions as a NOP. On the other hand, BIP 16 is inconsistent with the whole script concept.

Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic.

How? The reason OP_EVAL caused controversy was that it wasn't statically analyzable. This does not apply to CHV. I heard nothing of a problem with new opcodes.

Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey.

At the end of scriptSig, the code from the last OP_CODESEPARATOR until the end is stored at the front of the stack. At the beginning of scriptPubKey, it is pulled off the beginning and put in a new variable only used by CHV.

[gnar1ta$]

I am a miner.  I don't understand any of the poll options, and I bet most miners don't. If miners don't understand the technical details (and I don't think the majority do) that leaves the vote to be decided by other merits, like who they like better, or what pool they mine at.  The different codes should be evaluated by people who have the ability to evaluate the code, not people who are stuck evaluating the authors.  Once the codes are evaluated, the pros a cons of each - in plain language - could be sent to miners and users to vote.  This change might be implemented by miners, but it affects all users. Just my 2 bitcents.

[DeathAndTaxes]

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

Now now, DAT, implementing either P2SH or OP_CODEHASHVERIFY will hardly make the system less complex, would you agree?

Well I guess we need to define complex.

A cellphone is incredibly complex.  The protocols that handle authentication, tower handoff, inter-carrier romaing, etc are even more complex however to the end user it is simply.  Pick up phone dial and it works.
Multi-sig adds complexity on the back end but it allows safer more secure systems on the front end.

A wallet which must be signed by both the desktop and android phone is (more) secure.  The user won't care how it works they will just know IT JUST WORKS.
A company (which posts a $100K bond) and offers to insure transactions against double spends is a complex enterprise but to the merchant IT JUST WORKS.

So it allows building robust systems which don't rely on the user having either a masters degree in information technology and network security or just putting blind trust in another company (MyBitcoin) to use effectively.

[DeathAndTaxes]

I am a miner.  I don't understand any of the poll options, and I bet most miners don't. If miners don't understand the technical details (and I don't think the majority do) that leaves the vote to be decided by other merits, like who they like better, or what pool they mine at.  The different codes should be evaluated by people who have the ability to evaluate the code, not people who are stuck evaluating the authors.  Once the codes are evaluated, the pros a cons of each - in plain language - could be sent to miners and users to vote.  This change might be implemented by miners, but it affects all users. Just my 2 bitcents.

The problem is that ultimately for anything to be implemented it will need miners to vote.  They will vote by supporting the protocol with hashing power so miners need to be involved in the discussion.

If no proposal gains support of 51% of miners and at least a significant % of the nodes it will go nowhere.

[jake262144]

Well I guess we need to define complex...

So, we're basically going into higher levels of abstraction, just like with programming languages or frameworks.
That is a definition I can agree with.

What I had in mind when countering your post was:
Let's look at bitcoin protocol as a class.
It is reasonable that simplicity at the high-abstraction (public) level is paid for by greater amount of work and complexity being done at the invisible (private) low-level.
Not only can't low-level bugs usually be fixed (at best, they can be mitigated) at the high client-side level, but also the more complicated the low-level becomes, the harder it is to analyze it for flaws.
Thus, the overall complexity does not change, it's just shifted down.

Naturally, I believe we need multi-sig. I'm also confident the core developers will implement a decent and well-scrutinized approach.


EDIT::Some minor wording issues fixed.

[casascius]

My vote for what it's worth is in support of Gavin.

All technical details aside, gmaxwell has clearly enumerated the goals that such a proposal has been trying to achieve.  Luke has not.  I am not persuaded that Luke-Jr has any of the practical considerations of the needs of a payment network as a priority.

Rather, I see Luke as trying to impose some sort of orthodoxy on the way things work as a prime goal in and of itself - to hell with everything else - just like his vision that the entire world should switch to counting in base 16 with his "tonal" numbers because it's "easier".  Here's another example of an interaction between me and him that left me thinking wtf: https://en.bitcoin.it/wiki/Talk:Wallet_protocol ... Luke is a very talented developer but has totally lost credibility with me as a leader, or qualified to fairly evaluate the different tradeoffs that go into any design decision for a given application.

I will go with whichever flavor of multisig transactions chosen by Gavin and gmaxwell, as I have faith in their abilities to make the right decision for the project.

[casascius]

Bitcoin has come this far without there being an urgent need for multisig. I'm all for it, I just want to make sure it's well tested and done right. I'm not a coder, so I have to trust other coders, and that kind of sucks. Bitcoin has had some good vibrations lately, and I don't want to see anything screw that up.

The only thing driving the urgency is how far malware will go to steal the coins.  Sure, this doesn't need to be done tomorrow, or next week, or next month.  The longer there is no practical multisig, the greater opportunity we'll be giving to malware authors to come up with more sophisticated attacks to steal our coins.  Gavin alluded to it as a cat and mouse game, he is right.  Bitcoin got "this far" and crashed because its security was clearly not far enough along.

I don't thoroughly understand P2SH yet, but one of the key advantages I understand there to be is far less that needs to be tested because it will have far fewer capabilities than OP_EVAL.

[Luke-Jr]

Revised protocol draft, without stack abuse: https://github.com/luke-jr/bitcoin/commit/f026234cf4edc53de4d9e60ccea581adbcb8ee3c

[kjj]

Ok, since none of the options are perfect, how about we try to satisfy everyone with a hybrid solution?

How about we just redefine OP_NOP1 to mean "do nothing right now, but if the rest of this script is valid in the normal sense, then unpack the second script and run it too".  It'll break old clients, and we have to deal with that, but this way we don't have a special case second code path.  Essentially do exactly what P2SH does, but make the recognition explicit with a dedicated opcode, and not implicit.  Make it a flag that can only be set by the OP_P2SH opcode and can't be cleared, maybe even make the new opcode trigger an immediate validation failure if found by the second pass interpreter so that people can't try to sneak recursion in with it.

So, the default P2SH scriptPubKey would become:

Code:

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

[jake262144]

...Bitcoin got "this far" and crashed because its security was clearly not far enough along.

Mike, it's still going to be a cat and mouse game, as all security is.
Of course, raising the bar is always desirable. Common multi-sig deployment will render the old attack vectors ineffective.
However, we can rest assured that the bad guys will bring themselves up to speed and keep mounting increasingly complex attacks.

I do believe, however, that it's not inadequate security that's hampering wide-scale Bitcoin adoption but excessive technical issues with the client:
(1) slow initial block chain download.
(2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter).
(3) lack of wallet security (wallet encryption isn't offered by default, why?).
(4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up).

I'm sad to say these relatively MINOR issues do seem to have a heavy negative impact on the overall impression of the client.

Being active on the Newbies and Support subforums, I hear those issues being raised time and time again by very non-technical users who install the client and expect everything to just work.
They hear about the bitcoin PROTOCOL being secure and confuse that with client-side security (data theft/loss).

I'm writing this here hoping to raise these issues with the core developers.
Very little work put into purely cosmetic issues can make a lot of positive impact.