Make the client continuosly check for split chains or blocks it thinks are inval

[Killdozer]

I am not too worried about the recent events themselves, I don't think they display any major flaw in Bitcoin.
The events happened due to a bug in another library, these things will happen eventually. Since bitcoin is software, there WILL be unforseeable bugs, if you know that Bitcoin is a piece of machine code and are using it, you basically accept it already.

But the problem is getting warned about these things as fast as possible.
It seems that a lot of bugs can cause the chain split, as well other events, for example failure to update in time, or simply not hearing some important news.
That's why it is very important that people that are left behind will always get a warning.
It seems that a lot of these problems can be indicated if the software had a warning system for when it sees two different chains available (perhaps longer than X (6? 10? 20?) blocks).

According to some topics, for example LukeJr has a system like this already in place, however it involved external checks made possible by running multiple versions of the client.

What we need is for the standard client to constantly check for this situation and warning the user if it happens. It would be very good as a (optional!) setting to also make it possible to shut down until manual inspection option, if the situation arises. Since the bitcoin client is integrated with a lot of other software, it would be good to have support for this check even in the jsonrpc-communication which the client supports.

Thoughts?

[Spaceman_Spiff]

I am not too worried about the recent events themselves, I don't think they display any major flaw in Bitcoin.
The events happened due to a bug in another library, these things will happen eventually. Since bitcoin is software, there WILL be unforseeable bugs, if you know that Bitcoin is a piece of machine code and are using it, you basically accept it already.

But the problem is getting warned about these things as fast as possible.
It seems that a lot of bugs can cause the chain split, as well other events, for example failure to update in time, or simply not hearing some important news.
That's why it is very important that people that are left behind will always get a warning.
It seems that a lot of these problems can be indicated if the software had a warning system for when it sees two different chains available (perhaps longer than X (6? 10? 20?) blocks).

According to some topics, for example LukeJr has a system like this already in place, however it involved external checks made possible by running multiple versions of the client.

What we need is for the standard client to constantly check for this situation and warning the user if it happens. It would be very good as a setting to also make it possible to shut down until manual inspection option, if the situation arises. Since the bitcoin client is integrated with a lot of other software, it would be good to have support for this check even in the jsonrpc-communication which the client supports.

Thoughts?

I agree that fast signalling in case of an error seems like a very good idea.  That way merchants won't accept bad payments.  The "shutdown until manual inspection" should definitely be optional, otherwise it might become another way to harass merchants and the network.
A similar service outside of the client seems like a good idea too, sending out tweets, emails, text messages (paying service?), etc.  when a problem arises.

[Sukrim]

What we need is for the standard client to constantly check for this situation and warning the user if it happens. It would be very good as a (optional!) setting to also make it possible to shut down until manual inspection option, if the situation arises.

This already exists... https://github.com/bitcoin/bitcoin/blob/1a9ee5da327d8079a297ad292a1c16745b75df91/src/main.cpp#L2941

[Killdozer]

Did this catch the 0.7 not accepting blocks from 2 days ago? I didn't run the client at the time so I don't know.
It seems like it should, unless that block (and ones built on top of it) are completely rejected and forgotten by the client.
Then it's just a matter of the optional shutdown of operation when this alert is issued, if any merchants wants this.

[Sukrim]

As far as I understood it, the forks were not very far apart (~60% of hashing power on the 0.8 fork) so probably Gavin's alert was published to the net before this could take effect.

Anyways, I guess someone else who actually was online/awake at that time can say more to this.

[dree12]

As far as I understood it, the forks were not very far apart (~60% of hashing power on the 0.8 fork) so probably Gavin's alert was published to the net before this could take effect.

Anyways, I guess someone else who actually was online/awake at that time can say more to this.

It took effect, but only on the 0.7 nodes that did not need to downgrade. This was because 0.8 nodes only noticed a shorter, also valid chain, which is not unusual as orphans happen often. 0.7 nodes noticed a longer but invalid chain and displayed the notice.

[xcsler]

Are there other data points that could be monitored?

I'm not a programmer but reading through the transcript http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 at 23:36 just before the fork was discovered Canar questioned whether 4000 unconfirmed transactions was normal.

Are 4000 unconfirmed txs abnormal and something that could be monitored for forks...or am I way off base?

[Killdozer]

1. Even if some number of unconfirmed transactions can be an indicator, the number itself must be made dynamic, since obviously, this changes with time as the network grows. For example the client could compare the current number of unconfirmed transactions to the average number of transactions in a block, for 20 last blocks or similar. (And even then the block times variance can create problems.)
2. Shouldn't the last situation have produced only normal number of unconfirmed transactions? There were two chains, but since there was mining going on in both of them, transactions should have been confirmed in both chains?
3. Based on the latest number of transactions in blocks, according to blockchain.info, 4000 sounds like quite a lot, approx. 10 times more that it should be. Don't really know the reason then...

[dree12]

2. Shouldn't the last situation have produced only normal number of unconfirmed transactions? There were two chains, but since there was mining going on in both of them, transactions should have been confirmed in both chains?

The two chains split the hashrate, making blocktime longer. The 0.7 chain was at ~15% of total hashrate and so would have had ~7 times the regular amount of unconfirmed transactions.