Topic: How to vote for/against p2sh? - page 2. (Read 3462 times)

+1

appreciate your approach to this

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

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

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

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.
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.
So you have removed support for BIP 16 transactions from your bitcoind?

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.

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

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

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

There was a public meeting among the developers awhile back.

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.

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


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.

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

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.

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

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.

https://bitcointalksearch.org/topic/old-p2sh-debate-thread-58579

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.

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

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:

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

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.

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.