IMPORTANT: April 1 deadline for BIP16 support

[Gavin Andresen]

I'm posting this to both this and the Mining Pools subforum:

To all pool operators, solo miners and p2pool miners; I have an announcement.

As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.

Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.

This chart shows support over the last week: http://blockchain.info/P2SH.  Support is well over 70%.

So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.

p2pool users will also need to upgrade to the latest version of p2pool.

If you are a miner connecting to a mining pool, you can ignore this message.

For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.

Backports of the BIP16 code to earlier releases are available if you are running a patched bitcoind. Patched binaries of older releases will be available soon.

[1715137877]

1715137877

[1715137877]

1715137877

[1715137877]

1715137877

[Gavin Andresen]

See this thread for BIP16-compatible-backported release candidates:
  https://bitcointalk.org/index.php?topic=72069.0

A final 0.6 release candidate will be out very soon, the last issues are being resolved now.

Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

[jetmine]

Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

This only applies when you include transactions generated by other people (because the old client will not be able to fully verify them).

If you think this statement is incorrect, then please elaborate (with technical details).

[kokjo]

you do know that that is a sucky date, to make important decisions on, right? no one will believe you, because they are expecting that you will lie.

[rjk]

Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

This only applies when you include transactions generated by other people (because the old client will not be able to fully verify them).

If you think this statement is incorrect, then please elaborate (with technical details).

Why aren't you including transactions from others? Hmmm...

[Gavin Andresen]

Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

This only applies when you include transactions generated by other people (because the old client will not be able to fully verify them).

If you think this statement is incorrect, then please elaborate (with technical details).

That statement is incorrect.

There are two ways you might waste time hashing:
1) Put a bad BIP16 transaction in your block
2) Building on top of a bad block produced by somebody else

So even if you don't include anybody else's transactions in your blocks you will still almost certainly waste some time hashing by building on top of invalid blocks produced and announced by some other lazy miner running an old version of bitcoind.

[DeathAndTaxes]

There are two ways you might waste time hashing:
1) Put a bad BIP16 transaction in your block
2) Building on top of a bad block produced by somebody else

Yeah "mystery" miner this applies to you to.  No more 700 bitcoins per day unless you upgrade.

[RoadStress]

If he doesn't see this message can he figure out that he is wasting hash power? How?

[DeathAndTaxes]

If he doesn't see this message can he figure out that he is wasting hash power? How?

First clue will be his wallet shows block reward and then it becomes orphaned and disapears as the longer valid chain becomes dominant.  While this can happen occasionally if he is building on invalid chains it will happen at much higher frequency.   I would imagine it wouldn't take more than a handful of block rewards being reversed before someone investigagtes.  

Then again if you have a farm (ethical or not) which generates $1M annually wouldn't you atleast lurk this forum?

[bitcool]

you do know that that is a sucky date, to make important decisions on, right? no one will believe you, because they are expecting that you will lie.

To Be(lieve) Or Not To Be, That Is The Question 

[Gavin Andresen]

To Be(lieve) Or Not To Be, That Is The Question  

About 20 minutes until the deadline... I expect to hear some very loud complaining about "I wasted a bunch of time generating orphan blocks why didn't you WARN me!" in the next few days. This is not an elaborate April Fool's joke.

[DeepBit]

About 20 minutes until the deadline... I expect to hear some very loud complaining about "I wasted a bunch of time generating orphan blocks why didn't you WARN me!" in the next few days. This is not an elaborate April Fool's joke.

...or the most elaborate one :)

[finway]

Seems it's going through, smoothy.

[bitpop]

It's not totally their fault, tracking down updates and especially required updates is a pain. There will always be 10% still running 0.4 and then coming back a year later to check their miner wondering what happened..

Bitcoin desperately needs a mailing list. A locked google group that only instantly emails important updates for bitcoin, namecoin, p2pool, cgminer, etc.

[terrytibbs]

How's progress?

[bitpop]

1) Well this isn't a bug
2) It's been talked about since January
3) It's a feature that was voted on by many and needs everyone's support to work

[DeathAndTaxes]

1) Well this isn't a bug
2) It's been talked about since January
3) It's a feature that was voted on by many and needs everyone's support to work

It doesn't need everyone's support just a majority of miners.  It has a supermajority of miners.  The rest of miners will  need to upgrade if they don't the price of their incompetence will be orphaned blocks.

[hazek]

1) Well this isn't a bug
2) It's been talked about since January
3) It's a feature that was voted on by many and needs everyone's support to work

It doesn't need everyone's support just a majority of miners.  It has a supermajority of miners.  The rest of miners will  need to upgrade if they don't the price of their incompetence will be orphaned blocks.

Also wrong. The majority was only needed to avoid a permanent fork.

[DeathAndTaxes]

Also wrong. The majority was only needed to avoid a permanent fork.

No that isn't true.

As long as one miner continues to mine the older version the the fork will continue to exist.  There is no magical number to avoid a fork when implementing a breaking change to the protocol.  A super majority of miners, developers, exchanges, and merchant helps to create a smooth transistion.  If all end users see balances based on the new version then the alternate version has no real relevance.

A mere majority would be horribly chaotic and damaging to Bitcoin.  A worst case scenario.  One either wants the change to have overwhelming support or negligible support to ensure one chain remains dominant.

A 50/50 split would be catastrophic causing double spends across the network as the two incompatible chains switched places in height.  This is why a condition for moving forward with BIP16 was 70%+ support.  That ensure the minority fork would rapidly fall behind and consensus remains without dispute.

[grich]

I have a question
Why we have "block/transaction versions" if we don't use it? There was a good moment to increment version number and later use it in such way: if Miner gets a "strange" block with increased version number -- it is a signal for him to check for new soft. We could have avoided many of lost orphaned blocks