<p>This is not trivial, have you thought about chain reorgs?</p>

<p>This is a client side phenomenon, depending on who you're connected to in the P2P network. If there's a race between two miners - they publish two blocks, A and B, at the same time, some people will believe one or the other. Eventually one of the chains will be elongated making it the longest and valid chain. We'll say that B was added to. Any tx's in A would no longer be valid, so your app needs to deal with this, and not show duplicate transactions.</p>

<p>I'm not entirely sure on the behavior from the client either - if a reorg is 3 blocks deep, does it issue callbacks (blocknotify) on all 3 new blocks? Or just the highest, best block? Maybe you need to recurse backwards from the latest block every time until you find a parent block you've already encountered?</p>

<p>Scaling is an issue here - I've started down this path before and you need to try reduce the number of queries you make over the RPC. Try decoding transactions using <a href="https://github.com/Bit-Wasp/bitcoin-lib-php" rel="nofollow">https://github.com/Bit-Wasp/bitcoin-lib-php</a> instead of using the RPC, maybe that'll help. </p>

CC BY-SA 3.0
2014-08-08T19:45:46.220Z
2014-08-08T19:45:46.220Z
karimkorun
<p>You can't use jsonRPC to do this, because jsonRPC commands like gettransaction only work for wallet addresses you have in your wallet.  They don't work for arbitrary addresses.</p>

<p>Sites like blockchain.info basically read the physical blockchain files, not using jsonRPC.  You could do something similar.  I've heard that <a href="https://code.google.com/p/bitcoinj/" rel="nofollow">bitcoinj</a> may do what you want, but I've never used that library.  You also want to check into <a href="https://blog.bitpay.com/introducing-bitcore/" rel="nofollow">Bitcore</a> from BitPay.</p>

CC BY-SA 3.0
2014-03-18T21:50:22.643Z
The Bitcore project looks fantastic and is exactly what I think we can use. Thanks much - I can't upvote I do not have enough but I accepted the answer.
6paq
CC BY-SA 3.0
2014-03-18T21:33:37.893Z
2016-07-21T06:41:37.183Z
2016-07-21T06:41:37.183Z
ChrisW
<p>How can I use the jsonRPC for the bitcoin client to export the chain into mysql and then sync the two as transactions come in? I'm writing a blockchain explorer for a new alt coin and unfortunately ABE won't work for this particular coin. I can query the chain using jsonRPC just fine for each transaction but I want to be able to store the chain in mySQL for speed and efficiency later on. </p>

<p>Preferred technologies: php &amp; mysql.</p>

<json-rpc>
Store bitcoin transactions in mysql
6paq
# Store bitcoin transactions in mysql

(Asked by: username_0 on 2014-03-18)

How can I use the jsonRPC for the bitcoin client to export the chain into mysql and then sync the two as transactions come in? I'm writing a blockchain explorer for a new alt coin and unfortunately ABE won't work for this particular coin. I can query the chain using jsonRPC just fine for each transaction but I want to be able to store the chain in mySQL for speed and efficiency later on.

Preferred technologies: php & mysql.

**Tags:** json-rpc


---

## 2 answers

### Answer by username_2 on 2014-03-18. Score: 4 | Accepted answer

You can't use jsonRPC to do this, because jsonRPC commands like gettransaction only work for wallet addresses you have in your wallet. They don't work for arbitrary addresses.

Sites like blockchain.info basically read the physical blockchain files, not using jsonRPC. You could do something similar. I've heard that [bitcoinj](https://code.google.com/p/bitcoinj/) may do what you want, but I've never used that library. You also want to check into [Bitcore](https://blog.bitpay.com/introducing-bitcore/) from BitPay.

> **Comments:**
> **username_0**: The Bitcore project looks fantastic and is exactly what I think we can use. Thanks much - I can't upvote I do not have enough but I accepted the answer.  

---

### Answer by username_1 on 2014-08-08. Score: 0

This is not trivial, have you thought about chain reorgs?

This is a client side phenomenon, depending on who you're connected to in the P2P network. If there's a race between two miners - they publish two blocks, A and B, at the same time, some people will believe one or the other. Eventually one of the chains will be elongated making it the longest and valid chain. We'll say that B was added to. Any tx's in A would no longer be valid, so your app needs to deal with this, and not show duplicate transactions.

I'm not entirely sure on the behavior from the client either - if a reorg is 3 blocks deep, does it issue callbacks (blocknotify) on all 3 new blocks? Or just the highest, best block? Maybe you need to recurse backwards from the latest block every time until you find a parent block you've already encountered?

Scaling is an issue here - I've started down this path before and you need to try reduce the number of queries you make over the RPC. Try decoding transactions using <https://github.com/Bit-Wasp/bitcoin-lib-php> instead of using the RPC, maybe that'll help.


---

