BIP 16 / 17 in layman's terms

[kjj]

the way i see it BIP17 hashes code rather than execute data, but i guess its semantics

Sigh.  They all hash code and they all execute data.  The hash is used to verify that the data executed was the data intended to be executed.

[1713996769]

1713996769

[1713996769]

1713996769

[Costia]

BIP17:
   scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
   scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP
code is in green data in black. at what point do you execute data?
BIP16:
   scriptSig: [signature] {[pubkey] OP_CHECKSIG}
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

data in bold is being executed
this is semsntics. you can call everything in both sigs "data" and be done with it.

[interlagos]

What about this argument below from Stefan Thomas:

BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits.

While somewhat incidental, I'd like to note that this seems to me to be a very strong, pragmatic argument in favor of BIP 16.

From a theoretical perspective I also feel that BIP 16 is better. If the goal is to store code differently, it is best to handle this before execution by a preprocessor and not via a special opcode that changes execution flow in non-trivial ways. I have a very easy time implementing and feeling comfortable with BIP 16 as it only affects the way scripts are stored/loaded and not how they are executed. There are no new opcodes which can be used in unexpected places or unexpected combinations and there is no change to EvalScript, which is an argument that anyone who has actually tried to implement this function securely has to give a lot of weight to.

Quoted from here:
https://bitcointalk.org/index.php?topic=60433.msg714522#msg714522

[cbeast]

Volunteer organizations all suffer the same affliction. A few people do most of the work, but when it comes to making decisions, people suddenly come out of the woodwork. If someone doesn't make a decision, then nothing gets done. That's why most organizations have elected leaders whose votes tend to count more than others. I think it's great that this is an open voting for miners and pools and I'm not discounting their work, but the real volunteers are the devs themselves. I thing the devs should take an opinion poll about changes, but ultimately they should set the deadline and have the final say. Anyone else can start their own fork and start their own volunteer network.

[Epoch]

Actually I can manually ask many bitcoin developers with good reputation about what vote should I give, but there are 2 problems:
1) They possibly will be all for /P2SH/
2) This won't solve my goal of having better solution

Asking my miners to vote would be "democratic", but sadly they don't know what's the difference, how this will affect Bitcoin and will mostly fall for current FUD on the forum.

There are many interesting and stimulating posts in this thread, and Gavin's OP was very well written; I would have liked to respond to several but I don't want to spam/dilute this thread. So I'll limit my response to this one. First, a disclaimer: I do not mine at Deepbit; I never have. I have nothing against Deepbit or Tycho, it is merely my personal choice.

Tycho, your point is absolutely valid. Asking for a 'vote' of the general mining populous on BIP16/17 is pointless. Yes, it is democratic. But in this case democracy wouldn't be wise. Most people are not in a position to know, or understand, or don't want to understand, or are incapable of understanding, the fundamental differences between the two proposals. Why one is 'better' than the other.

Essentially most of us are sheeple that will vote based on what other sheeple are doing and FUD.

I am not a dev, but I also don't consider myself a sheeple. I am able to realize that my vote is meaningless; I simply don't understand the technical aspects of the bitcoin protocol, nor do I understand the technical ramifications of each of the competing proposals. Perhaps one day I will feel confident enough to voice my (educated) opinion. But that day is not coming up any time soon.

I would think that most miners are in the same boat as me. They, like me, shouldn't be voting. IMHO the only people qualified to vote are the devs. People who truly understand the protocol, how it works, how it can break, how it can be exploited. Only the devs are in a position to truly see the advantages/disadvantages/risks of each of the 2 proposals.

This is why I say that the only people qualified to 'vote' are devs (rather, more accurately, people who have a deep understanding of the existing bitcoin protocol and underlying codebase). I trust that enough of them are unbiased, with no hidden agenda, and are truly motivated by a pure desire to better the bitcoin network. All that is required of them is to be courageous enough, mature enough, to discuss, present, review, and reach concensus amongst themselves.

We are all part of the same network, the same community. We are not competitors here; there are no 'bad guys' and 'good guys'. It is healthy to have different opinions, but it is also important to be able to see when that is being taken too far. If the majority of devs are pushing for one implementation, and a minority are pushing for another, the minority needs to concede and allow development to move forward. Otherwise nothing will get done. And this harms all of us.

[Costia]

the problem is the devs seem to disagree
If they could agree on a solution among themselves - non of this would have happened
Of course at the end they are the ones who have to decide, but they can still ask the public if they want to. and if asked the public is allowed to state his opinion, no matter how stupid it may be.

[Littleshop]

You can not have a proper vote where if you do nothing a vote is counted one way, and do something (hard) the vote is counted the other.  You are going to get a # like 2% out of that. 

A proper vote would be people put in a code if they are against it, and a code if they are for it.  Can you imagine if the only way we passed a law was if we needed YES votes totaling half of the population and made it so that the vast majority of voters would not have the technical skills to vote?

[Costia]

this is actually good - because this is a vote on a technical issue. if you cant apply the patch you shouldn't vote.
the default "i am against the change" is a problem. but the tag was never intended to be used as a voting system. The tag's meaning is that your miner is technically able to use the feature.

[Luke-Jr]

All of the BIP 12/16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together.

Since we're trying to keep this non-technical (I'm not sure that's a good idea, so click the links if you can handle the details!), I'm going to try to come up with a more accurate analogy:

• BIP 12 (OP_EVAL) is inventing a touchscreen for your home security system. You can basically do whatever you want with to authenticate.
• BIP 16 is inventing a camera+touchscreen, but due to patents/closed-source or whatever you can only get it from one security company, and can't use any other security system in combination with it. Everything must be done through the touchscreen.
• BIP 17 (CHV) is inventing a lock mechanism that can be opened by not just the old flat keys, but also by various combinations of any of these old keys or pretty much anything imaginable, without an abstraction layer like the touchscreens.
  

Slush has stated that he supports P2SH and his pool is much more than 2 percent. I'm not quite sure which BIP he prefers, however.

Slush indicated to me that he isn't interested in researching the options, and will just go with whatever Gavin tells him to do.

Luke-jr initiated a rumor that Gavin is hired by some company going to produce hardware/software solution for 2-factor authentication and this is the reason he is pushing so hard.

This was mere speculation in private, IIRC when asked why Gavin is rushing things. I have no evidence, and haven't even looked at TruCoin's website to see if this might possibly be the case.

I just believe it's unhealthy for a few individuals (including you) to hold too much power over the development of Bitcoin.

This applies to Gavin as well. "I'll just go with what Gavin says" is a bigger problem than "I'm mining on Deepbit" right now: DeepBit at least cut down on advertising due to concerns of the centralization, but Gavin seems to be encouraging the "just trust me" attitude.

CHV (BIP17) also executes data, as does OP_EVAL (BIP12).  The debate is over how to execute the data, not whether to execute it.

No, BIP17/CHV does not execute data from the stack as BIP 12 and 16 do.

this is actually good - because this is a vote on a technical issue. if you cant apply the patch you shouldn't vote.

One problem IMO, is that Gavin has merged BIP 16 into git master, and set it up to force everyone using it to vote for it. To not vote you have to patch your client. I submitted a fix to make this optional 2 weeks ago and while he did say he'd accept it with a minor change a week ago (which I made immediately), it still isn't merged.


For the record, I agree with the many people who think we should give this more time. However, my interest is only in avoiding the deep protocol change that BIP 16 makes, so I am fine with compromising on getting BIP 17 deployed sooner.

Also note that while BIP 16 might arguably be slightly simpler/deterministic in the specific implementation used in Bitcoin-Qt, BIP 17 is almost certainly generally simpler to implement, and in practice much simpler in terms of backports to bugfix-only bitcoind and Bitcoin-Qt clients.

[chrisrico]

(accidentally posted this in the other thread)

Steve, don't both BIP16 and BIP17 satisfy your complaint that the scriptPubKey should not contain the rules for redeeming a transaction, only the script hash to be validated upon redemption?

Current:
scriptPubKey

Code:

OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

scriptSig

Code:

<sig> <pubKey>

BIP16:
scriptPubKey

Code:

OP_HASH160 <hash> OP_EQUAL

scriptSig

Code:

OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)

BIP17:
scriptPubKey

Code:

<hash> OP_CODEHASHVERIFY OP_POP

scriptSig

Code:

OP_0 <signature> OP_CODESEPARATOR 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG

So does the BIP16/BIP17 argument come down to whether the validation script should be encoded so that a new opcode is not necessary, or to introduce a new opcode so that encoding is not necessary?

[Technomage]

This applies to Gavin as well. "I'll just go with what Gavin says" is a bigger problem than "I'm mining on Deepbit" right now: DeepBit at least cut down on advertising due to concerns of the centralization, but Gavin seems to be encouraging the "just trust me" attitude.

I agree that asking which BIP to enable from the miners is stupid, a very large majority of them don't have a clue. But my point in all of this has been that most pool operators do not have a clue either which means that it's good to raise the awareness of all miners over this issue.

As far as the "just trust Gavin" issue is concerned, I for one don't think about it that way. This is exactly the reason why I want more transparency from the dev team. The dev team should be the one handling this. Vote amongst yourselves and come up with a compromise. A small minority must compromise if we want to make Bitcoin more than it is now.

So in conclusion I will list these following scenarios and if it's a problem:

A) Gavin says do what I say even though a good number of devs are against it and people still trust Gavin -> this is a problem
B) Gavin says do what I say and a large majority of devs agree with him -> this isn't a problem unless the minority is too stubborn to compromise

Based on what I've read in the forums, we are clearly at scenario B. Not a problem unless minority refuses to compromise. Clearly there is no compromise, yet. Whatever the scenario is, we need more transparency. Developers need to suck it up now, eat their pride and start coming up with answers among themselves.

[Steve]

CHV (BIP17) also executes data, as does OP_EVAL (BIP12).  The debate is over how to execute the data, not whether to execute it.

No, BIP17/CHV does not execute data from the stack as BIP 12 and 16 do.

I think we might be overstating the significance of this.  I agree (as I've stated) that pushing stuff on the stack and executing it is not ideal.  Neither is having special transactions with special rules that apply to them.

However at the end of the day this is a tactical step.  I think there is a growing awareness that P2SH in general is the way all transactions should work.  Neither BIP-16 or BIP-17 are a perfectly clean solution when viewed in that light.  I think the ultimate deciding factor should be what's best from an upgrade perspective and from a safety perspective.  As I understand it, there aren't a lot of tests around the scripting engine.  I'm not at all familiar with the implementation of the scripting system.  If there is something about BIP-17 that requires it to execute largely unproven code paths, that may be the deciding factor in favor of BIP-16.

As for the urgency, the danger I see is that an alt-coin implements this instead of bitcoin.  If bitcoin takes too long to add these capabilities, then an alt-coin could do it and then everyone would eventually move to that alt-coin.  I don't think we need to rush, but at the same time, we should take this opportunity while it's at the forefront of a lot of people's minds to make a decision and move forward with it.

My advice to the devs is to do the safer thing recognizing that the scripting system doesn't have a very good safety harness in the form of being well understood by a lot of people or in the form of a large amount of unit tests.  I've met Gavin in person and my opinion is that bitcoin is lucky to have him (both for his technical skills and for his approach to leading a project like this).  When he voices concerns that we need to be very careful about going down certain code paths…that they aren't well tested or well understood, I think we have to take that seriously.  I can't see anything about BIP-16 that is any kind of threat to the future of bitcoin.  Nor does it preclude a day when we could move to a more robust and simpler scripting system.

[Costia]

technomage
this majority/minority of devs makes no sense for this issue
If even 1 of 10 devs thinks a certain solution is insecure/bad for the system - it should not be implemented
This is not deciding what color shoes you should buy. this decision will have implications on the future
you must learn the technical side of both arguments to understand what it is all about.
btw, I think both solutions are not good enough. And no i dont have a better idea.
but if i had to choose now i would go with bip17 - due to elegancy

[Technomage]

But the thing is BIP16 is not insecure or bad. We're talking apples and oranges here and I've come to the conclusion that there is really nothing stopping us from implementing BIP16 except the stubborness of Luke-Jr. Pretty much all the other devs agree that it's a good solution. BIP17 isn't bad either but I don't think the support for that is as good as it is for BIP16.

This is the only viewpoint I can have on this because the technical details are not something I understand. But I think it's valuable because it seems that the answer to this problem is not going to come from the technicalities, that discussion has been in the apples and oranges stage for a while now.

[Costia]

i think both implementations have their problems and this is why gav opposed to bip17 and luke opposes bip16...
So why not listen to both of them?

[rjk]

this majority/minority of devs makes no sense for this issue
If even 1 of 10 devs thinks a certain solution is insecure/bad for the system - it should not be implemented

Why must it be unanimous? One vocal minority really shouldn't be bringing things crashing down like this.

Insecure is a completely different argument than bad for the system, so I would appreciate it if you kept those separate.

If we are so worried about the size of the blockchain, it appears to me that BIP_17 is not the way to go because of increased amounts of data being stored in the chain.

As for the "dear leader" complex that has been alluded to in this thread, I think that is a fallacy - most of us have seen for ourselves the capability and openness with which the current project leader has had and has conducted himself with, and for that reason only, there is support.

[Inaba]

The main problem is that it's an irrevocable change to the block chain if something goes poorly.

[chrisrico]

The main problem is that it's an irrevocable change to the block chain if something goes poorly.

I think this is going to be an issue with any implementation allowing payment to a script hash, and I agree with others that this is the correct way to go moving forward.

[Costia]

The main problem is that it's an irrevocable change to the block chain if something goes poorly.

as far as i can see it is true for both BIPs

[kjj]

BIP17:
   scriptSig: [signatures...] OP_CODESEPARATOR 2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG
   scriptPubKey: [20-byte-hash of {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG} ] OP_CHECKHASHVERIFY OP_DROP
code is in green data in black. at what point do you execute data?
BIP16:
   scriptSig: [signature] {[pubkey] OP_CHECKSIG}
   scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

data in bold is being executed
this is semsntics. you can call everything in both sigs "data" and be done with it.

In the current setup, scriptPubKey is the code, and scriptSig is the data.  If BIP17 isn't executing code by virtue of reclassifying scriptSig into "code", then none of the others are either.

In my view, the script in the transaction output is "code", and whatever is needed to redeem it is "data".  By that definition, all three are executing data.  If you prefer to think of things that are executed as code wherever they may be, then none of them execute data, but that is pretty silly, since it would reduce your credo against executing code into "be careful that you don't execute things that you don't execute".