How to vote for/against p2sh?

[kjj]

So one way to vote no is to join the Eclipse pool?

Unfortunately for me I am not brave enough to cope with their color scheme

"No" votes are completely useless. They are exactly the same as not voting at all. Again, this is not a vote.

Sorry I must have missed something? The acceptance of p2sh comes down to 51% of the hash power running the new software? So if you are not solo mining then one way to have a 'vote', so to speak, would be to lend your hash power to a pool that represents your position i.e. running to new software or not.

I have read several of these threads so maybe I have things mixed up

Exactly right.  What matters is whether or not /P2SH/ ends up in the blockchain.  If you aren't directly hashing your own blocks and submitting them to the network (a solo miner), then you don't need the software at all, you just need to pick a pool that matches your preference.  At least one well known pool has committed to each side, and several others have stated their preferences, but haven't implemented it yet.

[1715536946]

1715536946

[1715536946]

1715536946

[sturle]

BIP 16 is not universally accepted.  BIP 17 is an alternative (which I am not voting for at the moment, either).

One developer support BIP 17, and it is already very clear that BIP 17 will never gain popular support.  For technical and other reasons (transaction size and fees imposed on sender, security, etc).

BIP 16 was proposed on the 3rd of January, to be "ratified" by vote on the 1st of February.  That timetable is absolutely, positively ludicrous for a change of this type, and that is currently the sole reason EMC is not voting for or against it.  Until such time as I have time to evaluate it and/or the alternatives, makes the changes to my backend for the pool, deploy the changes and test them, then deploy the live backend, I will not vote for it.

You already did the changes required for your pool.  You didn't even answer if you undid all of them, or if you are just dishonest about it (miners support BIP 16 but don't put /P2SH/ in the coinbase).

The stability of the pool for the miners is of paramount importance.  I'm sorry that you feel that it's dishonest to want to maintain and stable, robust pool, but my opinion differs.

Please!  I don't believe you are that incompetent.  You do not seriously think the six chartacters /P2SH/ in the coinbase makes your pool unstable, and you didn't answer if you removed support for BIP 16 from bitcoind or not.  From what you write I suspect you of mining BIP 16 transactions without announcing it, which is dishonest and inconsistent with BIP 16 itself.  Did you or did you not remove support for BIP 16?  Did you do that by reversing the patch (and re-introduce OP_EVAL, which is bad), revert to an older version or patch it yourself (so much for stability)?

The fact that the vote is "forced" when you upgrade is also a red flag, as I already mentioned.  If it was a perfect plan, a forced vote would not be required and everyone would be scrambling to enable the vote.  As it is, the reception seems to be luke warm at best, indicating to me that there is little interest (and therefore little need) at best and flaws at worst.

Support for BIP 16 is introduced when you update, and so is the announcement in the coinbase.  This is to comply with BIP 16, which states that miner supporting BIP 16 transactions should include /P2SH/ in the coinbase to indicate the fact.  There is no forced vote.  You can decline to upgrade, and stay with a version not supporting BIP 16.

Additionally, I think you are the one who is confused as to what the point of the P2SH vote is for.  It's not to show what miners support it, it's to show what percentage of the hashing power supports BIP 16 and in the case of EMC, we do not at the present time.  Therefore removing the P2SH coinebase is exactly what is required by the BIP.  Let me quote the relevent part of the BIP:

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

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.

I did not put P2SH in the coinbase, it was put there for me without my consent.  This angers me.

I thought that was obvious.  /P2SH/ is there to indicate the fact that the miner accept BIP 16 transactions.  Is it possible to write it more clearly?  Otherwise the vote would be meaningless the way it is described.  The new bitcoind does this automatically.  Many pools generate their own coinbase, and need to patch their software to do the same when they choose to support P2SH.  If you think changes to bitcoind needs your consent (really? :-D), you should write your own version.  I doubt the developers will ask for your consent for every change they make or new feature they introduce to bitcoind.

There is nothing in the BIP to indicate the P2SH vote is to show what block miners support P2SH, only what block miners support the BIP.  If this is incorrect, the BIP needs to be fixed, not the other way around.  I do not support the BIP because of the timetable.  Given time, I may support P2SH or a revised BIP.

So you have removed support for BIP 16 transactions from your bitcoind?

[phelix]

BIP 16 is not universally accepted.  BIP 17 is an alternative (which I am not voting for at the moment, either).  BIP 16 was proposed on the 3rd of January, to be "ratified" by vote on the 1st of February.  That timetable is absolutely, positively ludicrous for a change of this type, and that is currently the sole reason EMC is not voting for or against it.
[...]

+1

appreciate your approach to this

[Inaba]

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

You already did the changes required for your pool.  You didn't even answer if you undid all of them, or if you are just dishonest about it (miners support BIP 16 but don't put /P2SH/ in the coinbase).

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!  I don't believe you are that incompetent.  You do not seriously think the six chartacters /P2SH/ in the coinbase makes your pool unstable, and you didn't answer if you removed support for BIP 16 from bitcoind or not.  From what you write I suspect you of mining BIP 16 transactions without announcing it, which is dishonest and inconsistent with BIP 16 itself.  Did you or did you not remove support for BIP 16?  Did you do that by reversing the patch (and re-introduce OP_EVAL, which is bad), revert to an older version or patch it yourself (so much for stability)?

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.

Support for BIP 16 is introduced when you update, and so is the announcement in the coinbase.  This is to comply with BIP 16, which states that miner supporting BIP 16 transactions should include /P2SH/ in the coinbase to indicate the fact.  There is no forced vote.  You can decline to upgrade, and stay with a version not supporting BIP 16.

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.

I thought that was obvious.  /P2SH/ is there to indicate the fact that the miner accept BIP 16 transactions.  Is it possible to write it more clearly?  Otherwise the vote would be meaningless the way it is described.  The new bitcoind does this automatically.  Many pools generate their own coinbase, and need to patch their software to do the same when they choose to support P2SH.  If you think changes to bitcoind needs your consent (really? :-D), you should write your own version.  I doubt the developers will ask for your consent for every change they make or new feature they introduce to bitcoind.

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.  

[sturle]

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

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

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.

I have read it many times now, and I can't see any mention of a vote.  It says:

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.

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:

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

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.

[Inaba]

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

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.

I have read it many times now, and I can't see any mention of a vote.  It says:

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.

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:

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.

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:

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.

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.

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.

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.

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.

[sturle]

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.  

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.

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.

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.

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.

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.

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.

[Maged]

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.

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.

[Inaba]

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

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.

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

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.

[sturle]

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

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

[Inaba]

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.  

[sturle]

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.  

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

[Inaba]

I agree that support applies to BIP 16, which is a technical specification of how P2SH transactions may work.

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.

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?

[sturle]

I agree that support applies to BIP 16, which is a technical specification of how P2SH transactions may work.

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.

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?

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 [...]

[paraipan]

don't feed it Inaba, you got point 

[Maged]

don't feed it Inaba, you got point 

Huh? Looks the other way around to me.

[paraipan]

don't feed it Inaba, you got point 

Huh? Looks the other way around to me.

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

[sturle]

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.

Gavin Andresen, the author of BIP 16, supports my interpretation here:

2) If, as a solo miner with an old client, compiled from source, wanted to vote in favor or against the P2SH, what changes exactly would I have to do to the source?  ...This question is strictly about adding the vote cast, nothing else.  What change(s) are necessary for that?

Don't do that, please. "Voting" with your coinbase should mean you actually do the extra validation required by p2sh, otherwise you're saying you support a feature when you really don't.

EclipseMC makes the same error the other way around.  Support the feature without announcing it in the coinbase like the BIP says.

[slush]

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

[Inaba]

2) If, as a solo miner with an old client, compiled from source, wanted to vote in favor or against the P2SH, what changes exactly would I have to do to the source?  ...This question is strictly about adding the vote cast, nothing else.  What change(s) are necessary for that?

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.

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

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