Latest bitcoin core?

[therealbtcdave]

I am working on a programming project and there is a version of Bitcoin Core which has functionality I need. Specifically there is a fork of Bitcoin Core v0.13.2 which has address indexing.

The latest version of bitcoin core is 0.15.1 currently so the version I was considering using is a little out of date.

Are there any risks or issues I should be aware of if I was to proceed using the v0.13.2 version?

Thanks

[1713311856]

1713311856

[1713311856]

1713311856

[1713311856]

1713311856

[1713311856]

1713311856

[1713311856]

1713311856

[achow101]

The biggest differences are related to syncing performance, which is going to be significantly worse for you with address indexing enabled. There were also some database changes but that's not really a problem for you.

[gmaxwell]

Old versions are old, they have known reliability and performance issues. 0.13.2 is vulnerable to DOS attacks (plus potentially other security issues, but I don't recall for sure), and it isn't getting updated for other changes so it will far further behind over time.   I would recommend at a minimum that you setup two nodes-- one on current software, one running your special code-- and make the one with the custom code connect only to the current software.  This way it's shielded from abuse that it might not be able to handle and it's easy for you to upgrade the external node.


As an aside, that address index patch that was floating around gave rare false results for me.  I suspect that it could lose entries when there were reorgs, but I'm not sure if that was the cause or something else.

[therealbtcdave]

The biggest differences are related to syncing performance, which is going to be significantly worse for you with address indexing enabled. There were also some database changes but that's not really a problem for you.

There were some database changes, which made this a pain.

I first downloaded the full blockchain using 0.15.1.

I looked more into the 0.15.1 documentation and found this:

Downgrading warning
The chainstate database for this release is not compatible with previous releases, so if you run 0.15 and then decide to switch back to any older version, you will need to run the old release with the -reindex-chainstate option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and processing the entire blockchain.

Old versions are old, they have known reliability and performance issues. 0.13.2 is vulnerable to DOS attacks (plus potentially other security issues, but I don't recall for sure), and it isn't getting updated for other changes so it will far further behind over time.   I would recommend at a minimum that you setup two nodes-- one on current software, one running your special code-- and make the one with the custom code connect only to the current software.  This way it's shielded from abuse that it might not be able to handle and it's easy for you to upgrade the external node.


As an aside, that address index patch that was floating around gave rare false results for me.  I suspect that it could lose entries when there were reorgs, but I'm not sure if that was the cause or something else.

I was going to run two nodes and had setup the addrindex patched node to run on a VM. Due to some disk constraints (speed, capacity) I ended up deciding I would just run the patched addrindex node and use whitebind and whitelist in my bitcoin.conf so nobody but I can connect. You raised a point about vulnerabilities. Do you think the addrindex node is protected if I use whitebind and whitelist?

Also, what about the incorrect results you saw? What did you see and was it from this version: bitcoin-0.13.2-addrindex?

Thanks

[gmaxwell]

I was going to run two nodes and had setup the addrindex patched node to run on a VM. Due to some disk constraints (speed, capacity) I ended up deciding I would just run the patched addrindex node and use whitebind and whitelist in my bitcoin.conf so nobody but I can connect. You raised a point about vulnerabilities. Do you think the addrindex node is protected if I use whitebind and whitelist?

You have to connect to the outside world somehow... you could run your gateway node with pruning, then it would only use about 3GB space or so.

Also, what about the incorrect results you saw? What did you see and was it from this version: bitcoin-0.13.2-addrindex?

Querying it on an address wihch had funds returned no results.  The addrindex code there was written by Pieter as a quick lark, before he realized it was a bad idea and abandoned it.  Other people picked it up and patched it forward but made no effort to improve it or investigate the issues I encountered with it.

Generally it's my expectation that anyone who uses something like addrindex is eventually going to be forced to us a centralized service provider like blockchain.info once the resource costs of an unpruned address indexed full node is beyond what they can support.  (The fact that you struggled with running two nodes suggests that you're within a factor of two of that already).

[therealbtcdave]

I was going to run two nodes and had setup the addrindex patched node to run on a VM. Due to some disk constraints (speed, capacity) I ended up deciding I would just run the patched addrindex node and use whitebind and whitelist in my bitcoin.conf so nobody but I can connect. You raised a point about vulnerabilities. Do you think the addrindex node is protected if I use whitebind and whitelist?

You have to connect to the outside world somehow... you could run your gateway node with pruning, then it would only use about 3GB space or so.

Also, what about the incorrect results you saw? What did you see and was it from this version: bitcoin-0.13.2-addrindex?

Querying it on an address wihch had funds returned no results.  The addrindex code there was written by Pieter as a quick lark, before he realized it was a bad idea and abandoned it.  Other people picked it up and patched it forward but made no effort to improve it or investigate the issues I encountered with it.

Generally it's my expectation that anyone who uses something like addrindex is eventually going to be forced to us a centralized service provider like blockchain.info once the resource costs of an unpruned address indexed full node is beyond what they can support.  (The fact that you struggled with running two nodes suggests that you're within a factor of two of that already).

Interesting. I will know in a couple hours after bitcoin core is done processing blocks on disk if 0.13.2-addrindex returns the correct balance or not. I sure hope it does or my efforts this far have been a waste of time. Also, thanks for that history, I was not aware of Pieter's contribution and the background of this bitcoin core patch.

Running the nodes is not so much a struggle, its just that I want results now and have been trying a few different configurations.

First off in my journey here I ran the latest bitcoin core 0.15.1 and after 2 or 3 days I had the full blockchain. Played around with some of the RPC calls but found even with that I still can't get the information I needed.

So I did some research and found out about 0.13.2-addrindex. One real fucking pain has been that 0.13.2-addrindex and 0.15.1 have different database versions. Getting the full blockchain I downloaded to work with 0.13.2-addrindex was not a struggle but a time consuming process and I am impatient and want results NOW!

So I've finally got 0.13.2-addrindex on what I think are the last stages. I rebuilt the blockchain so it would work with this version. And configured the bitcoin.conf to enable the address indexing. It took forever for the build indexes on disk step. Finally its been processing blocks on disk and is close to completion.

If this doesn't work out I am going to look into porting NBitcoin.Indexer (github.com/MetacoSA/NBitcoin.Indexer) to use local filesystem storage instead of Azure or look into using NBXplorer (github.com/dgarage/NBXplorer)

So yeah. Hopefully this works out. If not you can see I've got a plan B and C already