I don’t usually write opinion pieces or get involved in popular debates like when everyone had an opinion on the preferences of hypothetical pants wearing dogs. But I just couldn’t help myself to this opportunity to do something so revolutionary in this space … something so unique, so forward looking, so ground breaking.
Today, I proudly present to the reader: An original article, however tangential to the popular contemporary theme of Bitcoin Capacity Increases, that I promise, is not in any way about the f&!k&%g block size debate 😛
How long does it take a new Bitcoin full node to sync to the blockchain? Does the recently merged libsecp256k1 speed up the sync?
These are good questions, so I wrote a small script that gives us some data about the sync time of the new release candidate, whose new optimized library for elliptic curve operations has been rumored to give up to a “700%” increase in the speed of verifying transactions.
So let’s benchmark bitcoin-core with the new libsecp256k1 to see this speedup ourselves. Here is a script for making a log and getting a birds eye view of the sync process. Spoilers: it was really, really fast.
This is the kind of thing I always thought about doing, but never did. It’s a simple thing to do, however it just takes time to write up a useful albeit simple script to give you the data you want. Not only that, but previously, when syncs were taking days to complete, this sort of test would eat up my machine.
Since I have been involved with bitcoin, I have known the user base to be (I love you guys) …well, prone to getting carried about with the fear of an impending doom of the BTC — especially if the inevitable doom will be brought upon by some physical limitations of the client, its capacity, and scalability.
In fact, back in 2012-2013, the total size of the blockchain was really all the rage, and the buzzword of the times was “blockchain pruning”. This involved lot of media focus on this problem, as well as efforts by developers and theorists alike to put forth a concerted effort to find a method for reduction of the very scary, problematic growth rate of the block chain!
That’s right everyone was talking about the block chain being too large on disk already, and growing too fast. How bloody ironic, eh. I won’t say it. Don’t even say it!
Over time I have built up a thick skin for these sorts of mobs of fear and uncertainty. I just keep using my coins and really tend to take the doomsday scenarios with less than a grain of salt, because I have seen bitcoin overcome obstacle after obstacle, so many times that it becomes almost illogical to be anything but calm through it all, and feel as though we are in good hands with the devlopers (we are).
But node sync time has been a subtle concern to me for many months – not because I read it on www.scary-bitcoin-news.ninja, but because I noticed this sync time change over a long period of time and become a real hassle to me and running my node as a casual.
In early 2013, it took “pretty damn long” to bootstrap a new node. But I was able to run a full node that year, all year, on a mid level laptop, that I would wipe and re sync every few months. But by the end of 2014 I was no longer running the laptop node and noticed long sync times on my main high performance monster of a desktop. I felt it took so much longer in fact, that I considered not even running the node, which would have really sucked for me, and put a big damper in the way I got used to used bitcoin. By the end of 2015 I was just trying to avoid a fresh node sync at all costs, which is hard as a man who re-installs his OS every few months. The sync would, on either of my computers, take between 36 and 96 hours for me, depending on how uninterrupted I could run the process and the state of my internet service, and other variables.
It dawned on me at some point that if I was dreading a sync, I couldn’t have been the only one. And so I did consider whether node sync time was a real deterrent to running a node.
However I decided to go for it because I thought if the figures I heard are true, and this library gives a significant speedup, it might require less than a day. And when I inquired in the IRC channel, I was told “could be as fast as 4 hours.” Hot damn – this I had to so. So I finally did it. Result: Sp happy! It finished in a blazing 4 hrs, 4 minutes, and 4 seconds! Sweet victory for node operators and bitcoin as a whole!
This did truly make me very happy as it served my purposes and the community as a whole in no small part. I was stoked, and to such a degree that had to spread the joy around the community, encouraging others to take note of the speedy sync time by benching it themselves. I made a reddit post, and put the code on github, along with the data from my 4 hour full bootstrapping of bitcoin core.
Well anyway, I enjoyed this little treat from the devs, and hope y’all do as well. Thanks guys! Long live the core!