Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reuse Bitcoin synced blockchain for Bitcoin Gold #173

Closed
DarthJahus opened this issue Nov 12, 2017 · 17 comments
Closed

Reuse Bitcoin synced blockchain for Bitcoin Gold #173

DarthJahus opened this issue Nov 12, 2017 · 17 comments

Comments

@DarthJahus
Copy link

Since Bitcoin Gold is a fork of Bitcoin and of its blockchain, is there a way, if we have already synced Bitcoin BTC, to reuse that block info to bootstrap Bitcoin Gold blockchain sync process?

Questions from here and here.

@liuxurong
Copy link

liuxurong commented Nov 12, 2017

I am disappointed that the BTG team did not consider this problem, and now the client is in slow sync.

@tomix1024
Copy link

tomix1024 commented Nov 12, 2017

Does not work for me.
Let's hope that we can at least hardlink the common blocks in retrospect...

@c0deright
Copy link

You can NOT reuse anything from .bitcoin directory. Please see #64

@rosmo01
Copy link

rosmo01 commented Nov 13, 2017

In related thread @h4x3rotab states"However you can connect your Bitcoin Gold client to a Bitcoin Core client to sync from it locally."

In theory it should be like connecting any node with fully synced chain...?

Apparently not at all for BTG.....

I have added via conf and console, but BTG node always connects to internet and ignores nodes in LAN.

BTG node also ignores node even if on same host and I disconnect host from internet, the local Bitcoin node is ignored.

Disconnecting or banning all internet nodes will also not connect to the locak Bitcoin node. It seems this fork is intentionally forcing full blockchain from internet, effectively making it one of the worst forks I've come across.

Has anyone achieved a full sync to the blockchain through a local BTC host?

@rosmo01
Copy link

rosmo01 commented Nov 13, 2017

Using "bitcoin-q -connect=LAN IP" will ensure there is no connection to internet, but also does not connect to the specified IP. No sign of it in debug.log or in the Peers view.

It appears to me that BTG is unable to connect to a BTC node as it is hardcoded which port to connect to, and BTC core does not respond on expected port - yet that should have been logged in debug.log, but is not. So please disclose how to sync with LAN BTC node @h4x3rotab .

@tomix1024
Copy link

tomix1024 commented Nov 13, 2017

Have a look at these three lines of code:
https://github.com/BTCGPU/BTCGPU/blob/master/src/net.cpp#L1824
Just comment them out and you should be able to connect to your local instance of Bitcoin.

I am not sure what the intended behaviour of this piece of code is...

Also use bitcoin-qt -bootstrap to enable standard bitcoin port.

@rosmo01
Copy link

rosmo01 commented Nov 13, 2017

First and foremost this fork has chosen to not follow best practices in regards to the migration process from BTC to BTG chain. This would perhaps not have been a problem when the chain was tiny, but to not have a mechanism in the software that ensures migration/conversion from a local chain is really rather unprofessional and working against wider acceptance, and has as we have seen created a lot of tension since launch as so many were unable to achieve a full BTG chain as they had to download 150GB, instead of utilizing local BTC.

Now you suggest that we comment out lines of code and recompile to achieve a local sync!

I really can't believe what you're saying.

It is you and the dev team that should release a version with the proper mechanism to ensure the large BTC community can utilize their local BTC chain as they have done for BCH and thus also get a larger node base to support BTG.

@tomix1024
Copy link

@rosmo01, I totally agree with you.
I don't understand why they had to fork the BTC chain if you have to redownload it anyways.
Staring with an empty chain would have probably been the cleaner solution.

I can't believe that either, but the steps I described made the process work for me.
I am otherwise not involved with the BTG development...

@c0deright
Copy link

c0deright commented Nov 13, 2017

try -connect=IP:8333 instead of -connect=IP and try adding -bootstrap

@rosmo01
Copy link

rosmo01 commented Nov 13, 2017

@tomix1024 - my problem is it's a long while since I had any compilers or did any coding, so I need list of what I need to do in order to compile on Windows x64 (7 or 10), as I would like to at least test and get it out of the way as a solution or not, as I think the dev team will not deal with this in a long while...

@rosmo01
Copy link

rosmo01 commented Nov 13, 2017

@c0deright tested all formats, and makes no difference as it seems to be hard-coded which was confirmed by tomix1024.

My question to you, though, is how did you sync blockchain with LAN node?

@c0deright
Copy link

c0deright commented Nov 13, 2017

I did not sync from a Core LAN node. I had one node sync from the internet with an older btcgpu git version days ago. This node synced until one block before the fork block. Today I installed the release version and resumed block download with the fork block and all the ones thereafter.

@tomix1024
Copy link

Okay, if editing the code is no option for you, and this piece of code is indeed the problem, then another workaround would be to wait for 50 failed connection attempts.
Then it will not skip the wrong port numbers.

At least that is what should happen.

But maybe some of the devs will have a look and fix this issue soon.

@rosmo01
Copy link

rosmo01 commented Nov 14, 2017

Fortunately this did work, even on same host as BTG:
bitcoin-qt -bootstrap -connect=LANIP:8333 which is rather interesting, as none of the other ways to assign BTC node (conf, addnode, etc) was picked up by the BTG node.

This is a also interesting in regards to the code pointed out by tomix1024, but I'm glad I don't have to compile, although the Windows subsystem for Linux on my Win10 notebook is downloading the final binaries and is almost ready to compile now :-)

Thanks for your input @tomix1024 @c0deright !

@jagottsicher
Copy link
Contributor

jagottsicher commented Nov 14, 2017

I followed @tomix1024 hint and removed the line.
of course I use -bootstrap all the time, but still at around 50% the Client stops validating blocks suddenly.
Restart does not work, respectively no new blocks are validated.
it seems to be a thing of luck, if you receive the whole chain or not.

sources from gold nodes do not provide any data!

Problem seems to be that the validation stops, not receiving the data.

Trying for 2 days now, but it is not possible to download and validate the chain to a reasonable height that the algo is switched to equichash.

@almightyruler
Copy link

I've had the same problem, and I'm also confused why the Bitcoin Gold devs would think it was a good idea to force users to re-download 100GB+ worth of data that many of us would already have locally.

If you can compile from source, you can hack chainparams.cpp to (temporarily) change the message start bytes back to Bitcoin Core:

pchMessageStart[0] = 0xf9;
pchMessageStart[1] = 0xbe;
pchMessageStart[2] = 0xb4;
pchMessageStart[3] = 0xd9;
nDefaultPort = 8333;

Bitcoin Gold uses a different message start sequence, so even if you do manage to connect to a Bitcoin Core client, they will never communicate with each other. This temporary change lets your Bitcoin Gold client pretend to be a Bitcoin Core client. Remember you must change back once you reach the fork point, in order to continue on the Bitcoin Gold network.

@h4x3rotab
Copy link
Member

It's non-trivial to allow BTG client to share the same block history file with Bitcoin Core. Back to the early stage, there's a command line flag called "bootstrap" which allow to download the block history from Bitcoin Core clients. This flag was removed because it will make peer management complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants