Understanding why the call to rollback to v0.7 was made.

[nebulus]

What exactly do you mean by roll back? I can't get the chain on 0.7 to update...

[1715166020]

1715166020

[1715166020]

1715166020

[Stephen Gornick]

what are locks?

With databases, locks are generally referring to something that must be done in a series.  With multiple CPUs, there can be the situation where two pieces of code want to change the same variable at the same time.  Think of an increment operation.   If you have a value of four and that gets incremented by both at the same time, the result would be five, not six like it is supposed to be.     So a lock basically gives one instance of the code the ability to make the change, and then after that lock is released the next instance of the code can do what it needs to do.  So that value goes from four to five, and then five to six.

So in the context of the "bug" in v0.7 and prior versions, the setting used for maximum locks for BDB was below that necessary for a transaction that first made it into a block on a v0.8 node. v0.8 doesn't use BDB and therefore doesn't have that same restriction.  There was a rule in the bitcoin protocol, due to a specific BDB configuration, that wasn't expressly known previously.

[Edit: And here is the info specifically on the BDB locks configuration:

Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits.

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value.

[Stephen Gornick]

What exactly do you mean by roll back? I can't get the chain on 0.7 to update...

By rollback I think he meant have miners downgrade to v0.7 (i.e., roll back the version of software they are using to a prior relese).

If you are having an issue getting your client to sync with v0.7, that probably has nothing to do with the fork.  You probably should open a thread on the Tech Support forum board for that (if the typical suggestions of check your connections, delete the blockchain data files and re-download, etc. don't work for you.)  [Edit: Or move on over to v0.8 which doesn't use BDB for the blockchain.]

[nebulus]

All right, thanks, man... I can get the chain fine on the 0.8. Was not sure if the problem was related.

[eldentyrell]

Thank you for posting this.  However, what you write about risks on the 0.7 branch is not correct.

However in time as hashing power fled the v0.7 fork remaining nodes would become more and more vulnerable to a variety of attacks.  Not just from a potential 51% attack, but also from accepting generated coins which were valid on the v0.8 blocks and even non hashpower related double spends.  

Actually this isn't true.  The Satoshi client checks for long invalid chains (this line of code); if it finds one it goes into safe mode and stops processing transactions or responding to RPC calls.  The message three lines below that line of code is what Pieter Wuillie is talking about in the original announcement:

If you're on 0.7 or older, the client will likely tell you that you need to upgrade.

The now-infamous OKPAY-BTCe double-spend was the reverse problem: it was an attack on a 0.8 client (or a 0.7 client that for some weird reason accepted the large block -- there are unconfirmed reports that the bug is platform-dependent).  Unfortunately that problem is a lot harder to solve.  The Satoshi client needs to start watching for long-and-recent-but-not-longest orphan branches.

[Stephen Gornick]

I am unclear about the compatibility of older versions earlier than 0.7.

The BDB database lock limit issue discovered March 12th exists with every version of the reference client (Bitcoin-Qt, and prior to that WxBitcoin GUI, and bitcoind) prior to v0.8.

I assume that means all previous versions? At what point are older versions no longer usable?

That's the definition of a hard fork.  Old software rejects new blocks which include the incompatible change.
 - http://en.bitcoin.it/wiki/Hardfork_Wishlist

So the moment the fork starts is when any clients not supporting the new rules are no longer supported.

When that does happen how would a user know they should upgrade?

Chances are when the hard fork happens most everyone already would have upgraded.

What that means is that the client released would support both the existing rules and the new rules, with the new rules not taking effect until some future point in time (based on block number).   So essentially if block_number > N then follow the new rules else follow the old rules.

And it would be released well in advance of block N occurring.  [Edit: i.e., two years, according to one core dev:

A hard fork like this would require the intentional support of a majority of merchants.
Short of an emergency, that means everyone will be given at least 2 years to upgrade.

]

[johnyj]

It's cheerful that the roll back to 0.7 decision was made, the other things are not very important right now. The bitcoin's lifeline is hanging on consistency and integrity

Fork is a headache  

[jgarzik]

That is not the full story. There was an INTENTIONAL setting change from 0.7 to 0.8, there is no "bug" ... both version did what they were meant to but they had been made incompatible by this change below ...

https://bitcointalk.org/index.php?topic=140233.msg1619546#msg1619546

https://github.com/bitcoin/bitcoin/commit/ae8bfd12daa802d20791e69d3477e799d2b99f45#src/db.cpp

Code:

82	        -    dbenv.set_lk_max_locks(10000);
83 	  	-    dbenv.set_lk_max_objects(10000);
  	82 	+    dbenv.set_lk_max_locks(40000);
  	83 	+    dbenv.set_lk_max_objects(40000); 

This analysis is incorrect, as noted here when this "discovery" was posted in another thread.