Bitcoin
Bitcoin (BTC)
$61,221.00 -2.54671
Bitcoin price
Ethereum
Ethereum (ETH)
$3,007.55 -1.77536
Ethereum price
BNB
BNB (BNB)
$535.49 -0.15345
BNB price
Solana
Solana (SOL)
$135.10 1.87482
Solana price
XRP
XRP (XRP)
$0.4981350 1.1519
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000221 -0.80199
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000050 -7.11082
Pepe price
Bonk
Bonk (BONK)
$0.0000143 -1.36658
Bonk price
Bitcoin
Bitcoin (BTC)
$61,221.00 -2.54671
Bitcoin price
Ethereum
Ethereum (ETH)
$3,007.55 -1.77536
Ethereum price
BNB
BNB (BNB)
$535.49 -0.15345
BNB price
Solana
Solana (SOL)
$135.10 1.87482
Solana price
XRP
XRP (XRP)
$0.4981350 1.1519
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000221 -0.80199
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000050 -7.11082
Pepe price
Bonk
Bonk (BONK)
$0.0000143 -1.36658
Bonk price
Bitcoin
Bitcoin (BTC)
$61,221.00 -2.54671
Bitcoin price
Ethereum
Ethereum (ETH)
$3,007.55 -1.77536
Ethereum price
BNB
BNB (BNB)
$535.49 -0.15345
BNB price
Solana
Solana (SOL)
$135.10 1.87482
Solana price
XRP
XRP (XRP)
$0.4981350 1.1519
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000221 -0.80199
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000050 -7.11082
Pepe price
Bonk
Bonk (BONK)
$0.0000143 -1.36658
Bonk price
Bitcoin
Bitcoin (BTC)
$61,221.00 -2.54671
Bitcoin price
Ethereum
Ethereum (ETH)
$3,007.55 -1.77536
Ethereum price
BNB
BNB (BNB)
$535.49 -0.15345
BNB price
Solana
Solana (SOL)
$135.10 1.87482
Solana price
XRP
XRP (XRP)
$0.4981350 1.1519
XRP price
Shiba Inu
Shiba Inu (SHIB)
$0.0000221 -0.80199
Shiba Inu price
Pepe
Pepe (PEPE)
$0.0000050 -7.11082
Pepe price
Bonk
Bonk (BONK)
$0.0000143 -1.36658
Bonk price

“Nobody has Synced an Electrum Server from Genesis for Over a Year.”

This article is more than 4 years old
Interviews
News
“Nobody has Synced an Electrum Server from Genesis for Over a Year.”

Electrum is one of the oldest and remains a favorite light client for Bitcoin. It works with a network of servers that feed the clients with block data. But with the growth of the Blockchain, starting a new server has become nearly impossible, so that the creation of new servers has ultimately come to a halt; until Neil Booth’s ElectrumX fastened the synchronization by around a factor of 100. We talked with Neil about Electrum, the disadvantages of light clients and his project.

Hi Neil! Tell us something about you. How and why did you start developing Bitcoin?

I live and work in Tokyo, where I have lived for over 17 years now. I worked in the financial industry for about 20 years until early 2014, when I decided I’d had enough, took a break of 18 months, and joined a Japanese software company writing financial software. I’ve been passionate about Bitcoin since I first heard of it several years ago.

You work with Electrum, a light wallet. Can you explain the model of Electrum and its advantages over other light clients?

The idea is like all light-weight clients that you should just be able to install and get started with Bitcoin immediately without having to run a heavy server or download a large and ever growing blockchain.

I believe Electrum was one of the first, if not the first, to pioneer HD (hierarchical deterministic) wallets, where you only need to store a seed securely, usually expressed as a mnemonic of 12 or more words, to regenerate your whole wallet history. No other backups are ever needed. Your seed is stored encrypted and not held in memory for longer than necessary. By way of contrast, for many years bitcoind wallets were stored unencrypted on your hard drive and required constant backing up because the private keys in the wallet were unrelated and continuously refreshed as transactions happened. This led to many steep losses for early users of that software.

Electrum is also very flexible if you are a power user who knows how bitcoin works. For example, it has good coin control, which is important to preserve your privacy from third parties watching and analyzing blockchain transactions. I am not aware of other lightweight wallets that offer such a feature, but I am not familiar with all wallets. Electrum also supports a range of hardware wallets and has other features available as plugins.

In your read.me you write “For privacy and other reasons, I have long wanted to run my own Electrum server.” What are the specific reasons for people to host an Electrum server?

For the convenience of using a lightweight wallet, you necessarily sacrifice something. With all lightweight wallets you sacrifice privacy: for the wallet to get the information it needs to show the user’s transactions and balance, without processing the whole blockchain itself, it must rely on a server or service to index the blockchain and provide that information to it. For the Electrum server to provide the information, the client software necessarily needs to provide the server with all its user’s addresses, so that the server can notify the client when it receives money or give it the address history.

An unscrupulous server operator could collect information about IP addresses and requests made to the server, and, making various assumptions that may or may not be valid, correlate addresses and wallets over time to build profiles of users. Although I’m not aware of anyone doing this at present, for anyone with basic software knowledge it is easy to do.

So if you value your privacy yet like to enjoy the convenience of an instant-on HD wallet with hardware wallet support, then running an Electrum server yourself becomes an attractive proposition. If you connect to your server, you know that nobody spies you. And of course, the more people that run Electrum servers, the more users we can support without overloading the existing servers.

You tell that you failed to run an Electrum server on your DragonFlyBSB system. What is this for a system? And why did you fail?

DragonFlyBSD is an excellent operating system that forked from FreeBSD. It is mainly designed and developed by Matthew Dillon who is an incredibly talented individual, and very modest to boot.

Why did I fail to run a server? Unfortunately, the original Electrum server software was very resource intensive. What it does is that it indexes the blockchain in a special kind so that it can deliver information to the clients. This indexing needed a lot of resources, both in time, disk space and memory consumption. No one knows for sure how much time it takes today because I could not find anyone who has indexed an Electrum server from scratch for over a year. As the blockchain has grown to more than 100 GB, it takes so long no one will do it. An educated guess from volunteers letting it run for a while is that with recent good hardware it would take around one month.

This sounds like a serious thread for the Electrum network. Fortunately, you improved this process of setting up a server significantly with ElectrumX?

Yes. With ElectrumX I would say that syncing an Electrum server is not more work than syncing a bitcoin node. I wrote the server software in Python3 instead of Python2 and made several improvements and changes in the structure of the blockchain indexer. The result is that syncing the server from the Genesis Block is around 100 times faster. It needs probably around eight hours. And I am still finding ways to improve the sync times.

I hope to encourage as many people as possible to feel easily able to run their server without high-end machines.  One enthusiast has ElectrumX running on a Raspberry Pi serving several hundred sessions at a time. I guesstimate that the Pi running current ElectrumX software could just about keep up with the network if blocks averaged 3MB each; I have some ideas I think could raise that to about 8MB.

What are the requirements to run an Electrum server with your software?

To run an ElectrumX server you just need a few systems knowledge, as you would for any server. You need about 25GB of hard disk space to store the indexed database and have room for some growth (assuming you already have a bitcoind that has synchronized the blockchain, bitcoind needs to have the transaction index flag set to one or be reindexed with that flag). When indexing at least two gigabyte of RAM is best. Once you have caught up to current height, the server uses around 600MB of RAM to serve well over 1,000 sessions and is very low on resources (both CPU and incremental disk usage). So the requirements are no longer restrictive.

Follow Us on Google News