BIP 16 / 17 in layman's terms - page 13.

interlagos

hero member

Activity: 496

Merit: 500

What about this argument below from Stefan Thomas:

Quote from: Stefan Thomas on January 26, 2012, 10:46:48 AM

Quote from: Gavin Andresen on January 20, 2012, 11:53:31 AM

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://bitcointalksearch.org/topic/m.714522

Costia

newbie

Activity: 28

Merit: 0

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.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Costia on January 26, 2012, 11:08:16 AM

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.

Costia

newbie

Activity: 28

Merit: 0

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

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Costia on January 26, 2012, 10:24:50 AM

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

newbie

Activity: 28

Merit: 0

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

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: kjj on January 26, 2012, 10:13:32 AM

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.

kjj

legendary

Activity: 1302

Merit: 1026

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]

hero member

Activity: 742

Merit: 500

Quote from: Steve on January 26, 2012, 10:00:52 AM

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

Steve

hero member

Activity: 868

Merit: 1008

Quote from: ?? on ??

Quote

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.

Steve

hero member

Activity: 868

Merit: 1008

Quote from: [Tycho] on January 26, 2012, 09:45:54 AM

Quote from: Technomage on January 26, 2012, 09:42:59 AM

Quote from: [Tycho] on January 26, 2012, 09:41:06 AM

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.

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: Technomage on January 26, 2012, 09:42:59 AM

Quote from: [Tycho] on January 26, 2012, 09:41:06 AM

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.

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: Gavin Andresen on January 26, 2012, 09:37:56 AM

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.

Technomage

legendary

Activity: 2184

Merit: 1056

Affordable Physical Bitcoins - Denarium.com

Quote from: [Tycho] on January 26, 2012, 09:41:06 AM

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]

hero member

Activity: 742

Merit: 500

Quote from: Technomage on January 26, 2012, 09:39:36 AM

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

legendary

Activity: 2184

Merit: 1056

Affordable Physical Bitcoins - Denarium.com

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

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:

Quote

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

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Technomage on January 26, 2012, 08:38:13 AM

Quote from: [Tycho] on January 26, 2012, 08:25:02 AM

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.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Gavin Andresen on January 26, 2012, 09:17:28 AM

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.

CombustibleLemon

newbie

Activity: 34

Merit: 0

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.

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