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

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

[1714981140]

1714981140

[1714981140]

1714981140

[1714981140]

1714981140

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