How to vote for/against p2sh?

[Costia]

I am a miner on p2pool
how does the voting process work?

[Costia]

so updating to 0.5.2 = vote for P2SH
staying with 0.5.1 = vote against P2SH
?

that doesnt sound right , there are ~900 "no vote" blocks

[Costia]

only miners who will generate blocks at that time will actually get to vote?
they are the ones generating the blockchain, the other clients can reject the change but there is no way to know.
so there might be quite a mess if most of the clients will accept only the shorter blockchain.

[sturle]

so updating to 0.5.2 = vote for P2SH
staying with 0.5.1 = vote against P2SH
that doesnt sound right , there are ~900 "no vote" blocks

Yep.  I have deleted my post.  My source was the topic in #bitcoin-mining, and it was set by luke-jr.  Never believe a word typed by luke-jr!  When checking the facts, nothing checks out except for Eligius (his own pool) using his own special version which all the main developers think is bad for many good reasons.  Examining blocks from EclipseMC shows that the pool supports P2SH.  And for casual solo miners and p2pool miners to support P2SH, you need to pull bitcoin from git and compile it yourself.  I think that is making the threshold for voting for a better future for Bitcoin far to high.

[Maged]

I think that is making the threshold for voting for a better future for Bitcoin far to high.

That's because it is not a vote. The point is to see whether or not 50% or more of the network is ready to activate the feature. That requires that people upgrade, not just say that they support it.

The real vote among people has already happened.

[Costia]

upgrade to 0.5.2 or the version from git?
by 50% of the people you mean 50% of the miners?

[jake262144]

50% of the network's HASH POWER. That's the only thing that matters from the block chain's perspective.

You can use Luke's patch to modify your bitcoind code:

... I have written code that allows you the freedom to vote for (-p2sh) or against (-nop2sh):
    https://github.com/bitcoin/bitcoin/pull/755
You can apply it to your bitcoind code like so:
    curl https://github.com/bitcoin/bitcoin/pull/755.diff | patch -p1

[Costia]

so the voting is a patch?
strange
i am on a windows machine, i assume i need gcc on cygwin/mingw to compile the patched client
and maybe python as well
way too much effort/time
i will wait for a pre-compiled binary

[jake262144]

Luke's patch allows you to choose whether or not you want to vote.
If you use the default, compiled bitcoind it will vote in favor of BIP16 (OP_P2SH) by default.

If you are using a pool, you confer your voting right to the pool operator. They will use your hash rate to vote whichever way they want.

[Explodicle]

The real vote among people has already happened.

Could you elaborate?

https://bitcointalk.org/index.php?topic=58579.0

[Inaba]

EMC voting for P2SH was a mistake and has since been corrected to remove P2SH votes.  Simply running a base 0.5.2 - 99 client will cause you to vote for P2SH without requiring any interaction.  Having recently made some backend server changes, I elected to update the bitcoind clients and poof, suddenly I'm voting for P2SH without my consent. 

Removing P2SH from the coinbase flags removes the vote.  It's not exactly a vote against, but it's not a vote for, either, which is really what's being examined.

[sturle]

EMC voting for P2SH was a mistake and has since been corrected to remove P2SH votes.

Why did you decide to use EMC's users hashpower to vote against P2SH?

[Inaba]

Because the timetable is too aggressive for proper testing/vetting and deployment.

I am also not convinced that it is the proper solution to the problem.  I'm not saying it's not, either - but a 4 week timetable for deployment of this magnitude is unreasonable and irresponsible, not only from a blockchain (Miner upgrade) perspective, but also from a pool operator/backend perspective.

And I did not use it to vote against P2SH, we were never voting FOR it, simply because the timetable was too aggressive.  As it happens, some other issues caused a premature upgrade which briefly enabled a force vote for P2SH.  That alone should signal a major problem, when a change requires stealth to be slipped into the codebase.  It's like tacking on riders on bills in Congress - yeah vote against child porn!  Oh, by the way, we are attaching this little rider to say that we can confine you in GitMo without due process as well... but if you vote against this bill, you're for child porn!  

Like I said, and I thought it was clear, but apparently not.  WE are not voting for or against it, we are simply not voting at the present time.

[sturle]

Because the timetable is too aggressive for proper testing/vetting and deployment.

I am also not convinced that it is the proper solution to the problem.  I'm not saying it's not, either - but a 4 week timetable for deployment of this magnitude is unreasonable and irresponsible, not only from a blockchain (Miner upgrade) perspective, but also from a pool operator/backend perspective.

Different options have been discussed and implemented for a great deal more than 4 weeks.  No point in just sitting on the code and wait.  Wait for what?

And I did not use it to vote against P2SH, we were never voting FOR it, simply because the timetable was too aggressive.  As it happens, some other issues caused a premature upgrade which briefly enabled a force vote for P2SH.  That alone should signal a major problem, when a change requires stealth to be slipped into the codebase.  It's like tacking on riders on bills in Congress - yeah vote against child porn!  Oh, by the way, we are attaching this little rider to say that we can confine you in GitMo without due process as well... but if you vote against this bill, you're for child porn!

Like I said, and I thought it was clear, but apparently not.  WE are not voting for or against it, we are simply not voting at the present time.

Force vote and child porn!?  Congress?  Seriously.  Do you support P2SH, or did you remove that part of the code as well?  Because now you are confusing.  I thought the entire point of the vote was to show if the miner supports P2SH, to make it possible to switch P2SH on when the network is ready.  If you support P2SH without announcing support, you are simply dishonest and sabotaging the vote.

P2SH was implemented by a strong majority among the developers.  Pulling the support into git and enabling it was only the next natural step.  How can you make a majority of miners support P2SH in any other way?

[Inaba]

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

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.  The health and welfare of my pool and the miners on it are my main priority and I will not deploy untested code unless absolutely necessary... that said, the fact that I was forced into deploying untested code due to circumstances completely unrelated to this is what made it possible for EMC to inadvertently vote for BIP 16 and it goes to illustrate exactly WHY I do not want to deploy untested code - unexpected things happen.

It is neither dishonest nor is it sabotaging the vote, because I explicitly do NOT support it right now simply because I have not had time to investigate what the consequences are for the pool.  If the timetable were set at a reasonable pace, then your argument may have some value, but since the proposal to deployment timeframe is so short, removing a vote is simply prudent.

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.

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.

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.

[Maged]

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.

At the time, there was unanimous support for BIP 16. And don't let the reception fool you: all of the major developers are, at the very least, in overwhelming agreement that we need BIP 16 or 17 as soon as possible.

That being said, what few people realize is that it's actually possible to "vote" for BOTH BIP 16 and 17. If you merge the two BIPs into your code, you can go either way.

[Maged]

The real vote among people has already happened.

Could you elaborate?

https://bitcointalk.org/index.php?topic=58579.0

That's not a real vote. That's a poll on a single forum.

There was a public meeting among the developers awhile back.

[Defkin]

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

[Maged]

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.

[Defkin]

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