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

[Richy_T]

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

[1714928174]

1714928174

[kseistrup]

I agree.

[mb300sd]

How about, "Upgrade or be left on a dead fork"

[Richy_T]

Indeed. In fact that's another complaint. It doesn't even explain properly why you *should* upgrade.

[eb3full]

Let us know what you think of 0.7.2 in a few months.

[Gabi]

Indeed. In fact that's another complaint. It doesn't even explain properly why you *should* upgrade.

The code is open source, check it and you will discover why

[phillipsjk]

I think required is the appropriate wording. only 0.7.2 is required (with work-around), 0.8.1 is recommended.

[Richy_T]

Let us know what you think of 0.7.2 in a few months.

Reading comprehension not your forte?

If you don't upgrade you'll be snivelling in the dark crying why no one warned you to upgrade.

Yeah, OK....

The code is open source, check it and you will discover why

That's an advertisement for Bitcoin for sure... I am a person who *would* be able to comprehend the source and *I* don't want to read it.

Simply saying "If you stay on 0.7, you are likely to end up the wrong side of a forked blockchain", which is what I assume is at issue, would have been enough.

[Richy_T]

I think required is the appropriate wording. only 0.7.2 is required (with work-around), 0.8.1 is recommended.

I think "strongly recommended" or "urgently recommended" would be appropriate. There is currently no one with the authority to require anything wrt bitcoin.

[Walter Rothbard]

I had the same concern when I saw how this announcement was worded.

[bg002h]

Required is unarguably the appropriate term. If you don't upgrade, you're technically not running Bitcoin anymore (and may end up on your own split chain). Required doesn't mean you must...it means you must if you want to run Bitcoin.

Recommended would imply if you do nothing you'll still be running Bitcoin. 

[Richy_T]

Sez who? Bitcoin central control?

[evilpete]

Sez who? Bitcoin central control?

Not as such.. but more than 51% of the hash power is running 0.8.1 which has the code to automatically withdraw the artificial limit that buys people time to upgrade in an orderly fashion.  The train has already left the station.

Yes, the wording is a bit strong, but as we saw there are a lot of people who are confused or unclear about what they should do.  You obviously understand the situation and have already made an informed decision.  But think of the other people who aren't paying as much attention, or just don't care.  All they want is to be able to send, receive, and get confirmations.  They do have to do something if they don't want to get left behind on the wrong side of the next block that breaks their client.

[Richy_T]

Sez who? Bitcoin central control?

Not as such.. but more than 51% of the hash power is running 0.8.1 which has the code to automatically withdraw the artificial limit that buys people time to upgrade in an orderly fashion.  The train has already left the station.

Yes, the wording is a bit strong, but as we saw there are a lot of people who are confused or unclear about what they should do.  You obviously understand the situation and have already made an informed decision.  But think of the other people who aren't paying as much attention, or just don't care.  All they want is to be able to send, receive, and get confirmations.  They do have to do something if they don't want to get left behind on the wrong side of the next block that breaks their client.

I don't disagree with any of this. Just the wording.

I think it's important if not essential that Bitcoin remains a decentralized, collaborative effort and the language should reflect that.

With that said, I think I've made my position clear so I'll leave the floor for others to discuss now.

[oOoOo]

Is there any info on who actually wrote that?

[tysat]

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

Worry less about wording and more about upgrading?

[coretechs]

http://www.youtube.com/watch?v=-ZRUaDGW7WQ

[phillipsjk]

Sez who? Bitcoin central control?

Says the miners in control of the majority of hasing power, after consultation with developers. There used to be a link to a thread including Gavin's diplomatically worded e-mail at the top of the forum.

Was only able to find this earlier thread where they ask miner to revert to 0.7
https://bitcointalk.org/index.php?topic=152030.0

[JeromeS]

I agree with what everyone else said about the wording.

Also, I think our benevolent dictator dev(s?) decided the only thing they can do to push this (unnecessary) upgrade is to use stronger language without giving any reasons or details, which is comforting to me tbh.

Bitcoin is not decentralized until it's working like an actual protocol with multiple clients and possibly blockchains. Right now there's only a handful of people who understand the (undocumented) source code and who are writing its future as they see fit. This cannot be good.

I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.

[tysat]

I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.

Are you saying you want 2 blockchains going?  Your wording is a little confusing there.

[JeromeS]

Two more problems I have with that announcment,

Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.

Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.

Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.

How ?

[JeromeS]

I think an intentional fork is exactly what we need right now. At least to have something to come back to as the main bitcoin becomes less and less attractive.

Are you saying you want 2 blockchains going?  Your wording is a little confusing there.

Yes. meant to say if/when the main bitcoin etc...

It would be better than having only one blockchain going in the wrong direction.

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

[dree12]

Two more problems I have with that announcment,

Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.

Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.

Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.

How ?

0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true.

[JeromeS]

0.7 can in fact create blocks that 0.7 will reject. By increasing the number of locks, 0.7 will create the very blocks other 0.7 clients would reject. Both statements are therefore true.

What does set_lk_max_locks do ? and why didn't we have this problem before people started mining on 0.8 ?

[tysat]

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?

[evilpete]

Two more problems I have with that announcment,

Miners/mining pool operators

And if you are creating blocks and cannot upgrade to version 0.8.1 for some reason, you should not set_lk_max_locks in a DB_CONFIG file until May 15th; if you increase locks before then you run the risk of creating or building on blocks incompatible with the rest of the network.

Correct me if I'm wrong, but this is not exactly true, is it ?
If enough miners decide to start mining an alt blockchain now that is only compatible with the 0.8's there will just be another reorg on May 15 and their chain will become the main one. They actually stand to benefit from this.

Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.

Why this is necessary

A bug caused a temporary block chain fork on 11 March, 2013. After investigating that bug, we determined that the bug can happen even if the entire network was still running old versions of Bitcoin-Qt/bitcoind.

How ?

Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.

[theymos]

Also, I think our benevolent dictator dev(s?) decided the only thing they can do to push this (unnecessary) upgrade is to use stronger language without giving any reasons or details, which is comforting to me tbh.

I share Luke-Jr's view that hardforks should usually have two years of advance notice, but this hardfork is definitely necessary sooner. The behavior of old nodes is closely tied to the behavior of BDB: the limits are not on the number of transactions or bytes, but on database-specific things which aren't easy to track. Without this hardfork, all full nodes would be required to either use BDB or come up with some very complicated heuristics (which don't currently exist) to guess at what BDB would do. Even worse, old nodes don't always have consistent limits. It isn't reasonable to leave the network in this messy state for two years.

[JeromeS]

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?

It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.

Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.

I think there's an agreement between everyone involved that the pools won't make 0.7 incompatible blocks until May 15. I was just saying that technically what the announcement said wasn't true.

Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.

Why would anyone generate such a block ?

[JeromeS]

I share Luke-Jr's view that hardforks should usually have two years of advance notice, but this hardfork is definitely necessary sooner. The behavior of old nodes is closely tied to the behavior of BDB: the limits are not on the number of transactions or bytes, but on database-specific things which aren't easy to track. Without this hardfork, all full nodes would be required to either use BDB or come up with some very complicated heuristics (which don't currently exist) to guess at what BDB would do. Even worse, old nodes don't always have consistent limits. It isn't reasonable to leave the network in this messy state for two years.

Okay, it makes more sense to me now... (still uncomfortable with the whole thing though)
anyway, thanks for explaining.

[bitcool]

For a voluntary, consensus-based, p2p system,  "required" change is mostly bad; luckily this time, it not a protocol change (yet).  

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

[evilpete]

Also, apart from all that, I think several separate chains would actually improve bitcoin, even if they all follow the same rules. Transactions get split up between the chains and each network has less overhead for one thing.

Dude, several chains would make things super confusing.  Bitcoin is already hard enough to understand for new people, do you want them to have to learn how to segregate different chains as well?

It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.

Except it's already done.  The vast majority of the mining pool hashpower has already switched.  The miners flushed somewhere between $500-$1000 of mining revenue down the toilet to buy time for people to update in a more orderly fashion, you can be pretty sure they won't do it again.  Miners won't risk being on the wrong side of a fork.

When a miner with nefarious figures out that they can knock the un-upgraded miners off the main block chain by deliberately creating one of these blocks and that they'll get a larger share of the mining rewards as a result.. *somebody* will do it.  It's just a question of when.  It probably won't fly before may 15th, but it'll be game-on after then.

I think there's an agreement between everyone involved that the pools won't make 0.7 incompatible blocks until May 15. I was just saying that technically what the announcement said wasn't true.

It's more than the pools though.  You don't have to be a pool to generate a bdb-killer block.  If you look at the 0.8.1 patch (which the big pools are running), they are rejecting blocks with more than 4500 transaction references.  This is lower than what the 0.7's could handle which was somewhere around 4800-4900.  The irony here is that if somebody makes a valid block with 0.7 that had 4700 references, it'll be rejected by > 51% of the hashpower due to the 0.8.1 may 15 restriction even though it would have worked with all existing 0.7 installations.

Remember, you don't have to be a pool to generate blocks.  I could have an avalon, or I could get lucky with my gpu miner and a tweaked bitcoind that tried to gather up as many SatoshiDice transactions as possible in order to break 4800-4900 or so.  If I could figure a financial advantage in knocking 10% of the miners off the main chain and I got lucky, then I could do it.  Anyone can do it so long as it is a valid block and meets the rules of > 51% of the hashpower.

The bigger problem is that for some clients it might be 4911, and others 4850, or it might change to 4870 after a restart.. The limit is determined by internal state of 3rd party library code, not the bitcoin code rules.  Simply running 0.7 isn't enough of a "is it valid?" test.  Suppose I wanted to knock off just the 4850 and 4870 nodes?  I could generate a block (if I was lucky with mining) that would fork off those guys and leave the 4911 nodes on the chain for a bit longer.

It is this level of non-determinism in old clients that is the problem.

The only thing that is preventing mischief right now is that the bulk of the hashpower switched to 0.8.1 already.  If they were running 0.7 or earlier, a malicious pool (or a lucky person) could generate blocks to split them up.

Because bitcoind 0.7 can be configured generate a valid block that can cause other bitcoind 0.7 instances to overflow their lock tables and drop the valid block.

Why would anyone generate such a block ?

If I was a miner and wanted to knock 10-20% of my competition  off the chain so I got a bigger slice of the pie? Maybe I was USGOV trying to undermine bitcoin confidence?  Maybe somebody trying to just cause trouble..  If it can be done, somebody will do it.

Anyway, the train has already left the station.  If you want to be certain of being able to get confirmations on the main chain after may 15th, you have to do *something* before then.

[tysat]

It's already pretty easy. Just run a client/version of a client that is incompatible with the chains you don't want. So if 99% of the hashing power makes 0.8 blocks after May 15 but there's still 1% left making an 0.7 compatible chain all the 0.7s will tune to the second blockchain automatically. At least that's my understanding.

But imagine the 1% trying to figure out where to spend their bitcoins(0.7) since 99% of people will be accepting bitcoins(0..  Plus a split in theory doubles your bitcoins, but only for the existing ones, as you'd have coins in both blockchains spent independently of each other.  I think a whole different protocol (litecoin, namecoin, etc) is a lot better than having 2 bitcoin blockchains.

[Eri]

This isnt directed at anyone specific, its more a general statement.

Everyone that disagrees with this change either doesnt fully understand the situation or Doesnt fully understand bitcoin Or both.

If this wernt a good choice you can believe this, there would be allot of people who know what they are talking about complaining and pointing it out in a serious way.

the biggest problem with bitcoin is that a huge number of people dont fully understand it when they think they do and then go on to talk about 'problems' that dont exist. bitcoin has allot of traps where you think you get it, learn something else and build on what you know then realise you didnt quite get it and that a previous assumption was wrong.

im not going to explain it. but keep in mind, if you think you fully understand bitcoin and dont update. you run the risk of being left behind because you were sure you understood it. your better off being safe then sorry.


one thing i personally hope this situation drives home for people, is that they need to reasonably keep up to date.

personally, whether its 2 months or 2 years, i feel some people/businesses wont update and will be left behind. but we cant force them, and we cant stay in the past because they dont want to update. they will learn the hard way that keeping up to date is important.

[Littleshop]

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

Worry less about wording and more about upgrading?

+1

The language is clear.  If you don't like it, don't upgrade.  It is required because it is not a protocol change but a BUG FIX.  If you do not upgrade, the bug will be quite evident for you.  

[evilpete]

http://bitcoin.org/may15.html

I don't like the language used. No one can "require" me to do this. I understand why I should and I will but the wording seems wrong to me. Opinions?

Worry less about wording and more about upgrading?

+1

The language is clear.  If you don't like it, don't upgrade.  It is required because it is not a protocol change but a BUG FIX.  If you do not upgrade, the bug will be quite evident for you.  

It'll work for a short while for people that don't upgrade (or apply the bug fix in their old client) but it won't take too long before transactions fail verification on the main chain and can't be confirmed.

I predict, in vague hand-wavey terms:

• There will be a chain fork in fairly short order.  Somebody will generate a large and complex block to prove a point and split off the non-upgraded/fixed clients.
• Some holdouts will split off on their own blockchain fork, either accidently or by refusing to go with the majority, or leftover botnet members.
• Block generation rates will crash on the alt chain but there will be a few miners running that people have forgotten about.

By May 15th the difficulty will be huge..  blockexplorer.com predicts the next jump will be from the current 4.7 million to 6.1 million..  If the next 2016 block calculation is "close" at the time of the alt chain fork, then the difficulty won't drop much.  If it is distant enough to cause the calculation to drop then it'll take forever for the alt chain to get there.  The arrival of the asic miners is turning the dial up so high that the alt chain just won't be able to generate enough blocks to survive.

The people with the high end hardware won't be sending blocks to the alt chain, they'll be looking to get a ROI on the main chain ASAP.

[mb300sd]

For anyone who can't figure out how to do this... simply click and run.

https://mega.co.nz/#!xpxH2D7D!PSmX-Q6aL1W5AZnptZlyxnDyUvV41sgogoow5JQ0gpg

Code:

echo set_lg_dir database > %APPDATA%\Bitcoin\DB_CONFIG
echo set_lk_max_locks 120000 >> %APPDATA%\Bitcoin\DB_CONFIG

[johnyj]

Always good to check the current node version distribution:

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293

If this chart is correct, more than 5000 nodes runs 0.8.0, 261 nodes have upgraded to 0.8.1 ... Rest more than 6000 nodes are 0.7.2 or below. But I suppose those 0.8.0 nodes have the soft block size limit set at 250K to be compatible with 0.7.2 or before

[evilpete]

Always good to check the current node version distribution:

http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293

More than 5000 nodes on 0.8.0, 261 nodes upgraded to 0.8.1 ... but I suppose those 0.8.0 nodes have the block size limit set at 250K

Also keep in mind the difference between nodes and hash power.  This is also looking at version strings and can't tell whether the DB_CONFIG fixess have happened on old versions.

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.

[johnyj]

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

[eleuthria]

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

The majority of hash power is already on 0.8.1.  It's the hash power of the network that needs to be on 0.8.1 to prevent a fork event prior to the May 15th deadline.  Regular users are fine running 0.8, because 0.8 is compatible with 0.8.1.

As long as majority hash power is on 0.8.1, there will not be a hard fork event until the May 15th deadline.  There could be a soft fork where somebody generates a 0.8.1 rule-breaking block that also breaks 0.7, but since most hash power is on 0.8.1, which will not accept blocks that break 0.7 until May 15th, it will eventually converge back into a blockchain that is compatible with all nodes, just like how the previous fork was eventually fixed when majority hash power created a chain that was longer than the incompatible fork.

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