In order to do so I had to clone the git repository, checkout the “version3” branch, delete all of the checkpoints other than genesis from bn.cfg, and run the install.sh script to compile the node and its dependencies. Libbitcoin Node wasn’t too bad - the hardest part was removing the hardcoded block checkpoints. Expect version 4.0 to be much faster due to implementing headers-first sync.- Jameson Lopp November 5, 2018 Requires manually removing checkpoints from the code & recompiling for full validation. My nf: checkpoints=falseĪlong with: export NODE_OPTIONS= - max_old_space_size=16000įull validation sync of Libbitcoin Node 3.2.0 took my machine 20 hours, 24 minutes with a 100,000 UTXO cache. I ended up filing several github issues and had to try syncing about a dozen different times before I found the right parameters that wouldn’t cause the NodeJS process to blow heap and crash. I have regularly run Bcoin nodes but I haven’t spent a lot of time messing with the configuration options, nor had I ever tried a full validation sync. ![]() NodeJS default heap size of 1.7GB causes lots of issues, is hard to work around.- Jameson Lopp November 3, 2018īcoin took a lot more work. ![]() If you try to allocate more than 1GB to the UTXO cache, you're gonna have a bad time. My nf: assumevalid=0įull validation sync of 1.0.2 with 1GB UTXO cache finished in 27 hours, 32 minutes. Testing Bitcoin Core was straightforward - I just needed to add the assumevalid parameter. It took 311 minutes to sync Bitcoin Core 0.17 from genesis with assumevalid=0 on this machine bottlenecked on CPU most of the time from what I could tell.- Jameson Lopp October 24, 2018 This is done under the assumption that if a year or more of proof of work has accumulated on top of those blocks, it’s highly unlikely that you are being fed fraudulent signatures that no one else has verified, and if you are then something is incredibly wrong and the security assumptions underlying the system are likely compromised. As a performance improvement, most of them don’t validate signatures before a certain point in time, usually a year or two ago. Note that no Bitcoin implementation strictly fully validates the entire chain history by default. When I ran another sync in October I was asked to test the performance when running the non-default full validation of all signatures. I ran a few syncs back in February but nothing comprehensive across different implementations. QOvuwPgCgy- Jameson Lopp February 11, 2018 Next step: see how much traffic I can serve on gigabit fiber. Synced Bitcoin Core 0.15.1 (w/maxed out dbcache) in 162 min w/peak speeds of 80 MB/s. Just set up a maxed out PC on PureOS 8.0. I bought this PC at the beginning of 2018. ![]() We learned that syncing Bitcoin Core from scratch on one can take weeks or months (which is why we ship Casa Nodes with the blockchain pre-synced). We’ve also run tests on less high-end hardware such as the Raspberry Pi, the board we use in our plug-and-play Casa Node for Lightning and Bitcoin. I wanted to see what the latest generation SSDs were capable of doing, since syncing nodes tend to be very disk I/O intensive. The computer I chose to use as a baseline is high-end but uses off-the-shelf hardware. But are all node implementations equal when it comes to performance? I had my doubts, so I ran a series of tests. Testing full sync of five Bitcoin node implementations.Īs I’ve noted many times in the past, running a fully validating node gives you the strongest security model and privacy model that is available to Bitcoin users.
0 Comments
Leave a Reply. |