Topic: BIP 16 switchover date pushed to April 1 (Read 6788 times)

Those 32 blocks were generated by Eligius, but they won't be accounted for.
He is just saying "I'm against it", without any consequences for the "voting" because only "Support" blocks are counted.

I've heard you say that many times.  But how does D&T come up with this statement?

"377 Support vs 32 Oppose  (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other)."

Did he just make up the 32 that oppose?
Sam

1. This is NOT a voting.
2. Not putting /P2SH/ in your coinsbase is the same as "voting against".

I can vote for it or not vote at all.

Your original post states your annoyance at the 591, which I'm part of, that are not voting for or against.  Since I'm not a programmer and you programmers have not built in the option for me to choose, I cannot vote against.  And since the current client also is voting for P2SH with NO NOTIFICATION to the end user you have force people to vote for it that have no idea they are.
Sam

Really you are that helpless?  You can use choose to either use a p2sh capable bitcoind OR NOT.  You can choose to mine at a p2sh capable pool OR NOT.  Hence you can "vote" by your actions.

That's all well and good and informative.

But my point is that this "voting" can only be done by developers/programmers and not by ordinary mortals like myself since it requires a code change and recompilation.

So that gives developers free reign to do whatever they want, no matter what anyone else may think.
Sam

It's NOT a voting and just adding a couple of bytes will make things worse.
Those who include /P2SH/ in their coinbase aren't  just saying that they like BIP16, it means that their software is ready to support it.

An update:  It looks like Deepbit isn't supporting p2sh yet.  The "mystery miner" from Spain has modified his bitcoind to only send blocks to other major pools in an attempt to hide where they are coming from.  Since bitcoind uses the first IP it sees a block from to determine the owner it is thinking some of the mystery miner's blocks are from Deepbit.

WRONG.  Er wait I am talking to myself.  Looks like Tycho has turned on p2sh support in some blocks to test it out so likely those blocks are really Deepbit's blocks.

And how, exactly, does one bother themselves "to include a couple bits in the coinbase"?  I have seen no options in any of my Bitcoin Clients to "vote" one way or another on any BIP!
Sam

Edit: sarcasm removed, for now

377 Support vs 32 Oppose  (and 591 who can't be bothered to include a couple bits in the coinbase to indicate an opinion one way or the other).

I have just checked out http://blockchain.info/p2sh and I have verified Deepbit has started voting for P2SH.

Great!  I just hope everything goes smoothly and multisig is a success!

Response from forrestv at: https://bitcointalksearch.org/topic/1500-th-p2pool-decentralized-dos-resistant-hop-proof-pool-18313

If you do as Doc suggests please post the answer back here too.
Thanks,
Sam

The main development branch (0.6.0-beta) supports the -bip16 parameter and as far as I could detect has the necessary code.

Quick clarification on this, Solo miners need only upgrade the bitcoin client they are mining through in order to ensure generated blocks are "clean".

But, with P2Pool, because it's peer to peer. Would not EVERY P2Pool miner need to upgrade their clients or else the entire pool could be affected? (example being I'm mining against P2Pool, I'm using an updated client, but joebob is also mining on P2Pool with an old client. If his client happens to be the one that finds the block, even though I've contributed shares towards said block, and he includes the invalid tx, the whole block, and all contributing miners to that block get screwed correct?)

If this is the case, that's a pretty big problem for P2Pool miners. Because there is no way for us to know if the rest of the pool is updated. (and it essentially opens up P2Pool to a DOS attack vector. Anyone looking to take down P2Pool can join up with bogus clients and mine to start injecting bad blocks into the mining results for the whole pool... Sure it would only be proportional to the mining power brought to the table by the "attacker" relative to the rest of P2Pool, but it's still an attack vector).

Also what classifies as "upgraded". (ie: I'm running the latest official client from bitcoin.org, but not a dev branch. Do I need a dev branch? if so which version specifically)

Thanks!

Hope this time we'll get through.

Your summary is not very accurate or useful.


None of the development is going on in secret. The discussions are out in the public and are fairly transparent. If you don't have the time to follow and understand all of it, then thats a tradeoff you're choosing to make.  If there are reasonable ways to improve the transparency then I'm sure offers to help improve communications would be appreciated by all.

Or what do you expect? Certified mail on every commit?  You don't get to demand personal service.

(and frankly— a bit of unsolicited advice: the screeching bold faced text from an account with 25 posts just screams sockpuppet/troll — you might want to consider moderating your tone before you get written off as someone who's just trying to create controversy for fun)

When a change is *required* I'm sure the Bitcoin community will be behind it.  I'm also sure there will probably be allot of debate on how to implement a required change as well, but that is a good thing.
Sam

I know of a few solo/p2p miners whom I think I need to wake up, but it doesn't seem very straightforward to do so switch. Does the main branch now support BIP 16?

Let me summarize for you:

The issue that was found was NOT a big problem. Backwards compatability for miners was never a requirement for P2SH. Regular users do not need to upgrade but miners do, that is not a problem. Miners need to get used to the fact they might need to upgrade from time to time. Even users do but for them it should be different, slower. For example the 3.x Bitcoin clients don't work anymore. I expect that the 4.x clients will work for a while yet.

There is plenty of time for miners to upgrade, in best case there is still over a month to the switchover date. This is a good amount of time to do more testing with BIP 16 as well.