-
Notifications
You must be signed in to change notification settings - Fork 334
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
Comments
I am disappointed that the BTG team did not consider this problem, and now the client is in slow sync. |
Does not work for me. |
You can NOT reuse anything from .bitcoin directory. Please see #64 |
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? |
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 . |
Have a look at these three lines of code: I am not sure what the intended behaviour of this piece of code is... Also use |
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. |
@rosmo01, I totally agree with you. I can't believe that either, but the steps I described made the process work for me. |
try |
@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... |
@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? |
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. |
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. At least that is what should happen. But maybe some of the devs will have a look and fix this issue soon. |
Fortunately this did work, even on same host as BTG: 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 ! |
I followed @tomix1024 hint and removed the line. 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. |
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; 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: