BIP 16 / 17 in layman's terms

[Steve]

If you ask me, bitcoin could be mass adopted in a year globally, but we would have a dumb'ed down version that only makes p2sh transactions, no way to change it and no way to generate an original address, that way we would pay forced heavy taxes to Governments.
Perfect central control without people able to protest with a policed world government. How would you push those small changes ? Having on your side their "leader" ? And if Bitcoin doesn't have a leader ? Nah, the people are too stupid to think for themselves they always have a one, real anarchy is a myth.

I just want to point out (before people get into a conspiracy panic) that this doesn't make any technical sense.  The address of a traditional, single signature transaction, is a cryptographic hash of the public key that is used for signature verification in the spend transaction.  The address of a single signature transaction implemented with P2SH would be a cryptographic hash of the public key + an opcode (OP_CHECKSIG or OP_CHECKSIGVERIFY).  The notion that you couldn't create a crippled bitcoin client incapable of generating original addresses is nonsense…governments would have to ban general purpose computers (hell, they'd probably have to ban handheld calculators).

[alan2here]

0011 is being used?

[Gavin Andresen]

As I've been asking in other threads, but have yet to get an answer, I will ask here again.  Why is this such a rush?  Why the secretive "upgrade?"  What is wrong with this proposal that it requires it to be force pushed through at such a rapid pace?

This needs to be weighed and measured and the potential consequences thought out.  Why is this not being done?

I believe that without a deadline nothing would get done.

We could talk and argue and discuss for six months trying to find the perfect solution, and there would still be people saying that we need another six months to argue and discuss some more.

In fact, us developers HAVE been discussing and arguing about this for over six months now; this whole thing started with an impromptu brainstorming session at the first Bitcoin Conference in New York.

As for this upgrade being "secretive" : huh? It certainly isn't/wasn't a secret among the developers, and until the developers came to rough consensus (and I believe there IS rough consensus, despite what Luke claims) I didn't think non-developers would be interested in the technical details.

From some of the reactions in this thread, I think I was right-- most people don't care whether we use nails or screws or glue to build a better wallet.

RE: rumors that I'm doing this for some personal reason:  100% untrue. I want a solution because it will make Bitcoin better sooner.

[CombustibleLemon]

I am looking at the distribution of hashing power controlled by the various pools right now.  Deepbit only has 35% of the network.  Maybe people finally changed over.


Tycho's opinion on the matter is good just as a general thing, but at these levels I don't think he can force a change if he disagrees.

[slush]

I believe that without a deadline nothing would get done.

+1 Actually the discussion is here for long time, but only the near deadline pressed people to talk about it more intensively.

[kjj]

He is for BIP16.
And I don't know how he is going to mine enough voting blocks before 1 Feb.

I think the deadlines are right now the biggest problem and many seem to agree with that. This has a very low chance of working out with these deadlines I believe, but there can always be a new vote.

Well, it isn't really a deadline.  More like a target.  And since we are already into the 7 day window and support has been underwhelming, I think it safe to say that the target will be missed.  So the debate will rage on while support starts creeping in.

I totally sympathize with Gavin though.  I've spent a lot of time on various committees, so I've seen firsthand that no group ever takes a task seriously until the last minute.

[Gavin Andresen]

I want to try to clear up two misconceptions:

1. The original implementation of OP_EVAL was not "exploitable", but it did have bugs.  

2. The Feb. 1 deadline was explicitly designed to be a "soft" deadline; here is what BIP 16 says about it:

To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.

On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.

If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).

[Technomage]

To me the biggest deciding factor here is what is the general opinion of the devs? Make a dev vote damn it, if at least 90% of devs agree on a BIP, tell us, the regular folk about it. I would gladly mine on a pool that supports that particular BIP if large majority of the devs are behind it.

It's not enough that Gavin claims that there is a "rough concensus" on something, we need more transparency. Most of the people who will vote for this thing, the miners, do not know about the inside discussions devs have nor do they have any idea of the actual differences in each BIP.

[[Tycho]]

To me the biggest deciding factor here is what is the general opinion of the devs? Make a dev vote damn it, if at least 90% of devs agree on a BIP, tell us, the regular folk about it. I would gladly mine on a pool that supports that particular BIP if large majority of the devs are behind it.

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

[Technomage]

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

And what about BIP17? I did get the idea that Gavin didn't like it, but what about other devs? If more devs like BIP16 than BIP17, then in my book we can rule out BIP17.

Also if it's true that BIP16 really had a large support and luke was simply loud about his disagreements, I would be willing to vote on P2SH via BIP16.

[[Tycho]]

I want to try to clear up two misconceptions:
1. The original implementation of OP_EVAL was not "exploitable", but it did have bugs.

As I understand, there was a possible way to make pool's blocks invalid/orphaned, which can be an attack against the pool if this pool's rules state paying miners for invalid blocks.

[[Tycho]]

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

And what about BIP17? I did get the idea that Gavin didn't like it, but what about other devs? If more devs like BIP16 than BIP17, then in my book we can rule out BIP17.

BIP17 is less "compatible" with old clients and under some circumstances can allow redeeming other people's TXes if the network suddenly stops supporting BIP17.

But both BIP16 and BIP17 are incompatible with old clients to the enough level so we can't say that one is "significantly more" compatible anyway.

[Steve]

I think that the only dev against BIP16 is luke-jr, who is offering BIP17 instead.

And what about BIP17? I did get the idea that Gavin didn't like it, but what about other devs? If more devs like BIP16 than BIP17, then in my book we can rule out BIP17.

BIP17 is less "compatible" with old clients and under some circumstances can allow redeeming other people's TXes if the network suddenly stops supporting BIP17.

But both BIP16 and BIP17 are incompatible with old clients to the enough level so we can't say that one is "significantly more" compatible anyway.

This might be an irrational fear though.  As a merchant and as an individual, you are going to want to accept only the transactions that are the most broadly marketable.  If there is even a subset of the population that enforces stricter rules about transaction acceptance (as is the case with both BIP16 and BIP17), it is in your best interest to adhere to that stricter set of rules.

Here's another interesting prospect…let's say both BIP16 and BIP17 were implemented in two different forks of the bitcoin client.  Since they are both somewhat backward compatible (which means that the old validation rules will allow these transactions to pass if seen in a block), both styles of transaction could be supported by the network as a whole.  As a person interested in seeing that all coins I receive are as broadly marketable as possible, I would want to have very strict enforcement of both BIP16 and BIP17 transactions.  There would then be demand for a client that could enforce both BIP16 (supports the funky, special case execution of code pushed on the stack) and BIP17 (supports OP_CHECKHASHVERIFY).  I'm not advocating this mind you.  I've stated my preference for the approach in BIP17.

[Steve]

I think that the only dev against BIP16 is luke-jr

and this is sad, to see that the whole exercise is due to a single member.

No, Luke-Jr raised valid issues and that's a good thing.  However, he did it in a manner that pissed people off.  I only hope people can set that aside and evaluate his proposal on its merits and not discard it due to the manner in which he raised the topic.  I am very strongly of the opinion that BIP-17 is technically superior.  I only wish at this point I had more credibility to make this argument by having spent more time working on the core client.

[[Tycho]]

Here's another interesting prospect…let's say both BIP16 and BIP17 were implemented in two different forks of the bitcoin client.  Since they are both somewhat backward compatible (which means that the old validation rules will allow these transactions to pass if seen in a block), both styles of transaction could be supported by the network as a whole.

Possibly won't work this way. With "old validation rules" 1) both BIP16 and BIP17 will be "non-standard", but mined by supporting pools (unless stopped by not relaying to to way to miner), 2) more importantly, if someone is mining by old rules, then under some circumstances he can create a TX, redeeming any BIP17 TX, that belongs to someone else, causing evil blockchain forking (depends on hashing power of both branches).

[kjj]

Hey Tycho, as long as you are here, I see that one of your objections to BIP16 is the magic transaction pattern.  Would you be more comfortable if there was an opcode that triggered the BIP16 mechanism?

I've seen that same objection from a few people, and I have to admit that I have quite a bit of sympathy for that view.

I suggested that we reuse one of the OP_NOPx opcodes as OP_P2SH.  It would remain very much like a NOP in that it did nothing direct, but it set a flag in the interpreter to tell it to invoke the P2SH mechanism if the rest of the script was valid.  Gavin wasn't a big fan, but I think he saw it as pointless rather than harmful.  If the target date slips by without support (and it looks like it will), then it might become more useful.

[[Tycho]]

Hey Tycho, as long as you are here, I see that one of your objections to BIP16 is the magic transaction pattern.  Would you be more comfortable if there was an opcode that triggered the BIP16 mechanism?

Yes, I would be.

Also, you should note that I'll vote for /P2SH/ if considerable part of other miners will. It's not like I'm completely against it.
My position is rather "Vote for doing it in a better way unless impossible" and not triggering the avalanche by voting myself first.

[Costia]

my opinion is similar to steve's
BIP16 does look like something that can cause trouble down the road
1) the way i understood it, BIP16 pushes something on the stack as data and the executes it. Executing data is something i was taught to avoid at any cost
2) BIP17 looks like a more elegant solution that better fits the script's design.

but i am still concerened about possible security issues BIP17 might bring right now..
maybe the solution is wait till somebody has a better idea

[kjj]

my opinion is similar to steve's
BIP16 does look like something that can cause trouble down the road
1) the way i understood it, BIP16 pushes something on the stack as data and the executes it. Executing data is something i was taught to avoid at any cost
2) BIP17 looks like a more elegant solution that better fits the script's design.

but i am still concerened about possible security issues BIP17 might bring right now..
maybe the solution is wait till somebody has a better idea

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

[Costia]

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