<p>Maybe you can arrange it such that a refund always uses the TxOut of the transaction with which it came into the cold storage? Basically giving the user the same bitcoins back.</p>

<p>If a fork causes the funds not to go into cold storage they will not be going out either.</p>

CC BY-SA 3.0
2014-04-15T17:26:14.450Z
2014-04-15T17:26:14.450Z
Jannes
<p>Use:</p>

<p><code>bitcoin-cli</code><a href="https://bitcoin.org/en/developer-reference#getchaintips" rel="nofollow"><code>getchaintips</code></a>.</p>

CC BY-SA 3.0
2015-10-24T22:41:50.107Z
2015-10-24T22:41:50.107Z
Geremia
<p>What's the most efficient way to detect a fork in the blockchain?</p>

<p>My app polls for changes to user deposit addresses on each new block.</p>

<p>Deposits are credited to user accounts with a record in a database then the funds are transfered to cold storage.</p>

<p>When users get refunds those refunds come from the cold storage and a record is added to the database.</p>

<p>My concern is the following happening:</p>

<ul>
<li>User deposits Btc and the database record is created.</li>
<li>Chain is forked from 51% attack or software incompatability.</li>
<li>User gets refund from cold storage but I no longer have access to the funds they sent so its out of my pocket.</li>
</ul>

<p>It seems that everything but rechecking every deposit is marginally risky.</p>

<p>If I rely on height plus hash that can be manufactured by the attacker so the new chain looks like the old chain.</p>

CC BY-SA 3.0
2014-04-15T15:04:33.840Z
I'm not completely sure what you have in mind when you say "height plus hash". But note that a different fork of the chain will necessarily have different blocks with different hashes. (Unless the attacker has managed to break sha256, in which case we all have bigger problems anyway.)
Nate Eldredge
<blockchain-fork>
Detecting fork using bitcoind
Aaron
# Detecting fork using bitcoind

(Asked by: username_0 on 2014-04-15)

What's the most efficient way to detect a fork in the blockchain?

My app polls for changes to user deposit addresses on each new block.

Deposits are credited to user accounts with a record in a database then the funds are transfered to cold storage.

When users get refunds those refunds come from the cold storage and a record is added to the database.

My concern is the following happening:

* User deposits Btc and the database record is created.
* Chain is forked from 51% attack or software incompatability.
* User gets refund from cold storage but I no longer have access to the funds they sent so its out of my pocket.

It seems that everything but rechecking every deposit is marginally risky.

If I rely on height plus hash that can be manufactured by the attacker so the new chain looks like the old chain.

**Tags:** blockchain-fork

> **Comments:**
> **username_1**: I'm not completely sure what you have in mind when you say "height plus hash". But note that a different fork of the chain will necessarily have different blocks with different hashes. (Unless the attacker has managed to break sha256, in which case we all have bigger problems anyway.)  

---

## 2 answers

### Answer by username_2 on 2014-04-15. Score: 2

Maybe you can arrange it such that a refund always uses the TxOut of the transaction with which it came into the cold storage? Basically giving the user the same bitcoins back.

If a fork causes the funds not to go into cold storage they will not be going out either.


---

### Answer by username_3 on 2015-10-24. Score: 1

Use:

`bitcoin-cli`[`getchaintips`](https://bitcoin.org/en/developer-reference#getchaintips).


---

