How to Download and Get up and running quickly with a full Ethereum Mist/Geth Blockchain node on Windows 10.

You’ve come to the realisation that Ethereum is where it’s all at, as far as Smart Contracts and ICOs / Token sales go. It is a basic requirement to participate in most token sales, including that of VRENAR. You also know the difference between using third party nodes, and having your own full node. So now you’ve downloaded, and are trying to get the reference Ethereum Mist wallet working on Windows 10, and you are experiencing some problems.

This tutorial is for you, created from my own experience of being in the same position, so hopefully it will save you some time, and some pain. Even better if it actually tips the scales in favour of you becoming involved in Ethereum rather than throwing it aside in frustration as something not reliable enough to be taken seriously.

I had successfully played with Ethereum a few years ago on a Windows machine without incident. But this time I could not get the Mist wallet to download and establish a working node on it’s own at all. I left it downloading literally for weeks. It seemed to get very close, within less than 1000 blocks of 5.5 million, but it never quite got to the end. Also, the Mist wallet on it’s own appears intolerant to IP address changes, appearing to completely stall on any change made, say to a VPN. Further, if the Mist wallet does stop, or is stopped at any point during the initial blockchain database download, it appears to run in slow mode whenever restarted thereafter, rendering it incapable of ever synchronising. I’ve seen the same problem complained about on many forums, with as yet, no apparent solutions.

So, towards a solution; I’ve found that it helps first of all to imagine the Ethereum network being currently under some sort of sophisticated long running blocking / choking attack. Once you have this in mind, you start to form a picture of how such an attack might work, how it would affect you, and how to respond to it.

First of all the attackers might use AI type algorithms to analyse all internet traffic seen from their connection points, looking for the peer-to-peer encrypted charactistics of Ethereum. Then, they might trace this traffic to the IP addresses of it’s sources. Logically these would be either existing, or in creation Ethereum full nodes. Identified as such, those IP addresses could then be targeted with Denial of Service (DoS) traffic, or if the attachers somehow had the powers of ISPs, they could simply block or choke the Ethereum data flows.

Once you have that type of network characteristic in mind, you can start to work out a strategy to get around it. You might come up with some hypotheses, like mine as follows:

1. It takes time for AI algorithms to update their databases and learning systems with new target addresses and network geographics, and then to apply and adjust effective blocking / choking mechanisms.
2. The attackers would probably not wish to make their behaviour known, as once exposed, they could easily be stopped by agencies anxious to be seen to be working in the public interest. So it is likely that rather than completely block traffic, they could just slow it down so that it becomes practically unworkable, perhaps leading also to false conclusions that the fault is with Ethereum itself, rather than the network.

Logically, with such forces in play, the effect seen in Ethereum would be for your new node to at first freely and rapidly download the blockchain, then after a while your node IP address would be noticed by the attackers, and your downloads would then slow down to a trickle as the attackers begin to target your new node.

To get around it, you might install a VPN to remote your apparent IP address to a different geographical location, after the effects of blocking behaviours become apparent. Even more useful if the VPN has the ability to be rapidly switched between different remote networks selected from a list, and the IP address hopped from location to location as needs arise. Then you might encounter the problem of Mist intolerance to IP address changes, and move on to trying Geth.

It was not until I downloaded and installed Geth, and started a new download of the blockchain via the Private Internet Access VPN that I finally did it. Geth runs in a DOS mode CMD window, appears fully robust to IP address changes on the fly, and the Mist wallet automatically detects it running and connects to it, given that Geth is running when Mist is started. It took around 18 hours to download the blockchain and sync the new node using Geth via VPN.

Here are the steps I followed:

1. Download and install the Mist Ethereum wallet.
2. Download and install the Private Internet Access VPN.
3. Download and install Geth.
4. Delete any unsuccessfully downloaded chain data.
5. Start the VPN, choosing a European IP location to avoid any possible blocking that might be occurring due to the recent changes to net neutrality laws in the US.
6. Start Geth
7. Start Mist
8. Monitor the download behaviour. If it is like mine, it will rocket download at first, then after maybe a half hour or so, it will start to noticeably slow down to a trickle with various error messages appearing in the Geth command window. When this happens, do not close Geth, but switch the VPN to a different European location. Watch the download speed immediately start to rocket again, leaving the error messages behind.
9. Repeat step 8 as often as necessary to maintain the download speed. I found that it is possible to rotate the VPN around a small number of locations, as each appears to recover after a few hours.

After the node is finally fully synced, the traffic load decreases significantly to a fraction of what it was during the main blockchain database download, and appears to work without incident. The wallet will confirm synchronisation, showing number of peers and reception of another block at 15 to 20 second intervals. After this, there appears no longer a need to switch VPN locations, it appears to work anywhere indefinitely. If the sync is interrupted for a day or two, it can be resynced within a few hours repeating steps 8 and 9.

In conclusion, if there is such attacking behaviour going on, it is designed to recognise the high volume data characteristics of the initial database download, thus effectively prevents the initial setup of a new node in many cases, rather than stopping existing nodes. It follows that this characteristic would seriously impede the take up of Ethereum by new users, if they are not aware of it, and how to work around it.

So there it is. I hope my suggested workaround serves you as well as it does me.