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

i'm not a bitcoin dev, but i was already involved in many projects. from what i read here, i think the best way is to go with the proposal that has been tested at most so far, and most of the devs have studied the actual implementation. the reason is that in that case most of the current devs know about how it works, what its implications are and about the possible pitfalls. also, even if another proposal is better on paper and in theory, what actually counts is a very good, well tested implementation, it needs to be implemented near perfectly from the start! in that light, a superior theoretical approach, only checked by a few, will be much worse.

and yes, this means it could go something wrong, but that won't kill the internet and it won't kill the blockchain. a new client version will fix that -- and that's only the unlikely worst case scenario.

I'll start working on it when I'll see significant support from other miners. (2% is not significant)
BTW, according to Gavin's e-mail today, Deepbit is 28%, not 40%.

I'm saying that BIP17 has no chances not because of me, but because I seriously doubt that it will be supported by anyone besides Eligius.

I agree 100%


What are you referring to here?  BIP 16 (or 17, or 12, etc..) have no benefit to pools and everything to do with miners.

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?

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

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.

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.

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. 


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.

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

No, the BIP makes it sound like a vote.


Rightly or wrongly, that is the root cause.

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

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

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.

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.

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

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.

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

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.

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
also look at the examples there

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.