Topic: How to vote for/against p2sh? (Read 3462 times)

/OT/ *check mail box* 6480 unread out of 17331 in my inbox, really. You should also learn how to use filtering, lol ;-).

*check mail box* 945 unread out of 3672 in my Inbox...

Yeah, that probably not gonna work out too well for me

Maybe you should subscribe to bitcoin dev mailing list?

Already saw that link a long time ago (as far as this conversation goes) and it is irrelevent.  Like I said several times already, if that is the interpretation then the BIP is wrong.  Lobby to get it changed if it makes you that upset.  

As far as EMC goes, it is disabled because there is no guarantee EMC will support it at any given time, nor does EMC support it on all the getwork servers at the current time.  So you somehow think I should advertise that EMC supports it, when the support is a) incomplete and b) not guaranteed to b supporting it tomorrow, next week or next month?

Yep, it's official.  You know absolutely nothing about software development or running a business.


Nope, I wasn't aware of that.  Just one more example of why this whole fiasco is a cluster fuck of epic proportions.

Inaba, do you know that Gavin did also p2sh patch for 0.3.24? I'm using it without any issues. It is just FYI, I don't want to join the flamewar :-).

Gavin Andresen, the author of BIP 16, supports my interpretation here:
EclipseMC makes the same error the other way around.  Support the feature without announcing it in the coinbase like the BIP says.

dunno, i read the posts two times just to make sure i understood correctly

Huh? Looks the other way around to me.

don't feed it Inaba, you got point 

Now you are nit-picking.  A BIP is design document containing a concise technical specification.  The technical specification of the new transaction type (named pay-to-script-hash in chapter 2) is in chapter 3 and often referred to in the rest of the BIP.  E.g. in more than 50% of miners must support full validation of the new transaction type and later when it is described how miners should announce their support for the new transaction type, and how support can be counted to verify that more than 50% of the hashing power support the new validation rules.  The reason why it is important to correctly count blocks mined by miners validating by the new rules is explained in the BIP as well: To gracefully upgrade and ensure no long-lasting block-chain split occurs [...]

So which is it?  Is it a technical specification or is it a design document that contains a technical specification?  How can a technical specification contain a technical specification? Why would you be redundant like that, if you somehow managed to nest these?  Is this some sort of esoteric Matryoshka doll on paper I am not aware of?

I have presented all my arguments.  Just read my posts again to make sure nothing slipped.  I have nothing to add beyond that.  I agree that support applies to BIP 16, which is a technical specification of how P2SH transactions may work.  See BIP 1: A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.  Mining software (transaction validation is usually implemented in software) can support the technical specification in this BIP.  There is no special mention of bitcoind or other software.  Just the simple fact that the software must be upgraded to support this BIP.  We obviously don't agree to what software support of a technical specification (e.g. a BIP) means.

I think the BIP become pointless with your definition of to "support" a technical specification.  Testing conditions like "To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time." becomes impossible in the way described in the BIP if "/P2SH/" is reduced to a statement of opinion.  We can just agree to disagree on this, and perhaps have a popular vote here in this thread. :-)

Like I said, unless you can bring something to the table of substance, this debate is over.  Support in this context is applied to the BIP, no matter how you want to erroneously define the definition of "support" to fit your failed chain of logic. Support, however defined, still applies TO THE BIP, not to bitcoind, the protocol, etc...  Therefore my statement stands and your argument is still invalid.

Again, your post is meaningless and you are wrong.  If you think the BIP is wrong, take it up with whoever maintains it, if you disagree with me, provide anything to support your argument.  In the absence of either of those, there is nothing more to discuss.  

The word support can have a lot of different meanings depending on context.  When an army patrol under attack calls for air support, they clearly don't mean the air around them should support their views, share their opinions or vote for them.  A beam can support a roof.  The beam does not have an opinion of it's own.  The roof is supported by the beam from falling down, not voted by the beam to stay up.  A man leaning on a wall for support does not depend on the opinion of the wall.  He depends on the wall to stay put and keep him from falling down.  There is also economic support, supporting actors or instruments, etc.  My version of LibreOffice supports ODF version 1.2.  It does not support the database format used in the standard Bitcoin client.  Support can mean sharing a political opinion, but I already explained why that interpretation contradicts the purpose of /P2SH/ as described in BIP 16.

Hashing power is not a person, and do not have an opinion of it's own.  It can however support the technical specification much in the same way as a beam support a roof or LibreOffice support ODF 1.2.

I think your interpretation contradicts the context, and I can only conclude that our understanding of the word support in this context differs.  (This is an opinion which can be supported and voted over, not a technical specification which can be supported by software or hardware. :-)

It does not "clearly mean" any such thing.  In fact, it clearly states exactly the opposite.  You even requoted it in direct contradiction to what you just wrote:

To judge whether or not more than 50% of hashing power supports this BIP.

It says absolutely nothing about technical support.  It clearly and exclusively states "supports this BIP."  This is not in question.  The fact that you are trying to make it say something else is duplicitous and just plain false.


Whether or not it would be bad is not the issue or the debate.  The BIP clearly indicates, under ANY POSSIBLE LOGICAL INTERPRETATION that /P2SH/ indicates support for the BIP and NOTHING else.  You can try to shoe horn in any interpretation you like, but just reading the BIP it clearly defines what is what and your interpretation is wrong.


And here is really the root of the problem and the nonsensical debate with you that I am engaged in.  You want it so badly to say what you are interpreting it as, you refuse to acknowledge what is actually written.  The BIP is pretty clear.  I have outlined the relevant portions, you have failed to show anywhere in the BIP where it contradicts any single part of my position, so this debate is effectively over unless you have something meaningful to add.  Your interpretation is wrong, plain and simple. You are wrong, plain and simple.  

If you want to take the position that the BIP is wrong, I'm good with that and I will possibly even agree with you.  But as written,  I am conforming to the proposal (because, after all, a BIP is a proposal, not a technical specification.  It may be a proposal for a specification, but it is NOT a ratified specification, otherwise it would not be a proposal.).  If you want to lobby for the BIP to be changed, I will evaluate the changes as required.  As such, I do NOT support BIP 16 as written given the time constraints involved, therefore generated blocks will NOT contain /P2SH/ as required by the BIP to indicate support.

Miners ARE NOT REQUIRED to upgrade their clients on any timetable, even years after BIP 16 goes into effect. Old clients that were not modified to accept non-standard transactions are able to continue mining without consequence. The ONLY way old miners could be hurt is if a malicious miner creates a block that contains an invalid P2SH transaction that your client then attempts to build off of. Even THEN, your miner has to find a block before the rest of the network invalidates that block, which would be unlikely even for large pools.

There is no rush to upgrade. If we underestimated how much time it would take for over 50% the network's hash power to upgrade, oh well. That's our bad. We'll wait. Just don't lie about whether or not your clients are able to fully validate P2SH transactions.

The keyword here is support.  This clearly means technical support of the specification above, and has nothing to do with anyones opinion of the specification.  The purpose is to count miners which has implemented support for the specification, not miners who think that the specification should be supported (political support).

It would be very bad if miners put /P2SH/ in their coinbase to state their opinion without actually supporting the specification!  This may actually be a problem with the specification.  If more people understand support as political support, the change can be based on false assumption of technical support for this BIP.  Perhaps this method of probing for technical support is the main problem with BIP 16, and should be abolished in favour of testing with actual transactions.

This is a protocol specification not a description of one particular implementation.  There are at least two independent implementations of bitcoin, and many more speaks or interpret the protocol or parts of it.  Many pools create their own coinbase.  You must know that by looking at the coinbase transactions in the blocks created by other pools.  Standard bitcoind don't put the name of the pool in the coinbase, to take one example.

For normal solo miners like me it is enough to upgrade the vanilla client.  I have no intention of creating my own coinbase, and my limited knowledge of C++ says I shouldn't do to many changes to the code.  If normal solo miners like me should be required to make this change by our own, the threshold for supporting BIP 16 (and I still mean technical support) and show it would be unreasonably high.

And if you read it another time with my interpretation of the word support, I'm sure you will take my point.  BIP 16 is a technical specification, not a political resolution.

No, you are just a troll who doesn't seem to understand what he's reading.  I say "seem to" because I just can't believe someone as articulate as you is incapable of comprehending what he's reading.


You can't?  Really?  Let me highlight the appropriate portions of the quote you just made:

To judge whether or not more than 50% of hashing power supports this BIP

Definition BIP: Bitcoin Improvement proposal
Definition Vote: a formal expression of opinion or choice, either positive or negative, made by an individual or body of individuals.
Definition Vote: the means by which such expression is made, as a ballot, ticket, etc.
Definition Vote: the decision reached by voting, as by a majority of ballots cast: The vote was for the resolution.
Definition Vote: a collective expression of will as inferred from a number of votes
Definition Vote: to express or signify will or choice in a matter, as by casting a ballot

Take your pick, I gave you 5 definitions of Vote to choose from.  

Now let me highlight the relevant portion of the BIP that you are failing to understand:

...miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.

I did not put that string into the coinbase transaction, it was put there for me.


Even you, yourself, know that what you are saying is a contradiction.  Right here in your quote.  If a miner has upgraded software the string "/P2SH/" should be up into the coinbase to indicate that support.  I did no such thing, it was put there for me.  I removed it.


Ok, done.  Now go back and read it again, and please tell me where it says that /P2SH/ is an indication of the number of blocks supporting pay-to-script-hash?  The only thing I see is this:  To judge whether or not more than 50% of hashing power supports this BIP.  It says nothing about supporting P2SH.  It says supporting the BIP.  Plain. Simple. Clear. Read it again.  Now go back and read it again before responding.  Now do it again, because you are not comprehending what you're reading.  Once more, do it again.  Maybe with 4 read throughs, it will sink through.


Once again, my problem is not with BIP 16, my problem is with the timeframe.  Ancillary to that, my problem is also with the "forced" vote trying to slip it by through an "upgrade."  If it were an honest inclusion it would not have to be rushed through in less than 4 weeks and included as a "stealth" upgrade.  As it is, it's little more than a forced protocol change with the illusion of legitimacy by making it a BIP.  Maybe BIP 16 is the best solution.  What I want is the time to come to that decision for myself, not be forced into it or rushed through it.

Please calm down.  I may be Norwegian, but I'm not that big and scary. ;-)

I have read it many times now, and I can't see any mention of a vote.  It says:
If a miner has upgraded the software (yes, it says right there that an upgrade will support BIP 16 transactions) the string "/P2SH/" should be put in the coinbase to indicate that support.  It makes counting very easy.  The purpose is even more clearly stated below:

See?  No vote is ever mentioned.  It is just a practical way of counting the combined hashing power of miners who have upgraded their clients to support this type of transaction.  The alternative would be to keep feeding BIP 16 transactions to the network and see how many blocks include them.  If you support BIP 16 transactions, you should put /P2SH/ in the coinbase to make counting easier and not postpone it for to long.

Now go back and read again, and please tell me where it says that /P2SH/ is a [political] vote and not merely an indication of the number of blocks supporting pay-to-script-hash.

I remember sometime back in 2010 (september?) when no blocks were generated any more due to a bug triggered by a non-standard transaction.  All miners had to upgrade their clients, and the new version discarded non-standard transactions.  This is an important reason why the simpler BIP 16 is preferred by most over BIP 17 and other suggestions, and it shows that a network-wide miner upgrade has been done successfully before.  If each pool counts as one miner, the number of miners must be lower now than it was back then when no pools existed and people mined on their CPUs.

Sturle, you are a troll and I am wont to respond to idiots like you, but I will do it against my better judgement.


I think you are unable to comprehend what "dishonest" means, since you keep using it in a context where it is either a) clearly incorrect or b) clearly inappropriate (which, I suppose, falls under the "incorrect" category as well.)  But at any rate, whether or not I 'undid' them is immaterial.  P2SH in the block chain is intended to vote FOR BIP 16.  It is not to indicate support for the ability to process P2SH transactions or not.  That is a side effect.  I already quoted the relevant parts of the BIP.  Go back and read and comprehend what you are reading before responding.


Please!  At first I didn't think you were that incompetent, but now I am not so sure.  Do you seriously think I was referring to adding six characters to the coinbase as being a problem?  I will handhold you through the process, since you seem completely incapable of sussing it out for yourself.  Apparently, I gave you too much credit:

Stability of a pool is usually predicated upon testing new versions of software before a general roll out.  In this case, upgrading from version(s) 0.3.24 and 0.4.0 is a rollout I was not prepared to make in such a short time frame (less than 4 weeks!  I love how you ignored that portion of your completely false/dishonest previous post) - which means I was not prepared to either a) upgrade to 5.x or b) modify 4.x to support P2SH.  Due to unexpected circumstances, I went ahead and rolled out a test upgrade on two work servers to 0.5.99 as a test (leaving the third, most used server on a stable configuration).  Because 0.5.99 is not tested and has potentially unknown consequences, and because at least one of my getwork servers does not suppot P2SH AND because the timeline for deployment for untested code is so ludicrously short, I do not support BIP 16, therefore I removed P2SH from the servers broadcasting it.  

Whether or not they are capable of processing P2SH transactions is immaterial.  I do not support BIP 16 as written. Period. As such, I do not vote for BIP 16 with P2SH in the coinbase.


Again with this lack of reading comprehension.  Please quote the relevant portion of the BIP where it states that somehow to "comply" with a BIP, which is a ridiculous statement anyway.  Do you even know what a BIP is?  It sounds like you don't, which is not surprising, since you seem to be talking out your ass with every post you make.  A BIP is a proposal, not a "requirement" of some sort that must be "complied" with.  Please go look up the definition of "proposal" if you are still having trouble with this concept.

But at any rate, lets see your quoting of this relevant portion of the BIP that somehow compels me to "comply" with it.  I've already quoted the relevant portion of the BIP that clearly states inclusion of P2SH is a vote for the BIP... nothing about compliance or requirements or even that P2SH indicates the client supports it.


Well, stick a fork in me, cause I'm done.  Apparently you can read the actual BIP text and still fail to understand it.  Or is it a case of you refusing to understand it just to be a dick?  I dunno and frankly I don't care.  Nowhere in the BIP does it state that P2SH in the coinbase is to indicate that the miner accepts BIP 16 transactions, only the miner is in support of BIP 16.  It's not really possible to write it more clearly, since I, and then you quoted the portion that CLEARLY INDICATES the exact OPPOSITE of what you write directly below it.  Are you just an idiot or what is it?  How can you be so dense as to quote something and then interpret the exact opposite of what it's clearly states?  

Who said anything about bitcoind needing my consent? Again, you are just being obtuse and it's getting kind of tiring.  P2SH, as defined by the BIP, is it vote for the BIP.  My "vote" was cast automatically.  That is not a vote.  That is my point.  Quite being such an idiot.