<p>What happened in the March 2013 fork was that two different versions of the bitcoin client disagreed about what a valid block was. You could look for a block reorg, but that will only show up when the fork is fixed. How could you detect a hard fork as soon as it happens?</p>
<p>Well, you could run 5 different versions of the bitcoin client at once, then figure out when they get out of sync for a few minutes. That's when you know there's a version-specific fork. I should note that this is mainly aimed at getting the client fixed faster, not protecting a merchant.</p>
<h2>Detecting being out of sync</h2>
<p>You could write a program that polled all of clients looking for their latest block.</p>
<p>Psuedocode:</p>
<pre><code>run on each node
  block number = node.getblockcount()
  latest block = node.getblockbycount(block number)
  latest block hash = latest block['hash']
</code></pre>
<p>Oh, by the way, this requires the <a href="http://yyz.us/bitcoin/patch.bitcoin-getblock" rel="nofollow noreferrer">getblock patch</a>.</p>
<p>Now, if these differ for more than a minute or so (and you're not still in the initial syncing phase) then you might have a hard fork.</p>
<h2>Making sure you have a good connection to the network</h2>
<p>Let's say that you had a 0.8 client that was only connected to 0.7 clients. Even though it would have accepted the blocks in the March fork, it never even hears about them, meaning we won't detect the fork.</p>
<p>I'm not sure how to solve this. Perhaps upping <code>MAX_OUTBOUND_CONNECTIONS</code> ?</p>
<h2>Preventing false alerts</h2>
<p>If network conditions were really bad, then it's possible that one client would receive a new block, but the others wouldn't. You should use <code>addnode</code> to make them all talk to each other.</p>

CC BY-SA 3.0
2013-03-20T16:55:09.590Z
Is it possible to poll a pool for the pending Tx?  Will most pools allow this?
makerofthings7
CC BY-SA 3.0
2013-03-12T19:57:41.030Z
2013-03-12T19:57:41.030Z
2020-06-16T11:10:03.350Z
Nick ODell
<p><a href="https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119" rel="nofollow">In this post, MoonShadow says</a> it's easy to detect system wide segmentation. </p>

<blockquote>
  <p>Yet a system wide segmentation is fairly easy to detect, the current client just doesn't do it.  If code implementing my 'watchdog' idea were included, the client could be set to suspend automatic trading on websites or warn the user of a fault on interactive clients.</p>
</blockquote>

<p>How would that be accomplished technically speaking?</p>

CC BY-SA 3.0
2013-03-11T10:02:20.613Z
Speifically, a reorg of six or more blocks?
Stephen Gornick
CC BY-SA 3.0
2013-03-12T13:32:06.690Z
Amazing the timing of this question... a few hours after I asked it, there was a chain split with version 0.8 ... how did people detect this?
makerofthings7
CC BY-SA 3.0
2013-04-01T16:30:06.477Z
It was expected some devs had automated methods for learning of it, but it was actually first discovered from users questioning why in their logs the "locks" were not allowing blocks that other nodes (v0.8 clients, it was later discovered) were not having a problem with.  So it was discovered via a manual process.
Stephen Gornick
<network><doublespend><blockchain-fork><march-2013-fork>
How is it possible to detect system wide segmentation?
makerofthings7
# How is it possible to detect system wide segmentation?

(Asked by: username_0 on 2013-03-11)

[In this post, MoonShadow says](https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119) it's easy to detect system wide segmentation.

> Yet a system wide segmentation is fairly easy to detect, the current client just doesn't do it. If code implementing my 'watchdog' idea were included, the client could be set to suspend automatic trading on websites or warn the user of a fault on interactive clients.

How would that be accomplished technically speaking?

**Tags:** network, doublespend, blockchain-fork, march-2013-fork

> **Comments:**
> **username_1**: Speifically, a reorg of six or more blocks?  
> **username_0**: Amazing the timing of this question... a few hours after I asked it, there was a chain split with version 0.8 ... how did people detect this?  
> **username_1**: It was expected some devs had automated methods for learning of it, but it was actually first discovered from users questioning why in their logs the "locks" were not allowing blocks that other nodes (v0.8 clients, it was later discovered) were not having a problem with.  So it was discovered via a manual process.  

---

## 1 answers

### Answer by username_2 on 2013-03-12. Score: 2

What happened in the March 2013 fork was that two different versions of the bitcoin client disagreed about what a valid block was. You could look for a block reorg, but that will only show up when the fork is fixed. How could you detect a hard fork as soon as it happens?

Well, you could run 5 different versions of the bitcoin client at once, then figure out when they get out of sync for a few minutes. That's when you know there's a version-specific fork. I should note that this is mainly aimed at getting the client fixed faster, not protecting a merchant.

## Detecting being out of sync

You could write a program that polled all of clients looking for their latest block.

Psuedocode:

```
run on each node
  block number = node.getblockcount()
  latest block = node.getblockbycount(block number)
  latest block hash = latest block['hash']

```

Oh, by the way, this requires the [getblock patch](http://yyz.us/bitcoin/patch.bitcoin-getblock).

Now, if these differ for more than a minute or so (and you're not still in the initial syncing phase) then you might have a hard fork.

## Making sure you have a good connection to the network

Let's say that you had a 0.8 client that was only connected to 0.7 clients. Even though it would have accepted the blocks in the March fork, it never even hears about them, meaning we won't detect the fork.

I'm not sure how to solve this. Perhaps upping `MAX_OUTBOUND_CONNECTIONS` ?

## Preventing false alerts

If network conditions were really bad, then it's possible that one client would receive a new block, but the others wouldn't. You should use `addnode` to make them all talk to each other.

> **Comments:**
> **username_0**: Is it possible to poll a pool for the pending Tx?  Will most pools allow this?  

---

