Topic: BIP 16 / 17 in layman's terms - page 12. (Read 38982 times)

BIP 17 transactions use less data than BIP 16.

Except scriptSig is not and has never been mere data, it is code.

look at how Gavin himself wrote it in his post:
https://bitcointalksearch.org/topic/bip-17-60433

OP_HASH160 OP_EQUAL
OP_0 OP_PUSHDATA(2 2 OP_CHECKMULTISIG)

the code is "OP_PUSHDATA"
"2 2 OP_CHECKMULTISIG" is data
then, this previously pushed data gets executed

while in BIP17:
OP_CODEHASHVERIFY OP_POP
OP_0 OP_CODESEPARATOR 2 2 OP_CHECKMULTISIG
no tricks are used...

my problem with the idea of executing data is that it is the basis of a lot of hacks in other software

Watching.

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

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

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.

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

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.

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?

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.

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

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.

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.

(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
scriptSig

BIP16:
scriptPubKey
scriptSig

BIP17:
scriptPubKey
scriptSig

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?

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 indicated to me that he isn't interested in researching the options, and will just go with whatever Gavin tells him to do.

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.

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.

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

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.

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.

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?

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.

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.

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.