Why the hell this shit was not tested on testnet?

[speeder]

Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).

What the hell are the devs thinking? What is the testnet for? Testnet is not only to test userland code, but it is a fine place to test mining code too damnit!

Now know that from now on, you should ALWAYS test stuff like this on Testnet first.

[1715114960]

1715114960

[1715114960]

1715114960

[kokojie]

Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).

What the hell are the devs thinking? What is the testnet for? Testnet is not only to test userland code, but it is a fine place to test mining code too damnit!

Now know that from now on, you should ALWAYS test stuff like this on Testnet first.

I assume this has something to do with the kind of worrying "Critical: Current Bitcoin network fork. Action needed by mining pools. Merchants should hold transactions.".

Are my bitcoins worthless now?

Some people are reporting missing coins from very recent transactions, you better check your wallet to make sure.

[justusranvier]

Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).

The problem is older than you think. 0.8 is fine (at least with regards to the current problem). 0.7 had a bug in it and consequently is not capable of handling what it's supposed to be able to handle.

[dree12]

Ironically, more testing on testnet would not have helped this issue. Significantly less may have, as the network would have more time to upgrade.

I think the blame rests upon miners and merchants here. Miners should always upgrade and merchants should run FAN nodes.

[solex]

Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).

What the hell are the devs thinking? What is the testnet for? Testnet is not only to test userland code, but it is a fine place to test mining code too damnit!

Now know that from now on, you should ALWAYS test stuff like this on Testnet first.

Core Dev are always having to maintain the engines on a jet aeroplane flying at 35,000 feet. I don't notice any oil on your hands!

[justusranvier]

Ironically, more testing on testnet would not have helped this issue. Significantly less may have, as the network would have more time to upgrade.

This might have helped:

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

[JoelKatz]

Are my bitcoins worthless now?

If you've had bitcoins sitting in a wallet since before this happened, they are safe. Just don't do anything with them until the problem is resolved.

[Nemesis]

I wonder where Gavin is?

Did he make any statement? I dont see him posting comments in the sticky thread.

[justusranvier]

I wonder where Gavin is?

Did he make any statement? I dont see him posting comments in the sticky thread.

Probably has more important coding-related things to do right now.

[pera]

Seriously, you made TWO major changes at once (block size and database type) at once... And deployed in production and partially only (because not all people upgraded).

The problem is older than you think. 0.8 is fine (at least with regards to the current problem). 0.7 had a bug in it and consequently is not capable of handling what it's supposed to be able to handle.

incompatibility between versions should be called (at least) an issue imho...

[justusranvier]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

[gst]

What the hell are the devs thinking? What is the testnet for? Testnet is not only to test userland code, but it is a fine place to test mining code too damnit!

So are you paying the devs for developing the Bitcoin software? And why didn't YOU test the code in testnet before it was released as 0.8?

[dree12]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.

[pyra-proxy]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.

Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for.  What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site.

[n8rwJeTt8TrrLKPa55eU]

Core Dev are always having to maintain the engines on a jet aeroplane flying at 35,000 feet. I don't notice any oil on your hands!

Yep.  Backseat driving is rampant on this forum.  We have geniuses coming out of the woodwork who demand Bitcoin developers be exempted from fundamental laws of mathematics and produce 100% perfect software.  

Hint: look up "Halting Problem".

There will be bugs.  Always.  Either contribute to the testing & development cycle with your time or money, or stop complaining.

[markm]

Running all versions that are not totally obsolete on testnet at same time as running new version on it might have caught this, maybe?

Sure only running the new version on testnet without any old versions there would not test their compatibility.

-MarkM-

[dree12]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.

Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for.  What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site.

The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen?

[solex]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.

Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for.  What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site.

The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen?

A block rejected by all nodes is by definition invalid. Someone will produce a new valid one, and the building will continue as normal.

[dree12]

incompatibility between versions should be called (at least) an issue imho...

My point was that exhaustive testing of 0.8 would never have revealed the bug in 0.7 that nobody knew about.

Unit testing to make sure the code was actually capable of operating at the protocol limits would have caught the problem had it been performed on 0.7

Indeed, the testing should have been conducted in the three years since Bitcoin was released. It's appalling how the edge conditions were never tested.

Not sure backward compatibility is an edge case.... generally its a big deal you plan a transition for.  What happened here was a rushed satoshi dice bailout with much discussion on filtering out their transactions while a real solution could be worked on.... which now leaves everyone feeling the pain instead of a single entertainment site.

The edge condition is referring to the blocks that were rejected even before 0.8 was released. A perfectly valid block could be rejected by every Bitcoin node. Isn't this something that should never happen?

A block rejected by all nodes is by definition invalid. Someone wil produce a new valid one, and the building will continue as normal.

Is there any evidence that all nodes would reject it? It looks like, according to Pieter's preliminary statement, that certain configurations will (correctly) accept the blocks.

Immediate solution is upgrading to 0.8, or manually setting the number of
lock objects higher in your database. I'll follow up with more concrete
instructions.

[markm]

Different versions and distros of operating systems likely linked against different versions of Berkeley DataBase too so maybe it would have needed each old version of bitcoin, with each compatible version of the BDB linked to each one, to have found this just by running on testnet.

Edge case unit tests though should be looking for precisely the corner and limit cases of numbers of transaction, portions of transactions, number and type of script and sigs, size of blocks and so on.

Its just the unit tests are not really fleshed out fully yet.

Maybe they need to include trying linking to different versions of whatever database library is being used.

-MarkM-