BIP 16 / 17 in layman's terms

[westkybitcoins]

Watching.

[Costia]

look at how Gavin himself wrote it in his post:
https://bitcointalk.org/index.php?topic=60433.0

OP_HASH160 <hash> OP_EQUAL
OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)

the code is "OP_PUSHDATA"
"2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG" is data
then, this previously pushed data gets executed

while in BIP17:
<hash> OP_CODEHASHVERIFY OP_POP
OP_0 <signature> OP_CODESEPARATOR 2 <pubkey1> <pubkey2> 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

[Luke-Jr]

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.

BIP 17 transactions use less data than BIP 16.

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.

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

[kjj]

look at how Gavin himself wrote it in his post:
https://bitcointalk.org/index.php?topic=60433.0

OP_HASH160 <hash> OP_EQUAL
OP_0 <signature> OP_PUSHDATA(2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG)

the code is "OP_PUSHDATA"
"2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG" is data
then, this previously pushed data gets executed

while in BIP17:
<hash> OP_CODEHASHVERIFY OP_POP
OP_0 <signature> OP_CODESEPARATOR 2 <pubkey1> <pubkey2> 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

So, your objection is to OP_PUSHDATA?  I only bring it up because BIP17 does that implicitly.  It bangs both parts together and executes them as one.  Go dig for Gavin's objections to BIP17 where he explains that bitcoin used to work this way, and why it does not today.

[Costia]

AFAIK bitcoin still does exactly that.
puts the signatures together and executes the result
both signatures contain both data and code
my objection is not to push data, but that this data is being executed at a later stage

https://en.bitcoin.it/wiki/Transaction

The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig

also look at the examples there

[evoorhees]

I don't understand the technical details here... at all... but I find it fascinating to read these kinds of conversations. This stuff is so damn cool.

I'm confident from fiery debate, reason will emerge. As an onlooker, I'm continually impressed and bewildered by the brilliance, creativity, and passion of those developing the core of this new world.

Cheers to you guys.

[Inaba]

"average" miners, for all practical purposes, can't vote anyway... A solo miner isn't generating blocks fast enough to make a difference... so even if every miner popped up with a vote for P2SH, it wouldn't really change anything.  

The "vote" comes packaged in a solved block.

[paraipan]

Also, Gavin's signature says "Send Tycho a PM or email and ask him to support P2SH for a more secure Bitcoin" like I'm currently against "more secure Bitcoin".
But I'm not.

The fact that you've let your pool grow to the size it has suggests a different story to me. There are many reasons no pool should be that large, yet you seem happy to let it happen, even bragging about it occasionally (if you are also the forum user "deepbit"). I don't think you necessarily want that much power, you just earn more because of it.

For example, https://deepbit.net with over 3100 GH/s of hashrate

and your point is, Holliday ? this is a free market you know, grasp the concept

back on topic, I know this can be very frustrating for you Gavin but you will manage to reach consensus, i'm sure about that.

[Costia]

"average" miners, for all practical purposes, can't vote anyway... A solo miner isn't generating blocks fast enough to make a difference... so even if every miner popped up with a vote for P2SH, it wouldn't really change anything.  

The "vote" comes packaged in a solved block.

The regular pools should have at least made a poll on their site. so its not the manager who decides, but the miners of that pool

[rjk]

I am not sure why [Tycho] is being bashed for being completely agnostic! Sure it is a large amount of hash power, but instead of forcing his users to "vote" by modifying his blocks, he is instead doing nothing. I don't see how this warrants significant hate, because I am sure that voting one way or the other would just mean that many more people crying foul because it isn't they want they want it to be.

[Tycho]'s previous mentions of selling shovels to the miners have piqued my ongoing curiosity, and I can't wait for the next big thing to come along.

[Rassah]

Anyone else find it strange that Gavin would put this up to a vote with maybe two weeks notice, where no vote is the same as a "no" vote? With apparently most miners not even knowing how to vote? And the excuse that "if you don't know how to modify your client, you shouldn't be voting anyway" just resulting in an inevitable conclusion of almost no votes for it at all?
Two proposals:
1) Scrap the deadline, put up instructions on how to four for BIP16, BIP17, or neither, in a simple to understand way (precompiled bitcoind exe's preconfigured for specific votes maybe?), and just let the voting continue. Eventually once more than 55% of the miners are voting for either BIP16 or BIP17, implement the winner. With enough time it will happen.
2) If miners, despite securing the network and being the gate keepers to any changes, "don't understand the code anyway, and shouldn't be voting," which I sort of agree with, since I don't understand this completely, and don't think these important decisions should be turned into a popularity contest (disclosure: I like Gavin, I really don't like Luke, but what kind of people they are should have no bearing on their coding skills, of which I am not well enough informed), then don't vote. Gavin can push out his client, Luke can push out his. People will vote with downloads, and the stubborn ones will have to switch eventually. It will be forky and messy, and people may lose mining revenue, but Bitcoin will survive, especially in at this still early stage. It will also be a good test of how well Bitcoin will handle necessary radical changes, and we all know those will have to come eventually.

[Inaba]

Rassah, that doesn't really address the problem.  99.9% of miners will not get to vote, regardless of what they change their clients to.  All "votes" are packaged within a solved block, thus you must solve a block to "cast" a "vote".

[Costia]

this was not intended to be a vote...
people started interpreting it as a vote when luke came up with BIP17

I think i had enough of this. Let gavin and luke fight to the death. the winner writes the P2SH implementation

[Inaba]

No, the BIP makes it sound like a vote.

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.

Rightly or wrongly, that is the root cause.

[Costia]

No, the BIP makes it sound like a vote.

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.

Rightly or wrongly, that is the root cause.

supports here is "technically supports" as in "able to accept and process such transactions". not support like in politics

Edit: the concern was that most people wont update, because even now more than half of the clients are below version 0.5

[Inaba]

supports here is "technically supports" as in "able to accept and process such transactions". not support like in politics

I disagree... but we've already covered that in another thread.  If, in fact, it is to show technical support, then the BIP is wrong.  In either case, it is immaterial to this discussion. 

people started interpreting it as a vote when luke came up with BIP17

Is a false statement was my point.  People started interpreting it as a vote because of the BIP.  Perhaps the argument could be made that Luke increased awareness, and that I would agree with.

[[Tycho]]

1) Scrap the deadline, put up instructions on how to four for BIP16, BIP17, or neither, in a simple to understand way (precompiled bitcoind exe's preconfigured for specific votes maybe?), and just let the voting continue. Eventually once more than 55% of the miners are voting for either BIP16 or BIP17, implement the winner. With enough time it will happen.

Doesn't works this way. "Voting" means that this mining system already supports given method, but it will be enabled only after specified date.
If you want to vote for one version, but in case of other one winning switch to the other, you need to implement BOTH with a some kind of switch. And this switch should never br triggered after the end of this voting. Adds complexity and poosibly error-prone.

[LightRider]

There can't be a democracy if the vast majority of those with voting power are ignorant on what they're voting for.

I find it interesting that major changes were implemented to the client/protocol that helped pools before we started considering changes that would help the common bitcoin user. That is probably something that is endemic of our society. Helping the big interests in a society first makes it more difficult to implement changes for the betterment of all stakeholders.

[[Tycho]]

I would like to point that BIP17 has no chances of winning.
The question is WHEN bip16 will be over 55% and starts working.

[Costia]

I would like to point that BIP17 has no chances of winning.
The question is WHEN bip16 will be over 55% and starts working.

well if you say so....
Thats already 40% of the hashing power.
What exactly are you waiting for before you enable the support in your pool?