"Required" upgrade for Bitcoin-Qt/bitcoind versions 0.7.2 and older

[evilpete]

0.8.0 doesn't require an upgrade.  The special thing about 0.8.1 is that it has special time-limited block validation restrictions that are intended to enable the pool operators to upgrade.  After May 15th, 0.8.1 behaves the same as 0.8.0.  More than 51% of the mining hash power is applying the 0.8.1 restrictions to make sure no bdb-busters get into the chain.

As I understand, it was 0.8.0 client generated backward incompatible block last week, obviously they need to upgrade. Can you elaborate on that "time-limited block validation restriction"?

*All* block generators can be configured to generate a block that will break 0.7.x and earlier.  The problem is a valid block that passes all the bitcoin rules, but fails in a 3rd party library in an unpredictable way.

So 0.8.1 has a special set of code..  If (current_time < may 15th), reject otherwise-valid blocks that might close to breaking 0.7.x and earlier.  The majority of the hashpower runs this patch so that means that should somebody else generate a bdb-breaker block, most of the hashpower will orphan it and the network will reconverge on a chain that everyone can deal with.

The wildcard is all these heavy hitting mining operations with asics etc.  It is not out of the bounds of possibility that the big pools right now might not be able to scrape together a 51% majority for much longer.  New hashpower is being turned on at a great rate and not all is going into recognizable pools.  

Think about it.. if you had 50+ avalons in a room trying to pay themselves off, why not run your own bitcoind and get 100% of the revenue and 100% of the fees?  Folks like that probably aren't interested in an some future emergency workaround that involves them discarding valid blocks..  if they're even reachable at all.

[mb300sd]

0.8.0 doesn't require an upgrade.  The special thing about 0.8.1 is that it has special time-limited block validation restrictions that are intended to enable the pool operators to upgrade.  After May 15th, 0.8.1 behaves the same as 0.8.0.  More than 51% of the mining hash power is applying the 0.8.1 restrictions to make sure no bdb-busters get into the chain.

As I understand, it was 0.8.0 client generated backward incompatible block last week, obviously they need to upgrade. Can you elaborate on that "time-limited block validation restriction"?

*All* block generators can be configured to generate a block that will break 0.7.x and earlier.  The problem is a valid block that passes all the bitcoin rules, but fails in a 3rd party library in an unpredictable way.

So 0.8.1 has a special set of code..  If (current_time < may 15th), reject otherwise-valid blocks that might close to breaking 0.7.x and earlier.  The majority of the hashpower runs this patch so that means that should somebody else generate a bdb-breaker block, most miners will orphan it and the network will reconverge on a chain that everyone can deal with.

The wildcard is all these heavy hitting mining operations with asics etc.  It is not out of the bounds of possibility that the big pools right now might not be able to scrape together a 51% majority for much longer.  New hashpower is being turned on at a great rate and not all is going into recognizable pools. 

Think about it.. if you had 50+ avalons in a room trying to pay themselves off, why not run your own bitcoind and get 100% of the revenue and 100% of the fees?  Folks like that probably aren't interested in an some future emergency workaround that involves them discarding valid blocks..  if they're even reachable at all.

But as of right now, and most likely until May 15th, its beneficial for the miner to upgrade and cooperate rather than risk his blocks getting orphaned by the pools.

[evilpete]

But as of right now, and most likely until May 15th, its beneficial for the miner to upgrade and cooperate rather than risk his blocks getting orphaned by the pools.

Yes.

If you are running a mining program as part of a 3rd party pool, it does not matter what bitcoind you run.  Your pool is constructing the blocks, not your mining program.  With the notable exception of Deepbit, most are running 0.8.1 now.

If you run solo mining, then 0.8.1 is your best bet to make sure you don't accidentally build against a "valid" block that the rest of the network will orphan soon and so you have a seamless transition on may 15th.

eg: you could run bitcoind 0.7 and it would accept a transaction with 4600 txn refs without throwing an exception. You'd start building on it.  However the rest of the hash power will orphan that block and any work you did relative to it would be wasted.

[johnyj]

So, it is like ultimatum in 60 days I wonder why deepbit is still left behind

[dscotese]

I raised my kids without using the "You are required..." phrase.  The trick is to let them decide:

You don't have to upgrade.  You can continue using the old client that violates the protocol by rejecting certain valid blocks.  You will be in danger of seeing an rejected blockchain as valid.  If anyone mines your blockchain, you will get confirmations that aren't valid.  This is because you have buggy software.  The risk you face will go up tremendously on May 15th.

Anyone can run whatever client they want to, but if their client violates the protocol, except in one special case, then they are likely going to suffer.  The clients before 0.8 violate the protocol.  The one special case in which this is ok is NOT detected by those old clients.  That special case is that a valid block with a large number (4500 I think) of transactions must be rejected (protocol violation) until May 15th, 2013.  The reason most of us have agreed to violate the protocol this way is to give you people with the old broken clients time to upgrade.

It's your choice.  It's not required.  You can run whatever you want, but Bitcoin won't work very well for you after May 15th if your client violates the protocol, which clients earlier than 0.8 will do as soon as the main blockchain accepts a block with a lot of transactions in it.