Topic: "Required" upgrade for Bitcoin-Qt/bitcoind versions 0.7.2 and older (Read 2777 times)

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.

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

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.

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.

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

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.

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

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.

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

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

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

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.

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

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.

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.

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.


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.

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

https://bitcointalksearch.org/topic/should-there-be-three-laws-of-bitcoin-20866

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

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.


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.

Why would anyone generate such a block ?

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.

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.


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.