Topic: Old P2SH debate thread - page 6. (Read 19705 times)

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.

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.

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.

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.

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.

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.

No, it doesn't.

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

That's what I thought, but I didn't see that implemented in the code. In any case, it's not relevant to CHV.
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.

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.

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.

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.

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

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

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?

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

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)?

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

^ this.

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

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