Iota’s Tangle Protocol

In a previous post we looked at the blockchain.  I explained the blockchain data structure from the perspective of git.  Today I’d like to take a look at iota’s brand new protocol called tangle and explore what makes it different from a blockchain, and why in my opinion it’s such a simple, yet novel idea.


When we originally discussed the blockchain I pointed out that it’s essentially a linked list with some very special properties.  It seems like the next logical extension we all should’ve been asking ourselves, yet weren’t until now, is why a linked list?  What other data structures could we apply this same technique to?  This is what the tangle protocol has done.

Rather than storing the transactions on a linked-list, the transactions are stored on a DAG (directed acyclic graph).  Often the most simple ideas are the most brilliant.  This was the case with the blockchain, and now is the case with it’s extension, the tangle protocol.

200px-polytree-svg (a simple example of a DAG)

So what? why does it matter?

No fees, lower transaction times

Because the transactions are in a DAG, it further decentralizes the transactions.  Each node holds one transaction, because of this, they’re now small enough for other users of the protocol to perform validation, and proof of work without needing an ASIC.  As we saw in the blockchain post, the users had to rely on the miners to do the proof of work because a large portion of transactions were stored in a block, and there was only 1 branch.  Now the work can be parallelized and decentralized.  Because this consensus can happen on multiple branches at the same time, this makes transaction time much lower compared to standard blockchain technologies.wii-tangle

Looking at the above picture, it’s as if the blocks have been broken apart and their transactions scattered about in the ever forward moving continuous DAG, and they’re all happening in real time.  With the blockchain we viewed time in a block scale, imagine each block being a day, things could only happen at the end or beginning of a day.  With tangle, we’re able to inspect transactions on an hour, or even minute scale.


I think it’s hard for anyone in the cryptocurrency community to find anything wrong with the tangle protocol.  It’s increasing decentralization in a big way, and that’s something every one can agree on, particularly after the recent bitcoin hard fork, which was due in large part to the centralization of mining power.  With tangle we’re giving the hash power back to the users of the protocol.

I’ve also heard during this interview with one of the founders of iota, that the protocol was recently attacked with 300% hash power, and actually got faster and more robust from the attack.  This is very important, because as a technologist, my instinct was initially to say “well, it isn’t being mined by special hardware, can it really be that cryptographically secure?”  This protocol is still very new, and there is still a lot that needs to be hashed out.  For example, one thing I’ve heard asked is:  “what is the efficiency of transaction look up?”*  since transactions are now in a DAG this certainly raises the complexity associated with finding your transaction in the graph.  It is called a tangle after all, and I don’t know about you, but the word tangle doesn’t necessarily bring about ideas of order to mind.  However, I’m very excited about this paradigm shift away from the blockchain from a purely scientific standpoint.

After having further discussions with the tech community, I’ve elected to write another post directed at the details of some of the following criticisms of iota.  See you then!


NOTE: here are a few videos I found that were pretty good while doing research into this new topic. [1, 2, 3]

*Since writing this post, here’s another criticism I’ve found from Mr. Eric Hop:

“The only drawback with iota is that it’s not safe to send multiple transactions to the same address.”

My response to this was: “This seems like it would be easy for them to remedy, no?”

Here is Eric’s response after an impressive deep dive into the internals of the protocol:

You can use an address for receiving as long as you have not used it for any outgoing transaction. What this means is that once you have sent a transaction with a specific address as input, you should never use it again. This is because IOTA uses Winternitz one-time signatures which degrade security exponentially after each reuse.

So I was wrong in that it is unsafe to send multiple transactions to the same address. It only starts to become unsafe once you have spent some of the IOTA on that address.

Spending from the same address multiple times increases the risk that your address will be compromised, but your seed is still secure.

Addresses are generated by the wallet starting at index zero. It increments the index every time it finds an address already in the tangle. When it finds the first unused address that is the address returned.
That is why it is a good idea to connect a receiving address to the tangle already. So that the wallet will not generate the same address again while nothing has been received on that address.

Why the wallet does not simply keep track of the last index used is beyond me. It then could simply start at the next index when a new receive address is required. If I ever find out the reason for this I will follow up.

I also see no particular good reason other than accidentally being able to receive on an address that was spent from already for not being able to generate addresses offline like with Bitcoin wallets.

The seed should be a unique starting point, from which you could generate addresses one after another, incrementing the index every time.
The only security issue that could arise is when you would use the same seed again on a different offline wallet that would then proceed to generate the same string of addresses, or on an online wallet, that would potentially generate the next address in the sequence, in which case the offline wallet does not know about this fact and will happily generate the same next address…”

This made me sceptical of the Winternitz encryption (it seemed to be the cause of the majority of issues).  Eric explained the Winternitz was chosen due to it’s quantum proof qualities.


The blockchain, from a git perspective.

The blockchain is a revolution idea that’s changed the way computation and transaction will be done for decades to come.  There is already plenty of information out there on this topic, so I’ll spare the internet yet another tutorial.  However, I do think I have an interesting perspective to bring to the discussion.  I often tend to view the blockchain as very similar to the wildly popular version control software git.  In this post I’ll be both teaching, as well as defending my unique position.


If you’ve spent even a small amount of time in tech you’ve heard of git.  git is decentralized source control, and has revolutionized the way software developers collaborate on projects.  The idea behind git, is essentially a linked-list where each commit is a new node in the linked list pointing back to a previous snapshot of the code.  What’s interesting about git, is you can have forks in your linked-list, and these can be merged or deleted (or, orphaned, in blockchain parlance) at will.capture_stepup1_5_6

In a sense, git is a controllable linked list history of your project (note, that this can be any project, not just software, even artists should use git).

The Blockchain

Now, let’s talk about the blockchain.  The blockchain, is like git, except inside of the linked-list’s nodes lie transactions, rather than code changes.  That’s all bitcoin is, a big long string of git commits with balances of addresses in the commits rather than code changes.  So what is the big deal?

When you’re using git, you don’t really care what a developer does if they fork your code and make changes to it, as long as you get to decide what gets merged back into your original code beforehand.  The same can’t be said of financial transactions. You do care if someone makes changes to that history.  For example, let’s say I was able to fork the bitcoin blockchain, and everyone had to follow whatever changes I made.  Well of course, I’d create a transaction between my address and satoshi’s claiming a few hundred bitcoin.  Then I’d merge it back into the master branch.  Sound good? of course not.  This is the ingenious part of bitcoin.

Mining the blockchain

Because we don’t want people to have the ability to alter the history or future of the blockchain, we need a way of achieving what’s called consensus.  From a git perspective, consensus is simply the maintainer of the repo.  Great, who do we trust to maintain the bitcoin blockchain? satoshi, maybe? how about no one.  How about we place our trust in mathematics.


(here is our block chain, look familiar? it’s a git history, but with miners added on the last “commit”)

The way consensus is achieved without a centralized power having any control, is hundreds of thousands of computers around the globe (more computing power than google, in fact) are competing to cryptographically secure the bitcoin blockchain by solving hash puzzles.  The nature of the puzzles is that it’s nearly impossible for the same computer to mine two consecutive blocks.  This enforces decentralization mathematically.  These computers are called “miners” and whenever they find the solution to one of these puzzles, they get to “mine” a block (or commit, from the git perspective) on the blockchain.  But what’s in it for them? Each of the blocks contain a transaction that allows the miner to pay itself a certain amount of bitcoin, this is called the block reward.  Users of bitcoin also must pay transaction fees to move bitcoin from one address to another, the miner of a block also gets to collect these fees.


Like git, the blockchain can also be forked.  We saw it happen recently, when the blockchain split into the bitcoin cash branch, and the bitcoin branch.  In this case the fork was planned a head of time due to politics, however you’ll often hear the phrase “51% attack”.  This is a security concern for blockchain developers, that they always keep in mind when designing new blockchains.

Revisiting our initial question of “who do we trust to maintain our repo?”.  What would happen if someone managed to get enough computing power together to guarantee that they could mine every block? (note, for simplicity, let’s just leave it at that, but it doesn’t actually have to be every block)  They would position themselves as the “maintainer” of that blockchain.  They could decide what does and does not get added to our master branch of transactions.  This is obviously dangerous.  Luckily, as I said before, the amount of computational power that currently exists in the bitcoin blockchain is more than google has.  In effect, an attacker would have to manage to get their hands more computing power than google.  Attacks like this must still be considered with new non proof of work consensus algorithms that teams are currently developing though.

That’s all for now.  This style of blockchain is called a Proof of Work blockchain.  This means that a miner has proved that they’ve spent enough computation power to solve a hashing puzzle.  They’re proved their work.  There are other styles of blockchain that we’ll explore in future posts.  One is called Proof of Stake, whereby users of the blockchain stake their cryptocurrency in place of  computational power to “bet” on the probability of the next block and are rewarded for correct answers.  Another brand new one is called tangle whereby a user of the “blockchain” (in tangle’s case it’s actually a direct acyclic graph) validates other blocks in place of their transaction fee, thus trading a small amount of hash power in place of a transaction fee.


How to purchase IOTA with USD

I wasn’t planning on blogging about this, but I thought, what the hell, why not?  Today we’ll be purchasing some IOTA.  Iota is a new “tangle” technology designed to alleviate some of the problems with bitcoin.  Namely, high transaction fees, and slow transactions.  We won’t go into the details here, but if there is interest, I’d love to dive deeper into the details of an Iota transaction and explain the differences between bitcoin and iota.  For now, we’ll just be purchasing some.  This tutorial assumes you already have bitcoin in coinbase, or know how to go about getting some.

The wallet

The first step is downloading the wallet.  Go to this website and download the appropriate wallet for your operating system.  After your download is completed, open the wallet and choose the light node option (since we’ll only be using the wallet to send IOTA to it and nothing else).  You’ll next get a message talking about “transition phases”,  for now, we can exit out of this page.  Now you’ll see a page with “Seed” and a Login button.  I use a website like to generate an 81 character password, however 81 characters is not mandatory.  If you click the hamburger menu in the top left, then help, and “Creating a New Account” you can see the requirements for the seed.  If you use be sure to only set the “include upper case characters” and “generate on this device” options.  Store this password somewhere safe, if you lose it, or someone gets a hold of it, you’ll lose all of your iota.  Which may not sound like a big deal now, with IOTA trading at ~$1.00.  However, if IOTA explodes in value, you may have thousands of dollars in IOTA tied to this password.  Enter the password where it says seed, and click login.  You now have an IOTA wallet!


Iota is so new, that it looked to me like the only place to get it is on bitfinex.  So that’s what we’ll use to exchange our bitcoin into iota.  If you don’t have an account create one.  If you do, log into it.  In the top right corner you’ll see “Deposit”, click it.  Under Exchange Wallet click “Click to generate address”.  Back in coinbase send your bitcoin to this address (however you’d like, I use the QR code).  The transaction should go through after about half an hour (yup, bitcoin…see why we’re buying iota?).  After the transaction goes through, hover over “Trading” (in the top left corner) then down to Iota, finally, click on IOTA/BTC.  Click the green circle next to Amount MI.  This will ensure you can purchase the maximum amount of IOTA immediately.  This transaction should happen very quickly.  Congratulations! you now have IOTA!

Bitfinex to iota wallet

You do not want to leave your tokens on an exchange wallet, if you’re new to crypto google Mt. Gox, if you’re not, then you know why.  So let’s transfer the IOTA out of Bitfinex and into our newly create iota wallet.  In your iota wallet you’ll see “RECEIVE”, click it, and copy the address (the big long string).  Go back to bitfinex, click withdraw and select IOTA, paste the address in and enter the full amount of IOTA you purchased on the exchange.  Now your IOTA is safe and sound in your wallet.  You can use this site to track the transaction to ensure the iota is in your wallet.

Hosting a Tor Relay Node on an AWS EC2 instance

Back to Business

Ok, lets pick up where we left off .  We’re now ssh’d into our EC2 Ubuntu server.  The next step is installing tor. Do not run apt-get install tor.  Instead, follow the directions found here (we’re running Xenial Xerus, just so you don’t have to check).  As a sanity check, type tor into the terminal, you should see an error after following those steps.  If you see an error like “command tor not found” back up, and retrace your steps, or get in touch with me for help, something went wrong.


Just like we did in the Windows tutorial.  We’re going to edit the torrc file to configure the node.  I use vim, but feel free to use whatever command line editor you’re familiar with.  If you’ve never used one before, again, feel free to get in touch!  I’m a missionary for The Church of Vim.

The torrc file is located in the /etc/tor/ directory. So run:

sudo vim /etc/tor/torrc

Don’t forget the sudo, otherwise the file will be read only.

Paste the following lines at the bottom of the file:

ORPort 9001


RelayBandwidthRate 75 KBytes # Throttle traffic to 75KB/s (600Kbps)

RelayBandwidthBurst 200 KBytes # But allow bursts up to 200KB (1600Kb)

AccountingMax 1 GBytes

AccountingStart month 3 15:00

ExitPolicy reject *:* # no exits allowed

Here <YOU NODE NICKNAME> should be a unique name for your node that you’ll remember, because we’ll use it to search for the node using atlas.  We’re also directing tor to listen on the port we opened in the previous tutorial, as well as limiting the bandwidth that the tor network can use, and disallowing exit traffic.  We have to limit the bandwidth to these specific metrics, otherwise we’ll accrue charges from Amazon for our EC2 instance.  This explains why the tor network is slow, as discussed in our previous post.  Sadly, we’re one of the slow nodes.

Finally, run:

sudo service tor reload

Sanity Check

The tor documentation tells you the logs will be output to the /var/log/tor/ directory.  I never saw them there, instead I had to use journalctl.  Just like the Windows tutorial, we need to ensure the line “Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.” is being output by the tor node, otherwise the node isn’t working.  So we’ll run:

journalctl | grep "Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor."

If nothing is output to the console, your tor service isn’t running.  Just a few troubleshooting tips.  Run:

sudo service tor stop && sudo tor

If you never see that line output, there is a problem with your tor installation, consider uninstalling tor and reinstalling it.  If, however, it runs fine, there is a problem with the init.d script to daemonize the tor process.  Consider this reddit link.

Going back to AWS cost from the previous post, we can also monitor our tor node bandwidth usage using the following command:

journalctl | grep "Accounting enabled."

You should see output like:

Heartbeat: Accounting enabled. Sent: 94.42 MB, Received: 121.84 MB, Used: 122.38 MB / 1.00 GB, Rule: max. The current accounting interval ends on 2017-09-03 15:00:00, in 21 days 2:08 hours.

Here the node is telling us that it’s used 122.38 MB of the 1GB we’ve defined as the monthly max in the torrc (the Accounting lines).  When we reach 1GB of traffic, the node will stop accepting connections for the rest of the month, thus keeping our EC2 cost inside the free tier metrics.


If the Self-testing indicates... line showed up after running the journalctl command, your node is up and running!  We can now head over to atlas and search for the Nickname you set in the torrc file.  Keep in mind, that like the last tutorial, it will take a few hours to show up on the atlas webpage.

If you named your node something unique, when you search for it, you’ll be taken directly to your details page.  Here’s quick run down.

OR Addresses, is the public IP address of your node, Contact is your contact information if you set it in the torrc file (we didn’t, but it’s explained in the Windows tutorial).  Advertised Bandwidth is how much bandwidth you’re telling the rest of the network you’re willing to allow through you.  Exit Policy is set to reject all exit traffic, as we said, those nodes get put under extra scrutiny.  Uptime is how long our node has been active on the tor network.  You can see AS Name is, Inc, since we’re using Amazon’s hardware.  Below this you can see metric graphs for your node.  Since ours is so new, nothing shows up.


You’ve just joined a unique brotherhood.  You are a protector of internet freedom.  You’ve managed to do what only a very small portion of the population has done, and that’s take concrete action toward a free and open internet.  Anyone can click like, or retweet, but few actually look into the details and understand what it takes for a free and open internet.  I’m proud of you for following along, and if you know me at all, you’ll know this may be the first time I’ve ever said that.


Let me know if I can make this tutorial better or if you managed to make it through!


Creating an EC2 Instance on AWS to use as a Tor Relay node

But This One Goes to Eleven

A few weeks ago I documented the steps necessary to get a tor relay node up and running using Windows.  This was mainly because I wanted to give a gentle introduction to anyone interested in cryptography and internet freedom who may not have a large chunk of experience in tech.  I strongly believe anyone can become an expert in any niche given the scale of information currently available on the internet, and I don’t think technology is any different.  All it takes is a little bit of inspiration, which I was hoping to provide by taking it slow.  Now we’re going to turn up the volume a bit.



One large drawback of hosting a relay node on your personal laptop is your connection to the tor network is not persistent.  Every time you close your laptop or shut it off and turn it back on, your tor software loses all the connections that were so helpfully shuttling network traffic for everyone.  This time, we’re going to set up a Free Tier AWS EC2 instance in the cloud, and run the relay node software using this server space.  This will ensure our node will forever stay up supporting the tor network and internet freedom!

One thing to note is, once you’ve got your EC2 instance provisioned, you can put any software you want on it and it will automatically be connected to the rest of the internet!  I use this frequently for a lot of my side projects.

Also, I’m going to assume you’re running some flavor of Linux and have some familiarity with the command line moving forward.  If you don’t, please don’t fret, just google, and as always, don’t hesitate to reach out to me and ask for help!

Welcome to The Cloud

First, we’ll go to and click “Sign In to Console”.  You’ll click “I am a new user.” after being directed to the next page and entering your email address.  Heore you’ll enter your first name, retype your email address, and set your password.  Then click “Create account”.  You’ll then be redirected to a Contact Information page.  Select the Personal Account radio button.  Fill out the information in the form.  When you’re done, click the Agreement check box and then Create Account (if it took you more than two tries to get the captcha don’t worry….I did too).  Next AWS asks for your payment information.  I know when I first signed up I was hesitant.  I’m always hestitant about inputting credit card info.  However, I assure you, your account will not be charged throughout this tutorial.  And in fact, I’ve inadvertently racked up $1100 in AWS charges after uploading my IAM keys to github (yes, I’m that stupid) and had them all refunded.  Amazon rocks with refunds.

Next, you’ll fill out the captcha and click the button to receive the phone call from Amazon herself.  Type in the pin shown on the screen and end the phone call.  Then click Continue.  We want the Basic support plan, so select that and again click continue.  You’ll be taken to the homepage, click Signin to Console.  Enter your email, and password your set earlier in the tutorial.

You now have an AWS account.  Welcome to the cloud.


There are an endless supply of cloud computing resources supplied by Amazon.  We’ll only be looking at 1 today, but I recommend you check out as much as you can.  In fact, if you don’t have a job, or dislike the one you’ve got and you learn the ins and outs of AWS, you could easily land yourself a dev-ops role at a great company.


We’ll be using the EC2 service provided by AWS, so click that one, under AWS services.  EC2 stands for Elastic Compute Gen 2.  The elastic part means that your computational resources can scale up or down depending on how much you’re using.  I believe you can also bid on computing resources, whereby the price fluctuates with demand for Amazon’s servers.  Since we’ll be doing very minimal computing, this means ours will be free!

Click the blue Launch Instance button.  You’ll be presented with various different Operating Systems that you can put on your EC2 instance.  We’ll be using Ubuntu, so scroll down until you see Ubuntu Server 16.04 and click select.  Here we’ll choose the computing resources that we’d like to use on the server.  Leave it as is, which should be the t2.micro settings, which as Amazon has so kindly informed us is free tier eligible.  Now, click Review and Launch, and finally, Launch.

Private Key File

You’ll now be presented with a pop up informing you that you need to create a private key file in order to SSH (secure shell) into your Ubuntu server.  As I said, we’re turning the volume up for this tutorial.  Here’s the general idea of what we’re doing.

You have a laptop that you’re reading this blog post on.  Somewhere in New York or Oregon, or hell, even Tokyo, Amazon has a bunch of servers it uses for various tasks on its website.  Well it’s decided to sell some of those servers to the public to make money when they aren’t using them.  You’ve just been given a server somewhere in the deepest depths of Mordor.c-hrivxvoaalxjl

Great! we have a server! but how do we access it?  We have to use a networking protocol that allows us to pass commands to the computer through the internet.  However, we don’t want anyone to be able to pass commands to our computer, so we need a way of securing it.  Enter: the private key file.  Using roughly the same technique that keeps your traffic secure while you do your online banking, we can keep our commands to the cloud computer safe.

Bombs Away!

Select Create a new key pair, then name it whatever you like.  I’m going to name mine “torRelayNode” because that’s what I’ll be using this EC2 instance for.  Then click “Download Key Pair”.  Save this file somewhere safe, if anyone gets ahold of it, they’ll have access to your server and can do whatever they’d like with your AWS account.


Now click Launch Instances, then View Instances.  You should see your new t2.micro instance, with an Instance State of running.

While we’re here, we’re going to set the port forwarding for the port we’ll be using on the tor node.  On the left, you’ll see Network & Security, and under that Security Groups, click that.  You should see two security groups, we want the one that belongs to the launch-wizard-1 Group Name.  When you click it you should see it’s current network rules.  The only one should be of type SSH, using the TCP protocol, on port 22, from any source (  Click the Edit button above that, and Add Rule.  From the drop down under Type, choose Custom TCP, the protocol is TCP, the port will be 9001 (as we’ll see in the next tutorial).  Using the Source dropdown, select “Anywhere”.  You’ve now added the firewall rule to allow for incoming connections on the tor network to connect to your node on port 9001.  If at any point you decide to change the tor node’s port in the torrc file, don’t forget to change it here as well!

You now have your very own cloud computer!


But how do we access it?  We use that private key file we downloaded, and ssh into it. First we need to get the public IP address associated with our EC2 instance.  On the left (where you saw Network & Security) you should see Instances, click Instances under that.  You should see “Public DNS:” below where all of your EC2 instances are listed, and a big long string starting with “ec2-“.  That’s your shiny new server’s address on the internet.  Copy it, we’ll need it later.

Next, we’ll open up the command line, cd into whatever directory you downloaded or moved the private key file to, then change the execution permissions of that file with chmod:

chmod 400 <The name of your .pem file, in my case torRelayNode.pem>

and finally:

ssh -i <The name of your .pem file> ubuntu@ec2-the-ip-address-you-copied-from-before

Note, that you’ll need to be in the same directory as your .pem file, or pass the command the path to your .pem file.  If it’s your first time logging into your EC2 instance, you’ll be asked if you want to trust it.  Type yes and hit enter.  Now you’re on your new computer!

Shutting it Down

Before I forget, if you do somehow end up getting charged somewhere down the road from AWS, you can kill your instance by going to the Instances page, clicking your instance, selecting the Actions drop down, and changing the Instance State from Start to Stop (and the nuclear option, Terminate).  You’ll still have to cough up the charges (they should be small) but this should stop you from getting any more.  Also, on that note, I’d recommend looking into setting a billing alarm to send you an email if you ever do get charged.  I’ll also monitor this EC2 instance for a month and post an update if it does end up charging me, so we can fix it together if it does.  Also, again, don’t hesitate to get in touch if you have any problems with the charges!

Next Steps

In the next blog post, we’ll get the tor relay software up and running on your new cloud server, and you can now brag at parties that you’re actually protecting revolutionaries in dictatorial countries, just like I do any time someone asks me which VPN to use.  Also, don’t forget to buy a tor sticker to put on your laptop, as you’ll have joined the brotherhood after the next tutorial.









Hosting a Tor Node on Windows 7

Please note, this tutorial is not for the technologically feint of heart.  However, I’ll give you my personal guarantee that if you run into troubles, I will respond to every request I receive for help.

First, lets to go to this URL:

and download the Expert Bundle for Microsoft Windows (that’s right, you’re now a tor expert, go a head and tell your friends).  We’re going to follow the steps for Windows, because if you’re on Linux, I’m going to assume you can figure all of this out on your own.  If not, feel free to get in touch and we can walk through the steps together.  And in fact, the steps on the torproject website are made for Linux.

Once the download is finished, extract the contents of the zip file.  You should now see two folders, Tor and Data.  Go to the Tor folder and create a new text file.  Inside of it, paste this:

ORPort 443
Exitpolicy reject *:*
Nickname ididntedittheconfig
ContactInfo <your email address>

where <your email address> is your email address.


Now begins the feint of heart parts.  We’re going to log into your router, and enable port-forwarding for the port tor uses to connect to the rest of the tor network (443).  Look into your specific router’s configuration.  A quick google search for something along the lines of “linksys WRT160nl ip address” should tell you which ip address your router resides on.  Type this ip address into your browser and log into the router admin page.  Each router is different, but again, a quick google search for something like “belkin n600 enable port forwarding” should yield good results.  The tricky part is, you’ll have to know what ip address your computer currently has to type into the device IP portion of the port forwarding inputs.  Your router will pass all the traffic it receives on port 443 on to your computer.  To get the ip address, follow these steps.


Hurray! you got port forwarding working! this is useful for all sorts of things outside of tor.  If you want to make any device at your house accessible from the internet, you’d simply add the port forwarding in your router, and forward the traffic to that device in your house.

Ok, if you followed the steps to find your IP address, you’ve at least opened the terminal now and ran one command.  Things are going to get a little bit ambiguous because we’re all on different computers and the files are all probably in different places, but here’s the general idea (and I’d recommend google a lot if you get stuck, as well as getting in touch with me).  We’re going to change directories (cd) into the extracted tor-win32- folder.  When you get there, cd one more time into the Tor folder.  You should see your newly created torrc.txt file, as well as a tor.exe file.  Now, type this:

tor.exe -f torrc.txt

If you get the error 'tor.exe' is not recognized... then you’re not in the correct directory.

Tor will now spew out a bunch of information to your terminal, one of which is “Guessed our IP address as <Ip address>”.  Remember this, as we’ll use it to validate that our node is actually working.  Eventually, you should see the line “Self-testing indicates your ORPort is reachable from the outside.  Excellent.  Publishing server descriptor.”  This means you did everything right.



Another way to check is atlas.  Click the link, and in the top right corner search for “ididntedittheconfig” (notice above, that’s the Nickname we added to the torrc file at the very beginning, you can name your tor node whatever you want, you’d use this new nickname to search for your node on atlas).  You should see a bunch of nodes named that, since its the default setting, but one will be that IP address I told you to remember in the previous section.  Please note, atlas takes awhile to update, so you probably won’t see it immediately, don’t panic.

Tor Network

Welcome to the tor network!  The only remaining issue to handle is, when you turn off your computer or log out, you’ll be disconnected from the tor network.  Ideally, we’d like to reconnect to the network any time this happens.  This would involve running the tor.exe -f torrc.txt command when the computer wakes up, or powers on.  But we’ll save this for another tutorial, or if you’re feeling adventurous, for you to try (a quick search for “run command on power up windows” should give you a good place to start).  Alternatively, you could use a free tier AWS EC2 instance to persistently host a node.

A Rant on the NSA and VPNs (or, your civic duty to put on a pair of pants)

I’ve gotten enough family and friends asking about VPNs that I’ve decided it’s time for a blog post about it.  I can’t explain how happy I am to hear people asking unprovoked about VPNs.  As anyone who’s had a conversation with me at any kind of gathering knows, I care deeply about a free and anonymous internet.  I strongly believe that cryptography is the way to achieve this.  I read cypherpunks on my honeymoon.  I’m invested in cryptocurrency (no, not bitcoin, and yes, including ICOs), and I’m in the process of building a miner.  I spent my downtime after leaving SDL learning solidity.  That’s how much I care.

With the Snowden leaks it became known that the NSA was surveilling public communications in mass.  We often hear the tired trope of “well, I’m not doing anything wrong on the internet, so why would I care?”.  And in response to that I’ll trot out the equally tired trope of “perhaps you’re not doing anything wrong under the current regime, but what happens when that regime changes, and they don’t like something you’ve done in the past on the internet?”.

There are more nuanced reasons for the necessity of secure communications online, however.  One of which is brought to light by the recent cyber attacks [1,2].  It isn’t secure for all communication to be stored in a centralized manner anywhere, as this leads to the possibility of massive cyber attacks.  Both of the above cyber attacks used NSAs own tools.  The internet wasn’t originally designed to be centralized, and any centralization of power or data is extremely dangerous.

Another nuanced point will play to your civic duties as a progressive, libertarian, patriot, or whatever you people are calling yourselves nowadays.  As it stands now, it is relatively easy for the NSA to target individuals, nefarious or otherwise, because of the nature of their internet traffic.  If a user is using a VPN, or tor, or any kind of abnormal encryption, they’re immediately given a jaundiced eye, even if this person is simply browsing reddit.  If, however, everyone on the internet decided tomorrow to tunnel all their traffic through tor or a VPN, or use an elliptic curve cryptography instead of TLS, this would create a massive computational haystack with which the NSA would have to search in to even check for the existence of needles.

In a sense we’d all be pretending to carry around bombs in the NSAs eyes, making anyone actually carrying a bomb look less suspicious.  And therein lies the quandary.  We want the NSA to find bombs, but at what cost? The verdict on whether or not the NSA is effective in their goal is hotly contested [1,2,3,4,…I could go on for days].  I don’t want to stray too far off topic (this was actually intended to be an introduction to this post walking a user through the basic set up of the TunnelBear VPN), but there are numerous discussions pointing out the irrelevance of the NSA’s effectiveness to the moral question of mass surveillance.

But I digress.

I personally believe that the internet was meant to be fully anonymous and fully encrypted.  Rather than thinking of it as “we’re all pretending to carry around bombs”, I believe it’s more similar to “we’re all wearing clothes, and anyone not encrypting their traffic is buck ass naked”.  Don’t you think that’s a bit suspicious?

And this is why I believe everyone should use tor or VPN for every form of internet communication.  It is your civic duty to put on a pair of pants.

TunnelBear VPN

Phew.  I just got done writing the introduction to this post.

It turned into a cryptography rant, which I eventually moved to its own post.  The theme of this post will be staying out of the weeds.  If you’re interested in my cryptography rant, I’ll be posting it sometime soon, so feel free to subscribe or follow me on twitter and get updated when I do.  For this one, we’ll dive right in.

A number of friends and family have asked about VPN (which if you read the rant you’ll know brings me a lot of happiness).  Usually in the form of “which VPN is the best?”, to which I typically respond “just use tor“.  The problem with VPNs is, they cost money.  If you go the free route, your internet is either as slow as it is using tor, or their is a data cap on the service.  In both cases you’re better off using tor.  However, what if you’ve got cash to shell out for your online anonymity? Enter…


I’ve used this in the past when I was just toying around with VPNs and found it insanely easy to use and set up.  For that reason I chose to use TunnelBear for this little tutorial, because I’d like to direct it toward less technical people.  If there is interest, I’ll be more than happy to do a follow up with a more serious service, but for now TunnelBear will be great to get our feet wet with a VPN.

Getting an Account

The first step is creating an account.  I lucked out when I started writing this and found a referral link to get 5GB of data free instead of the typical 500MB you’re given.  So we’ll use it!  Click the link, create an account, and the download for the installer will immediately start.  Once it’s done, go ahead and run it.  Agree to the service terms and install!  After the installation finishes, login with the username and password you created at the above link.  Before you can actually use the software, they’ll send a confirmation link to your email.

The Fun

Now begins the fun.  This is why I chose TunnelBear.  People like to see feedback in the user interface to let them know something is actually happening.  Well TunnelBear certainly does a fantastic job of this.

After your account has been verified simply turn the VPN on.  You’ll see in the UI that your sheep has tunneled to a new continent and is now a vicious bear.  You’ll also see your monthly data cap going down from 5.5GB when you navigate to a new page.  You’ll notice that your internet is now presumably a bit slower.  See these (1, 2, 3) for explanation.

Maybe your traffic got tunneled to Canada but you’d like it to appear as though you’re in India.  With TunnelBear this is super simple.  Simply use the map to navigate to another tunnel and now all of your traffic appears to be from that continent!

If you read either of the two links above explaining the speed loss, you’ll now understand why when you tunnel to a continent farther from you, your speed degrades a bit more.


There you have it, you’ve got a VPN up and running in a matter of seconds!  Well, kind of.  Remember what I was saying about shelling out cash?  Once your 5.5GB of data runs out on TunnelBear you’ll no longer be allowed to use their services for that month.  For reference that’s about 2 hours of HD streaming on netflix.  If you’re willing to pay $10 a month, however, you’ll have unlimited anonymous internet to your hearts content.  You can also tweet to TunnelBear and receive an extra GB of data per month on your free account.


I recently heard back from a friend who pointed me to this video.  In it JayzTwoCents recommends Astrill.  I haven’t tried Astrill, but JayzTwoCents is very scientific about the process and says he tried a bunch and Astrill was the best.


The friend ended up pulling the trigger on NordVPN after doing their own research.  Another pointed out one of the flaws of TunnelBear is you can’t tunnel torrent traffic using their service.  Apparently the Bear isn’t too keen on pirates.