Quote from: taltamir on March 13, 2013, 09:49:30 PM

What needs to happen is that 0.8.1 should be released where its the same as 0.8 only it changes the default CONFIGURATION such that it will NOT create 0.7- incompatible blocks.
When over 90% of the network are using 0.8+ this limitation can be safely removed and people using 0.7 or earlier will be forced to upgrade.

Until such a hypothetical 0.8.1 is released you can MANUALLY apply the needed configuration files using the instructions in:
https://bitcointalk.org/index.php?topic=152030.msg1620853#msg1620853

No, the point of the big mining pools switching to non-upgraded 0.7 was to act as the lowest common denominator so that more than 51% of the hash power will (mostly) reject the same valid blocks that the other non-upgraded 0.7 users and merchants. As close as it can be done, that is.

Quoting what I said above: "Upgrade" includes upgrading their bitcoind/bitcoin-qt etc to 0.8+ OR setting the DB_CONFIG entries mentioned above.

Releasing a 0.8.1 won't fix anything. All that it can do is clamp the value that you can set the max generated block size to. The problem is the code is still there, and so is 0.8. If somebody wants to compile a custom 0.8.1 from source with the limit at 1MB, they can.

If a person (or a pool) wanted to cause trouble, they could simply change the code in their 0.8.1 checkout and compile, or use 0.8. Of course they need to be able to solo-mine their own blocks. Generating a block that's complex enough to overflow the lock tables of old 0.7 bdb based systems is still valid. If more than 51% of the hash power applies the DB_CONFIG fixes (even on 0.7) then they'll accept it and build on it.

What actually needs to happen is a new fixed 0.6.x, 0.7.x need to come out, and the people who can't/won't go to 0.8.x need to pick up one of those instead. Or do the DB_CONFIG fixes. But more than 51% of the hash power has to stay behind until a good 90%+ of nodes have been upgraded. Because sooner or later somebody will generate one bdb-breaker on purpose.

To repeat, by "upgraded", I mean either switching to 0.8.x or applying the DB_CONFIG changes, or switching to a new 0.6.x or 0.7.x with the bdb changes.

Releasing 0.8.1 won't fix the vulnerable 0.3 / 0.6 / 0.7 nodes. The moment somebody uses a a couple of avalons to feed a custom patched 0.8 in order to deliberately make a bdb-breaker block we'll be in the same mess again unless there is > 51% of the hash power on un-fixed 0.7 to cause the bdb-breaker block to be orphaned.

The moment somebody figures out a financial angle to exploit this, it'll happen. eg: a replay of the OKPAY double spend etc.

Anyway, the pool operators have this covered. The only reason I said anything at all was somehow end users are getting the idea they need to downgrade. They should not.
If they're on 0.8, they should stay on 0.8.
If they're on 0.7 or earlier they EITHER need to fix their DB_CONFIG; or get a fixed 0.7.x when it comes out; or upgrade to 0.8.
If they're running mining software as part of a pool then the bitcoind they're running doesn't matter - they still need the fixed one.
Merchants particularly have to pay attention.

The only people that should be downgrading are pool operators or large solo miners.