How to Run your Own Independent DNS with Custom TLDs

This article was originally written for and published at N-O-D-E on September 9th, 2015. It has been posted here for safe keeping.



After reading what feels like yet another article about a BitTorrent tracker losing its domain name, I started to think about how trackers could have an easier time keeping a stable domain if they didn’t have to register their domain through conventional methods Among their many roles, The Internet Corporation for Assigned Names and Numbers (ICANN), controls domain names on the Internet and are well known for the work with the Domain Name System (DNS) specifically the operation of root name servers and governance over top level domains (TLDs).

If you ever register a domain name, you pick a name you like and head over to an ICANN-approved registrar. Let’s say I want my domain to be “”. I see if I can get a domain with “n-o-d-e” affixed to the TLD “.net” and after I register it, I’m presented with an easy-to-remember identification string which can be used by anyone in the world to access my website. After I map my server’s IP address to the domain, I wait for the new entry to propagate. This means that the records for my domain are added/updated in my registrar’s records. When someone wants to visit my website, they type out “” in their address bar of their browser and hit the enter key. In the background, their set name server (usually belonging to the ISP) checks to see who controls records for this domain, and then works its way through the DNS infrastructure to retrieve the IP address matching this domain name and returns it back to you.

It’s a reliable, structured system, but it is still controlled by an organization who has been known to retract domains from whoever they like. What if you could resolve domains without going through this central system? What if there was a way to keep sites readily accessible without some sort of governing organization being in control?

I’m not the first to think of answers to these questions. Years ago, there was a project called Dot-P2P which aimed to offer “.p2p” TLDs to peer-to-peer websites as a way of protecting them against losing their domains. While the project had notable backing by Peter Sunde of The Pirate Bay, it eventually stagnated and dissolved into obscurity.

The organization that would have handled the “.p2p” domain registrations, OpenNIC, is still active and working on an incredible project itself. OpenNIC believes that DNS should be neutral, free, protective of your privacy, and devoid of government intervention. OpenNIC also offers new custom TLDs such as “.geek” and “.free” which you won’t find offered through ICANN. Anyone can apply for a domain and anyone can visit one of the domains registered through OpenNIC provided they use an OpenNIC DNS server, which is also backwards-compatible with existing ICANN-controlled TLDs. No need to say goodbye to your favorite .com or .net sites.

If you have the technical know-how to run your own root name server and submit a request to OpenNIC’s democratic body, you too could manage your own TLD within their established infrastructure.

Other projects like NameCoin aim to solve the issue of revoked domains by storing domain data for its flagship “.bit” TLD within its blockchain. The potential use cases for NameCoin take a radical shift from simple domain registrations when you consider what developers have already implemented for storing assets like user data in the blockchain alongside domain registrations.

But what if I wanted to run my own TLD without anyone’s involvement or support, and still be completely free of ICANN control? Just how easy is it to run your own TLD on your own root name server and make it accessible to others around the world?


It turns out that running your own DNS server and offering custom TLDs is not as difficult as it first appears. Before I set out to work on this project, I listed some key points that I wanted to make sure I hit:

– Must be able to run my own top level domain
– Must be able to have the root server be accessible by other machines
– Must be backwards compatible with existing DNS

Essentially, I wanted my own TLD so I didn’t conflict with any existing domains, the ability for others to resolve domains using my TLD, and the ability for anyone using my DNS to get to all the other sites they would normally want to visit (like


For this guide, you are going to need a Linux machine (a virtual machine or Raspberry Pi will work fine). My Linux machine is running Debian. Any Linux distribution should be fine for the job, if you use something other than Debian you may have to change certain commands. You will also want a secondary machine to test your DNS server. I am using a laptop running Windows 7.

Knowledge of networking and the Linux command line may aid you, but is not necessarily required.


I needed DNS software to run on my Linux machine, and decided upon an old piece of software called BIND. BIND has been under criticism lately because of various vulnerabilities, so make sure that you read up on any issues BIND may be experiencing and understand the precautions as you would with any other software you may want to expose publicly. I am not responsible if you put an insecure piece of software facing the internet and get exploited.

It is important to note that I will be testing everything for this project on my local network. A similar configuration should work perfectly for any internet-facing server.

Other DNS software exists out there, but I chose BIND because it is something of a standard with thousands of servers running it daily in a production environment. Don’t discount other DNS packages! They may be more robust or secure and are definitely something to consider for a similar project.


Step 1. Initial Configuration

Connect your Linux machine to the network and check the network interface status.


The response to the command should look similar to this:

eth0      Link encap:Ethernet  HWaddr f0:0d:de:ad:be:ef
                         inet addr:  Bcast:  Mask:
                         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                         RX packets:8209495 errors:0 dropped:386 overruns:0 frame:0
                         TX packets:9097071 errors:0 dropped:0 overruns:0 carrier:0
                         collisions:0 txqueuelen:1000
                         RX bytes:2124485459 (1.9 GiB)  TX bytes:1695684733 (1.5 GiB)

Make sure your system is up-to-date before we install anything.

sudo apt-get update
sudo apt-get upgrade

Step 2. Installing & Configuring BIND

Change to the root user and install BIND version 9. Then stop the service.

su -
apt-get install bind9
/etc/init.d/bind9 stop

Now that BIND is installed and not running, let’s create a new zone file for our custom TLD. For this example, I will be using “.node” as my TLD but feel free to use any TLD of your choosing.

cd /etc/bind

Paste the following into the file and edit any values you may see fit, including adding any domains with corresponding IP addresses. For a full explanation of these options visit which has a nice write-up on the format of a zone file. I did find that I needed to specify a NS SOA record with a corresponding A record or BIND would not start.

As you see below, a lot of this zone file is boilerplate but I did specify a record for “google” which signifies that “google.node” will point to the IP address “”

When you are done editing, save the file with CTRL-X.

       ; BIND data file for TLD “.node”
       $TTL    604800  ; (1 week)
       @       IN      SOA     node. root.node. (
       2015091220      ; serial (timestamp)
       604800          ; refresh (1 week)
       86400           ; retry (1 day)
       2419200         ; expire (28 days)
       604800 )        ; minimum (1 week)
       @         IN    NS    ns1.node.    ; this is required
       ;@        IN    A         ; unused right now, semicolon comments out the line
       google  IN    A
       ns1       IN    A         ; this is also required

Now, we need to edit the default zones configuration file to include our new zone.

nano named.conf.default-zones

A the bottom, paste the following block to add our new zone to the configuration.

zone “node.” {
                       type master;
                       file “/etc/bind/”;
                       allow-transfer { any;};
                       allow-query { any;};

Now find the block in the file similar to the below:

zone “.” {
               type hint;
               file “/etc/bind/db.root”;

Replace this block with the following to make our root server a slave to master root server This is one of OpenNIC’s public DNS servers and by marking it as a master, we can also resolve OpenNIC TLDs as well as any TLDs under control of ICANN.

zone “.” in {
                  type slave;
                  file “/etc/bind/db.root”;
                  masters {; };
                 notify no;

After saving the file, we want to generate a new root hints file which queries OpenNIC. This can be done with the dig command.

dig . NS @ > /etc/bind/db.root

Finally, restart BIND.

/etc/init.d/bind9 restart

You should see:

[ ok ] Starting domain name service…: bind9.

Configuration on the server on your Linux machine is now done!

Step 3. Configure Other Machines to Use Your Server

On your Windows machine (on the same local network), visit the Network Connections panel by going to Control Panel -> Network and Internet -> Network Connections.

Right-click on your current network connection and select Properties. On the resulting Network Connection Properties dialog, select Internet Protocol Version 4 (TCP/IPv4) if you are using IPv4 for your local network or Internet Protocol Version 6 (TCP/IPv6). Since I am using IPv4, I will be selecting the former.

Next, click the Properties button. On the resulting Internet Protocol Properties dialog, select the radio button for “Use the following DNS server addresses.” Enter the IP address of your Linux machine in the Preferred DNS server box ( from my example, but make sure you use the IP address of your Linux machine) and then click the OK button. Back on the Network Connection Properties dialog, click the Close button.

Now, load up a command shell and ping one of our defined domains.

ping google.node

You should see the following:

Pinging google.node [] with 32 bytes of data:
Reply from bytes=32 time=15ms TTL=55
Reply from bytes=32 time=17ms TTL=55
Reply from bytes=32 time=16ms TTL=55

Congratulations, you now have a DNS server which will not only resolve your custom TLD but be accessible to other machines.


This is just a proof of concept, and could easily be expanded upon for future projects. If you are wondering where to go from here, you could easily move on to make your DNS publicly accessible and expand the offerings. Further, you could construct multiple DNS nodes to act as slaves or links to your root server as a method of distributing the network to make it more reliable and geographically accessible

While I don’t think many BitTorrent trackers will be quick to adopt a system such as this, it still shows that you can create and resolve custom TLDs which may be useful for constructing alternative networks.




Automating Site Backups with Amazon S3 and PHP

This article was originally written for and published at TechOats on June 24th, 2015. It has been posted here for safe keeping.


I host quite a few websites. Not a lot, but enough that the thought of manually backing them up at any regular interval fills me with dread. If you’re going to do something more than three times, it is worth the effort of scripting it. A while back I got a free trial of Amazon’s Web Services, and decided to give S3 a try. Amazon S3 (standing for Simple Storage Service) allows users to store data, and pay only for the space used as opposed to a flat rate for an arbitrary amount of disk space. S3 is also scalable; you never have to worry about running out of a storage allotment, you get more space automatically.

S3 also has a web services interface, making it an ideal tool for system administrators who want to set it and forget it in an environment they are already comfortable with. As a Linux user, there were a myriad of tools out there already for integrating with S3, and I was able to find one to aide my with my simple backup automation.

First things first, I run my web stack on a CentOS installation. Different Linux distributions may have slightly different utilities (such as package managers), so these instructions may differ on your system. If you see anything along the way that isn’t exactly how you have things set up, take the time and research how to adapt the processes I have outlined.

In Amazon S3, before you back up anything, you need to create a bucket. A bucket is simply a container that you use to store data objects within S3. After logging into the Amazon Web Services Console, you can configure it using the S3 panel and create a new bucket using the button provided. Buckets can have different price points, naming conventions, or physical locations around the world. It is best to read the documentation provided through Amazon to figure out what works best for you, and then create your bucket. For our purposes, any bucket you can create is treated the same and shouldn’t cause any problems depending on what configuration you wish to proceed with.

After I created my bucket, I stumbled across a tool called s3cmd which allows me to interface directly with my bucket within S3.

To install s3cmd, it was as easy as bringing up my console and entering:

sudo yum install s3cmd

The application will install, easy as that.

Now, we need a secret key and an access key from AWS. To get this, visit and click the plus icon next to Access Keys (Access Key ID and Secret Access Key). Now, you can click the button that states Create New Access Key to generate your keys. They should display in a pop-up on the page. Leave this pop-up open for the time being.

Back to your console, we need to edit s3cmd’s configuration file using your text editor of choice, located in your user’s home directory:

nano ~/.s3cfg

The file you are editing (.s3cfg) needs both the access key and the secret key from that pop-up you saw earlier on the AWS site. Edit the lines beginning with:

access_key = XXXXXXXXXXXX
secret_key = XXXXXXXXXXXX

Replacing each string of “XXXXXXXXXXXX” with your respective access and secret keys from earlier. Then, save the file (CTRL+X in nano, if you are using it).

Now we are ready to write the script to do the backups. For the sake of playing different languages, I chose to write my script using PHP. You could accomplish the same behavior using Python, Bash, Perl, or other languages, though the syntax will differ substantially. First, our script needs a home, so I created a backup directory to house the script and any local backup files I create within my home directory. Then, I changed into that directory and started editing my script using the commands below:

mkdir backup
cd backup/
nano backup.php

Now, we’re going to add some code to our script. I’ll show an example for backing up one site, though you can easily duplicate and modify the code for multiple site backups. Let’s take things a few lines at a time. The first line starts the file. Anything after <?php is recognized as PHP code. The second line sets our time zone. You should use the time zone of your server’s location. It’ll help us in the next few steps.


So now we dump our site’s database by executing the command mysqldump through PHP. If you don’t run MySQL, you’ll have to modify this line to use your database solution. Replace the username, password, and database name on this line as well. This will allow you to successfully backup the database and timestamp it for reference. The following line will archive and compress your database dump using gzip compression. Feel free to use your favorite compression in place of gzip. The last line will delete the original .sql file using PHP’s unlink, since we only need the compressed one.

exec("mysqldump -uUSERNAMEHERE -pPASSWORDHERE DATABASENAMEHERE > ~/backup/".date('Y-m-d').".sql");
exec("tar -zcvf ~/backup/".date('Y-m-d').".tar.gz ~/backup/".date('Y-m-d').".sql");

The next line will archive and gzip your site’s web directory. Make sure you check the directory path for your site, you need to know where the site lives on your server.

exec("tar -zcvf ~/backup/".date('Y-m-d').".tar.gz /var/www/public_html/");

Now, an optional line. I didn’t want to keep any web directory backups older than three months. This will delete all web directory backups older than that. You can also duplicate and modify this line to remove the database archives, but mine don’t take up too much space, so I keep them around for easy access.

@unlink("~/backup/".date('Y-m-d', strtotime("now -3 month")).".tar.gz");

Now the fun part. These commands will push the backups of your database and web directory to your S3 bucket. Be sure to replace U62 with your bucket name.

exec("s3cmd -v put ~/backup/".date('Y-m-d').".tar.gz s3://U62");
exec("s3cmd -v put ~/backup/".date('Y-m-d').".tar.gz s3://U62");

Finally, end the file, closing that initial <?php tag.


Here it is all put together (in only ten lines!):

exec("mysqldump -uUSERNAMEHERE -pPASSWORDHERE DATABASENAMEHERE > ~/backup/".date('Y-m-d').".sql");
exec("tar -zcvf ~/backup/".date('Y-m-d').".tar.gz ~/backup/".date('Y-m-d').".sql");
exec("tar -zcvf ~/backup/".date('Y-m-d').".tar.gz /var/www/public_html/");
@unlink("~/backup/".date('Y-m-d', strtotime("now -3 month")).".tar.gz");
exec("s3cmd -v put ~/backup/".date('Y-m-d').".tar.gz s3://U62");
exec("s3cmd -v put ~/backup/".date('Y-m-d').".tar.gz s3://U62");

Okay, now our script is finalized. You should now save it and run it with the command below in your console to test it out!

php backup.php

Provided you edited all the paths and values properly, your script should push the two files to S3! Give yourself a pat on the back, but don’t celebrate just yet. We don’t want to have to run this on demand every time we want a backup. Luckily we can automate the backup process. Back in your console, run the following command:

crontab -e

This will load up your crontab, allowing you to add jobs to Cron: a time based scheduler. The syntax of Cron commands is out of the scope of this article, but the information is abundant online. You can add the line below to your crontab (pay attention to edit the path of your script) and save it so it will run on the first of every month.

0 0 1 * * /usr/bin/php /home/famicoman/backup/backup.php



[WANTED] Let’s Find All The TechTV VHS Tapes

TechTV, the 24-hour technology-oriented cable channel was a never ending source of inspiration to me when I was growing up. Back then, TechTV was only available in my area on digital cable, a newfangled platform that people didn’t want to pay the extra money for. By the time I had ditched analog cable, TechTV was long gone, absorbed into G4, with any programming carried over reduced to a shell of its former self.

Back in the heyday (2001-2002 for this example), TechTV decided to release direct-to-video VHS tapes of various one-off programs and specials designed as something of an informational/instructional reference. I remember these being advertised, and the concept excited me as it was a way to get TechTV content without needing the cable service. That said, I never got to view a single one of these tapes. Unfortunately, they were priced a just a little too high. It was a big financial investment for an hour of content.

Over a decade later, a few of these tapes have made their way online. By my research, I can find that TechTV produced six (Maybe more?) VHS tapes, three of which some kind souls have digitized and put on YouTube or The Internet Archive. But, that means that there are three other tapes out there which I or anyone else have a hard time getting at unless we want to spend a bunch of money working our way through Amazon resellers. Not something I want to do. To add to this, the digitized videos available online are not the best quality. Again, thanks to the kind souls who went through the trouble, but I would really like to see the maximum quality squeezed out of these bad boys. Over the years, there have been many efforts to find old TechTV recordings from over-the-air, but these tapes remain mostly lost.

Let’s try to fix that.

I’ve created a project page to track as much information as I can on these tapes and am looking for any people who can create digital rips themselves or send these tapes my way to rip. I can’t offer any money to buy them, but you’ll be doing a good service getting these videos out there. Once again, I would like to find fresh sources for each of the tapes listed if possible.

The titles I can find existing are as follows, let me know if I missed any:

  • TechTV’s Digital Audio for the Desktop (2001)
  • TechTV’s How to Build Your Own PC (2001)
  • TechTV’s Digital Video for the Desktop (2002)
  • TechTV Solves Your Computer Problems (2002)
  • TechTV’s How to Build a Website (2002)
  • TechTV’s How to Build a Website (2002)

    ChannelEM and TechTat are now Archived

    Since both TechTat and ChannelEM are essentially no longer updated, I didn’t want to have to worry about maintaining them on the server. I’ve backed up their installations, and created static html versions of each website which are now up at the URLs below.

    The static sites are not perfect, and may have some missing thumbnails, background images, or pages that were created on-the-fly by applications. Regardless, all the pages and their information should be intact. The original domains should work until I let them expire, but for now they will offer up a redirect to the new static sites. Neither Techtat nor ChannelEM ever got the traction I hoped they would, though they proved to be interesting projects when they were active. ChannelEM in particular, when it worked, worked very well and I would love to apply the approach of an online television station developed there to another project down the road.

    Until then, I’ll narrow my focus a bit, and continue my “Spring Cleaning” as best as I can.


    Archiving Radio

    A few months ago, I got involved with my university’s radio station. It happened unexpectedly. I was out with some friends in the city and two of us made our way back to the school campus. My friend, a member of the station, had to run inside to check something out and ended up calling me in because there was some older gear that he wanted me to take a look at. I was walked past walls of posters and sticker-covered doors to the engineering closet. The small space was half the size of an average bedroom, but was packed to the brim with decades of electronics. Needless to say, I was instantly excited to be there and started digging through components and old part boxes. A few weeks later, after emailing back and forth with a few people, I became something of an adjunct member with a focus in engineering. This meant anything from fixing the doorbell to troubleshooting server issues, the modified light fixtures, the broken Ms. Pac-Man arcade machine, or a loose tone-arm on a turntable. There are tons of opportunities for something to do, all of which I have found enjoyment in so far.

    Let’s take a step back. This radio station isn’t a new fixture by any means. I feel that when people think of college radio these days they imagine a mostly empty room with a sound board and a computer. Young DJ’s, come in, hook up their iPod, and go to work.

    This station is a different animal. Being over 50 years old means a lot has come and gone in the way of popular culture as well as technology. When I first came in and saw the record library contained (at a rough estimate) over 40,000 vinyl records, I knew I was in the right place. I began to explore. I helped clean out the engineering room, looked through the production studio, and learned the basics of how the station operated. After a few weeks, I learned that the station aimed to put out a compilation on cassette tape for the holiday season. One of the first tasks would be to get some 50 station identifications off of a minidisc to use between songs. Up to the task, I brought in my portable player and with the help of a male/male 3.5mm stereo cable and another member’s laptop, got all the identifications recorded. While the station borrowed a cassette duplicator for the compilation, it would still take a long time to produce all the copies, so I brought in a few decks of my own and tested some of the older decks situated around the station. It was my first time doing any sort of mass duplication, but I quickly fell into a grove of copying, sound checking, head and roller cleaning, and packaging. If felt good contributing to the project knowing I had something of a skill with, and large supply of old hardware.

    A little later, I took notice of several dust-coated reels in the station’s master control room containing old syndicated current-event shows from the ’80s and ’90s. I took these home to see if I could transfer them over to digital. I ran into some problems early one with getting my hardware to simply work. I have, at the time of writing, six reel-to-reel decks, all of which have some little quirk or issue except one off-brand model from Germany. I plugged it in, wired it to my computer via RCA to 3.5mm stereo cable, and hit record in Audacity. The end result was a recording in nice quality.

    Stacks of incoming reels

    Stacks of incoming reels.

    I decided to go a little further and use this to start something of an archive for the radio station. I saved the files using PCM signed 16 bit WAV, and also encoded a 192kbps MP3 file for ease of use and then scanned the reel (or box it was in) for information on the recording, paying attention to any additional paper inserts. I scanned these in 600dpi TIFF files which I then compressed down to JPG (again, for ease of use). Any interesting info from the label or technical abnormalities were placed in the file names, along with as much relevant information I could find. I also made sure to stick this information in the correct places for the ID3 tags. Lastly, I threw these all into a directory on a server I rent so anyone with the address can access them. I also started asking for donations of recordings, of which I received a few, and put them up as well.

    What's up next?

    What’s up next?

    After I transferred all the reels I could find (about 10), I went on the hunt for more. Now, until this point, I had broadcast quality 7-inch reels that ran at 7.5ips (inches per second) with a 1/4-inch tape width. A lot of higher quality recordings are done on 10.5-inch reels that run at 15ips, though sometimes 7-inch reels are used for 15ips recordings. Reel-to-reel tape can also be recorded at other speeds (such as 30ips or 3.75ips), but I haven’t come across any of these besides recordings I have made. Now, while my decks can fit 7-inch reels okay, they can’t handle any 10.5-inch reels without special adapters (called NAB hubs) to mount them on the spindles which I currently don’t have. Additionally, there are other tape widths such as 1/2-inch which I don’t have any equipment to play. The last problem I encounter is that I don’t have any machines that can run at 15ips.

    Next up...

    In progress.

    Doing more exploratory work, I got my hands on several more 7-inch reels and also saw some 10.5-inch reels housing tape of various widths. Some of the 7-inch reels I found run at 15ips, and while I don’t have a machine that does this natively, I’ve found great success in recording at 7.5ips and speeding up the track by 100% so the resulting audio plays twice as fast. As for the larger reels, I may be able to find some newly-produced NAB hubs for cheap, but they come with usage complaints. While original hubs would be better to use, they come with a steep price tag. There is more here to consider than might be thought at first. Additionally, there is a reel-to-reel unit at the station that though unused for years is reported to work and be able to handle larger reels and higher speeds. However, it is also missing a hub and the one it has doesn’t seem to come close to fitting a 10.5-inch reel properly. At the moment, there doesn’t look to be anything I can use to play 1/2-inch width tape, but I’m always on the hunt for more hardware.

    There are literally hundreds of reels at the station that haven’t been touched in years and need to be gone through, it’s a long process but it yields rewarding results. I’ve found strange ephemera: people messing with the recorder, old advertisements, and forgotten talk shows. I’ve also found rare recordings featuring interviews with bands as well as them performing. This is stuff that likely hasn’t seen any life beyond these reels tucked away in storage. So back to transferring I go, never knowing what I will find along the way

    Digitizing in process


    From this transferring process I learned a lot. Old tape can be gummy and gunk up the deck’s heads (along with other components in the path). While it is recommended to “bake” (like you would a cake in an oven) tape that may be gummy, it can be difficult to determine when it is needed until you see the tape jamming in the machine. Baking a tape also requires that it is on a metal reel while most I have encountered are on plastic. Additionally, not all tape has been stored properly. While I’ve been lucky not to find anything too brittle, I’ve seen some tape separating in chunks from its backing or chewed up to the point that it doesn’t even look like tape anymore. More interesting can be some of the haphazard splices which may riddle a tape in more than one inopportune spot or be made with non-standard types of tape. I’ve also noticed imperfections in recording, whether that means the levels are far too low, there’s signs of a grounding loop, or the tape speed is changed midway through the recording. For some reels there is also a complete lack of documentation. I have no idea what I’m listening to.

    I try to remedy these problems best I can. I clean my deck regularly: heads, rollers, and feed guides. I also do my best to document what I’ve recorded. I listen to see if I can determine what the audio is, determine the proper tape speed, figure out if the recording is half track (single direction, “Side A” only) or quarter track (both directions, “Side A + B”), and determine if the recording is in mono or stereo. Each tape that goes through me is labelled with said information and any information about defects in the recording that I couldn’t help mitigate.

    After dealing with a bad splice that came undone, I’ve also gone ahead and purchased a tape splicer/trimmer to hopefully help out if this is to happen again. As for additional hardware, I’m always on the lookout for better equipment with more features or capabilities. I don’t know what I’ll ultimately get my hands on, but I know that anything I happen to obtain will lend a hand in this archiving adventure and help preserve some long-forgotten recordings.

    After doing this enough times, I’ve started to nail down a workflow. I put all the tapes in a pile for intake, and choose one to transfer. I then feed it into the machine, hit record in Audacity, and hit play on the deck. After recording, I trim any lead-in silence, speed correct, and save my audio files. At this point, I also play the tape in the other direction to wind it back to its original reel and see if there are any other tracks on it. From here, I label my files, and go on to make scans of the reels or boxes before then loading these images into Photoshop for cropping and JPG exporting.

    All done.

    All done.

    It is a lot of work, but I can easily crank out a few reels a day by setting one and going about with my normal activities, coming back periodically to check progress. I have many more reels to sift through, but I hope one day to get everything transferred over – or at least as much as I can. Along the way, I’ve come across other physical media to archive. There are zines, cassette tapes, and even 4-track carts that are also sitting away in a corner, being saved for a rainy day.

    I’ll keep archiving and uncovering these long forgotten recordings. All I can hope for is that some time, somewhere, someone finds these recordings just as interesting as I do.

    Even if nobody does, I sure have learned a lot. With any luck, I’ll refine my skills and build something truly awesome in the process.


    Just Meshing Around

    This article was originally written for and published at Philly Mesh on January 28th, 2014. It has been posted here for safe keeping.

    The first time I remember hearing about mesh networks was sometime around 2005. Through rigorous searches, I had finally tracked down a complete run of Seattle Wireless TV, a proto-podcast that ran from July of 2003 until June of 2004. This hunt was undergone for my own personal interests; I was and am something of an online-video-series junkie, and I have since posted all the episodes for download on where they will be preserved for anyone to watch for years to come. The topics of these episodes varied from interviews with operators, to wardriving tips, and even antenna creation. Pretty popular topics back then, but now the show serves as a fantastic time capsule from a technologically-simpler time. Even ten years ago, “getting into” wireless networking seemed radically different. Everyone tried their hand at wardriving, embraced 802.11g, and wired cantennas to their Orinoco cards. Here is a prime example of the times — some Seattleites setting up their own mesh network in 2002. Essentially, Wi-Fi was king and you could have it in your own home. I didn’t end up jumping into the mix until years later. I got my first laptop in 2006 and even then I usually embraced a wired connection. Watching these video shows was my own little outlet into what the cool kids were doing. It wasn’t until a little later that I decided it was time to play.

    In 2007, I received a La Fonera router from Fon courtesy of a free giveaway (I actually managed to snag one on the very last day they offered the promotion). I thought it might be cool to join their Wi-Fi collective, but I was much more interested in what else I could do with the device. The day it came in the mail I promptly researched what others were doing with it and joined in on the popular act of flashing dd-wrt firmware onto the little device to get some expanded functionality. This process was harder than I expected and my lack of knowledge on the subject at the time showed. After many frustrating hours  flipping back and forth between telnet, tftp, and IRC chatter  I had a fully functioning dd-wrt router of my very own. While this was a feat all in itself, it went on to inspire me to see what I could do with other routers. I soon grew a little collection of second-hand Linksys WRT54G routers to tinker with and take up space on my work bench. I tried out different firmwares like OpenWrt and Tomato and always tried to keep something new running on a separate network for me to play with so I didn’t accidentally bring down the whole house’s internet access with a bad flash or misconfiguration.

    Years later, I ended up working with wireless technology in a professional capacity. However, I was no longer handling everyone’s favorite suite of 802.11 protocols but the new-fangled 802.15.4 for low-rate wireless personal area networks. I focused on the ZigBee specification and its derivatives, which were and are a popular choice for technologies like home automation systems, wireless switches, electrical meters, etc. I spent months toying with the technology, working to understand the encryption, capture and dissect the traffic, and create and transmit my own custom packets. While the technology itself was enough to hold my interest, I felt a draw toward the technology’s use of wireless mesh networking to create expansive networks.

    This wasn’t my first foray into the world of mesh networking per se. Prior to my work with ZigBee, I focused on meshing briefly to combat network interruption when creating the topology for a hobby-run IRC network I was administrating. This was, however, my first time applying mesh ideas wirelessly. I quickly learned the ins and outs of the Zigbee specification and the overarching 802.15.4 standard, but I couldn’t help thinking about how these technologies applied to Wi-Fi and how much fun an 802.11 mesh network would be.

    Soon, I discovered the existence of Philly Mesh, a Philadelphia-based mesh network in its infancy that connected with Hyperboria: a global decentralized network of nodes running cjdns. I made a few posts to its subreddit, added my potential node to the map, and ordered some TP-Link routers to play with. While the group seemed to be gathering support, it ultimately (and much to my dismay) stagnated. Expansion stopped and communication dwindled. People disappeared and services started to fall apart. Over the next year I tried to work through getting my own node up but hit several setbacks. I bricked a router, ran into configuration problems, suffered from outdated or missing documentation, and then bricked another router. Eventually, after a seemingly endless process of torment and discovery, I connected to the network using a Raspberry Pi. My first cjdns node was up.

    After this, I made a push to revive the Philly Mesh project. I constructed a new website, revived some of the services, and started my push for finding community involvement. Though it stands to be a slow process, things are coming together and people are coming forward. Whether or not we will have a thriving mesh network in the future is unknown, but the journey in this case interests me just as much as the destination.

    As of now, I’m embracing wireless mesh as a hobby. I still have a pile of routers to play with and test firmware on, and am getting new hardware every so often. As for the bricked TP-Links, I’ve picked up USB/TTL adapter in an attempt to correct my wrongdoings and get cjdns set up properly. I’m also constantly playing with my settings on the Raspberry Pi installation as I have to firewall things off, assure reliability for an application crash, and generally make sure things are running smoothly. Additionally, I’ve been toying around with different technologies to set up an access point through the Raspberry Pi such as a USB/Ethernet adapter to bridge a connection between an old router and the Pi, and a USB dongle to create an access point in a more direct model. Aside from the Raspberry Pi and assorted routers, I’m also interested in getting cjdns installed and configured on plug computers like the Pogoplug and single board computers like the BeagleBone Black.

    Where will all of this take us? Hopefully this is a stepping stone on the way to building a thriving local mesh, but the future is unknown. I’d love to get some nodes set up wirelessly within the city, but I’m only one person out in the suburbs tinkering away. While I’m sitting here learning about setting up devices, I only hope to share what I find with others who might benefit from having someone else carve out an initial path. I, by myself, can work to build a local mesh but it wouldn’t be nearly as robust or expansive as if I worked within a team sharing ideas and experience.

    If you’re reading this, you have the interest. You may not have the know-how, the money for high-tech equipment, or a location nearby other potential operators, but you have the desire. If there’s anything that I’ve learned throughout my ongoing mesh adventure, it’s that good things take time and nothing happens overnight.

    Tomorrow, we can work to build a strong mesh for our city. As for today, why don’t we get started?


    Helping Aaron – A Vintage Computer Adventure

    This article was originally written for and published at Philly 2600 on December 23rd, 2013. It has been posted here for safe keeping.

    It’s rare that I get overwhelmed. I’m not talking about stress or anything like that. It’s rare that my senses get overwhelmed, specifically my sense of sight. This past Saturday, that sense became overloaded.

    I’ve known Aaron for a little while now. We met online somehow in 2012, and while I don’t remember the exact details, I think he started following me on Twitter and things went on from there after I followed him back and we started replying to each other’s tweets. We quickly figured out that we lived pretty close to  one another, which I found humorous considering we were both into archiving and preservation. Who would think that I’d be geographically this close to another person who idles in the #archiveteam IRC channel, online headquarters for the team dedicated to rescuing any and everything in the way of data? Aaron and I hit it off pretty well, and we eventually ended up meeting (somewhat unexpectedly) at Pumpcon 2013. Later, I ran into him again at the BSides Delaware conference and shortly thereafter he started coming to the Philly 2600 meetings which I’ve been frequenting for some time.

    About two weeks ago, Aaron approached me via an online message and asked if I would like to go through some old computers at a local nonprofit he is on the Board of Directors for, NTR. NTR is in itself a fantastic organization which provides both refurbished computers (done in-house from donations) and hands-on computer training to low-income Philadelphia residents. If you are employed by or know a company in the area that is retiring their current fleet of workstations, consider donating the old machines to NTR. And, if they ultimately cannot use the machines, they will ensure that they are recycled in an environmentally safe fashion.

    Aaron thought that I would be the right guy to help out. Being someone that preserves old technology, rescues it from unknown fate, and is a general enthusiast about it, I couldn’t resist the urge to come out and see what I could uncover. The details I got about what I was to do left a lot to my imagination. I got a location, we  settled on a time, and I was told to wear clothes I wouldn’t mind getting dirty and bring a set of work gloves. Hardhats would be provided.

    The dirt and grime never bother me. Just what I would be working with, I didn’t know. But, I was excited nonetheless and on the morning of Saturday I walked on over to NTR and met Aaron out front. The building we would go on to enter was the former site of the hackerspace The Hacktory before they moved to a larger location. The building itself is a big old warehouse that is much larger inside than it looks from the street. The parking lot to the side is encased with giant stone walls almost as high as the building itself and easily fits a dozen cars without having anybody blocked in. Aaron tells me that the building has also been declared a historical site, meaning they can’t do a lot of modification to it directly, but they do keep it nicely maintained.

    As Aaron lifts one of the giant metal doors encased in the building’s western wall, I get my first look into NTR. He shows me bins of donated computer equipment: smaller stuff like peripherals lovingly stacked in re-purposed milk crates and small amounts of desktop computers stacked together up the side of the two-story wall. I get a tour of all the classrooms, a look into the computer thrift store they run out of the same building, and dozens of other rooms and hallways that wind around the giant space, separated by heavy opaque sliding doors. Eventually we make our way into the main computer storage area where there are pallets upon pallets of donated machines on giant shelves that Aaron points out to me with a flashlight. It’s dark in this part of the building.

    We then go up to the second floor to see Stan, who is the Executive Director Emeritus of the organization, having initially been the Executive Director starting in 1980 and taken on the Emeritus title more recently. Stan himself is energetic and charismatic and goes on to tell me about how he set up a community information store on South Street in the 1970’s as we head down to where we came in to the building to the relatively new looking wooden steps that will lead to the area that Aaron and I will be looking through for the next few hours. Aaron later explains that much like me, Stan has been collecting and preserving technology and computer history, though he has been doing it for considerably longer. Some of his collection is also mixed in with the stuff we will be digging through.

    I put on my gloves and snag a hardhat out of milk crate on a shelf by the stairs before Aaron and myself head up. The stairs are steep and don’t seem to be spaced consistently. You feel like you could fall down them easily but the railing is firm enough to keep you steady. As we make it to the top, I peer into the sea of computers which I will be acquainting myself with, lit by a pair of metal lamps that are clipped on to the wide beams of the underside of the roof – an afterthought in this 40×20 foot space.

    A shot behind me after I made my way off the stairs

    A shot behind me after I made my way off the stairs

    I quickly realize I can’t stand up all the way and have to hunch over, but that isn’t nearly as assaulting as the dust that comes out from seemingly everywhere and permeates through the air thick like smoke. Aaron walks slowly forward with his flashlight in hand and I follow close behind as he points out different areas of the space. We see newer stuff like a few Dell servers and stacks of Intel-based PCs at first but as we go further in we take more steps back in time. Aaron shines his light on a pile of all-in-one Macs before going further to the more interesting artifacts. On the left are some more modern machines, followed by boxes upon boxes of various documents, computers, and peripherals. I see Kaypros with Commodores with IBM clones and crazy displays for systems I can’t even fathom. There are tons of Macs, a few Mac clones, Apple ][s, and some old portable computers the size of suitcases. There are bags of electronics: half finished projects from decades before, muddled in with 8-bit personal computers, a pile of Sun workstations, and boxes of 5.25″ floppy disks. On the right side are more Macs: G5s, G3s, a dozen classic Macs, some older desktops and a seemingly endless collection of obscure monitors and terminals to other systems. This is where we start.

    A view of the left side

    A view of the left side

    A claustrophobic shot of the beginnings of the right side

    A claustrophobic shot of the beginnings of the right side

    We navigate down the narrow path separating the space straight through the middle and get acquainted with the Mac area. We line up rows of milk crates and start digging, sorting along the way. Put the classic Macs here, put modems in this bin, mice in that bin, terminals over here, MIPS-based hardware over there. We sort and sort and sort, moving the heavy machines slowly as we work another path into the mess. The day was a cold one, but we quickly discarded our jackets as we carried hardware along the narrow aisle we carved out; we were warm enough simply moving back and forth, ducking beneath low hanging beams and swiveling around waist-high stacks that created our own personal obstacle course. As we went, we stopped to appreciate anything interesting we happened to find. Almost immediately we come across a monitor for a NeXTcube (though we didn’t find the cube itself) and we dug up other odd monitors and software packages and interesting little add-on boards that most people have probably long forget. We pooled our expertise and our energy and sorted in a long sprint.

    After we cleared a new path

    After we cleared a new path

    Cleared path continued

    Cleared path continued

    Aaron told me that a lot of this stuff will ultimately be cleared out. The newer stuff didn’t necessarily belong there and could be assimilated downstairs or recycled while the less valuable systems would be readily sold at their retail store. Some of the rarer pieces would be donated to museums or sold to enthusiasts and collectors who appreciate them to  ensure their longevity. I hope when the time comes I might fit into this last group. The amount of history in this room is simply breathtaking.

    View from the far corner

    View from the far corner

    After a brief break, we pushed back against the section we were using for trash so we had more room to sort. Ultimately, we successfully cleared space more terminals and bins upon bins of manuals – hard copies are always under-appreciated. We then moved around, more slowly, to some of the more obscure hardware – testing a few things as we went. More time in this stretch was just spent digging as opposed to organizing. We wanted to see what was in some of the giant boxes at the bottoms of the stacks. We didn’t want to leave any stone unturned. Who knows what would be tucked away? We sorted through some IBM clones, found an Amiga 2500, a Wang Terminal, a Vector Monitor, a Silicon Graphics Indy, a whole mess of Kaypros and some more interesting items like a computer for those with disabilities and a strange keyboard or computer that neither of us could quite figure out. Down below us, people were trickling in for a computer class in one of the many rooms. “Who here has internet access at home?” I heard an instructor ask before I accidentally knocked over a PowerPC Mac. Hopefully they didn’t mind the noise.

    Delta Data IV "Cherry." Keyboard or 8-bit computer?

    Delta Data IV “Cherry.” Keyboard or 8-bit computer?

    SGI Indy

    SGI Indy

    Stack of Altos 580's on some Kaypros next to a Commodore 128

    Stack of Altos 580’s on some Kaypros next to a Commodore 128

    We finally succumbed to the tech and called it quits for the day. We got a good idea of what was up in the area and talked about the next steps which are likely to be inventorying and testing (though there can probably be some more organization in the meantime). The space itself serves as a fantastic time capsule and it is a breath of fresh air to know that some of the stuff in there is just in there – and in good condition. However, there is much to be done and many more hours to devote to make sure everything is handled properly.

    As we rounded out the end of our excavation, we threw down the hardhats and unhanded the once-clean work gloves before walking around the corner for a cup of coffee. As we took our first steps away from the building, I felt a sense of accomplishment. We were archaeologists returning from our first day at an excavation. We uncovered some great finds, having fun along the way.

    With any luck, I’ll be asked back. There’s a lot to go through and I can’t help but think that there’s more I can offer. Never before had I been able to lay my hands on some classic pieces of hardware that I had only read about, and it was quite an experience being able to put the pieces together.

    Univac / Sperry Rand keyboard

    Univac / Sperry Rand keyboard

    “Age means nothing today,” Stan told me earlier that morning. “In this day and age, things are moving so fast.” I can’t say that I disagree, but I consider myself lucky to have the experience and knowledge under my belt when it comes to vintage computers.

    And with any hope, I can keep expanding it.



    A shot of the left side from out path in the Mac section

    A shot of the left side from out path in the Mac section

    Another shot of the left side

    Another shot of the left side

    Some newer Intel-based PCs

    Some newer Intel-based PCs

    More of the Mac area

    More of the Mac area

    Newer computers tucked away

    Newer computers tucked away

    More Macs, pink note states that this Mac was the second produced

    More Macs, pink note states that this Mac was the second produced

    Sun workstations, Macs, Apples, old laptops

    Sun workstations, Macs, Apples, old laptops

    RadioShack diskettes. Think the warranty is still good?

    RadioShack diskettes. Think the warranty is still good?

    5.25" diskettes

    5.25″ diskettes

    Close-up of the Altos 580's

    Close-up of the Altos 580’s

    A lone Kaypro II

    A lone Kaypro II

    Wang terminal

    Wang terminal

    A Tandy and a terminal

    A Tandy and a terminal

    The Amiga 2500 and an Apple monitor

    The Amiga 2500 and an Apple monitor

    Unknown brand keyboard

    Unknown brand keyboard

    Vector display

    Vector display

    Timex personal computer

    Timex personal computer

    Another Kaypro II and a Kaypro 10

    Another Kaypro II and a Kaypro 10


    Hacking History – A Brief Look Into Philly’s Hacking Roots

    This article was originally written for and published at Philly2600 on November 4th, 2013. It has been posted here for safe keeping.

    The tech scene in Philadelphia is booming. We have local startups like Duck Duck Go and TicketLeap, and we have co-working spaces like Indy Hall and Philly Game Forge. We have hackathons like Apps for Philly Transit and Start-up Weekend Health, and we have hackerspaces like Hive 76 and Devnuts. We have user groups like PLUG and PSSUG, and we have conferences like Fosscon and PumpCon. We have events like Philly Tech Week and TEDxPhilly, and we have security meet-ups like PhillySec and, yeah, Philly 2600. The hacker spirit is alive and well in the city of brotherly love, but where did all of this pro-hacker sentiment come from? What came before to help shape our current tech-centric landscape?

    It’s surprisingly difficult to approach the topic from the present day. I haven’t been there since the beginning, and the breadcrumbs left over from the era are few and far between. We are left with hints though, but usually from more analog sources. The first issue of 2600 that includes meeting times is volume 10, issue 2, from 1993. Philly 2600 is listed here with numerous others (making the meeting at least 20 years old), but how long did the meeting exist before this? We also know that Bernie S., longtime 2600 affiliate, was the founder of the Philadelphia 2600 chapter. Other than that, there is little to find on paper.


    First listing of the Philadelphia 2600 meeting in 2600 Volume 10, Issue 2 (1993).

    But what else can we dig up? We do have some other little tidbits of information that apply themselves to the history of Philly 2600. The film Freedom Downtime (2001) has some footage taking place at Stairway #7 of 30th Street Station, the original meeting location. There are also mentions of the meeting in the book Hacker Diaries: Confessions of Teenage Hackers (2002), where one story places a student at the 30th Street meeting in the late 1990’s. More recent references, such as the current 2600 magazine meeting listings have the meeting location moved to the southeast corner of the food court – the location used previous to the current location some 50 feet away.

    Mention of Philadelphia 2600 meeting from The Hacker Diaries: Confessions of Teenage Hackers (2002).

    Mention of Philadelphia 2600 meeting from The Hacker Diaries: Confessions of Teenage Hackers (2002).

    But what about the people who attended? It’s hard to keep track of this aspect, and as time goes on people come and go. Some come for one meeting and are never seen again, but some stick around a while. Eventually, there are no remains of the previous group – the meeting goes through generations. We can get a little information from simple web searches. Old Usenet listings can be a great source for material, here’s a Philadelphia 2600 meeting announcement from 1995 by The Professor. Even more interesting, here’s a Phrack article by Emmanuel Goldstein (publisher of 2600) talking about how he and three others brought Mark Abene (Phiber Optik) to the Philly 2600 meeting before having to drop him off at federal prison in Schuylkill.

    Using Internet Archive’s Wayback Machine, we can get an interesting perspective on the members from ten years ago by visiting an archived version of the old website (also at this domain). This is actually something we can explore. It appears that as of mid 2002 to regulars were JQS, Kepi Blanc, Damiend LaTao, Dj`Freak, The Good Revrend Nookie Freak, and GodEmperor Daeymion. Before this, regulars included Satanklawz (former site admin at the time) and Starkweather before the site was passed on to Kepi Blanc. The archived website offers an incredible amount of information such as a WiFi map of the city, several papers, and even (incredibly tiny thumbnails of) meeting photos. It’s clunky and full of imperfections but this website offers a time-capsule-like look into Philly 2600’s past.

    The old Philly 2600 logo

    The old Philly 2600 logo

    But what about other hacker origins in the area?

    We know of Pumpcon, one of the USA’s first hacker conferences started in 1993 (almost as old as DEFCON). Pumpcon has been running for over 20 years with an invite-only status. It is often overshadowed and left in the dust by the larger conferences in the country, despite its stature as one of the first of its kind. Pumpcon has not been exclusively held in Philadelphia since its inception. The conference has previously been held in Greenburgh, New York and Pittsburgh. Pumpcon has no central repository of information (why would it?) but a lot of history can be found scouring the web through old ezine articles like this one about Pumpcon being busted and notices like this one announcing Pumpcon VI. I’m currently compiling as many of these resources as I can, but there is an immense amount of data to sift through. Below I have some hard copy from my collection: A review of Pumpcon II from the publication Gray Areas and the incredibly recent Pumpcon 2012 announcement.

    Pumpcon II Review (Page 1/2) from Gray Areas Vol. 3 No. 1 (1994)

    Pumpcon II Review (Page 1/2) from Gray Areas Vol. 3 No. 1 (1994)

    Pumpcon 2012 Announcement

    Pumpcon 2012 Announcement

    Other groups are harder to find. Numerous groups started up, burned brightly, and were then extinguished. Who knows where those people are now or the extent of what they accomplished. There are of course a few leftovers. One of my own pet projects is the development of an archive of older hacker magazines. A previously popular publication in particular, Blacklisted! 411, sheds a little light on some long-lost Philly hackers. A few issues make reference to Blacklisted! meetings taking place at Suburban Station in Philadelphia and another at the Granite Run Mall run by thegreek[at]hygnet[dot]com (long defunct) in neighboring Delaware County (and surprisingly about five minutes from my house). The earliest occurrence of these meetings I can find of this is in volume 3, issue 3 from August 1996 but either may have started earlier.

    Philadelphia/Media Blacklisted meeting listings from Blacklisted! 411 Vol. 3, Issue 3 (1996).

    Philadelphia/Media Blacklisted meeting listings from Blacklisted! 411 Vol. 3, Issue 3 (1996)

    There are a few other loose ends as well. The recent book Exploding The Phone (2013) by Phil Lapsley catalogs the beginnings of the phreak culture, and makes reference to several fone phreaks in PA, some more notable than others, including Philadelphia native David Condon and some unidentified friends of John Draper (Cap’n Crunch) around the time he was busted by Pennsylvania Bell. We additionally know that some of the main scenes in the previously mentioned Freedom Downtime were filmed in Philadelphia. We also know that there are were hundreds of hacker bulletin board systems in the area from the 1980’s through the 1990’s.

    Bell Pennsylvania joke advert, from Exploding the Phone (2013)

    Bell Pennsylvania joke advert, from Exploding the Phone (2013)

    Let’s change gears now. Our main problem in moving forward is what we do not know. Stories and events have been lost as time goes one, and the hopes of finding them becomes dimmer with each passing year.

    If you had some involvement with the Philadelphia hacking scene in the years past, tell someone. Talk to me. Let me interview you. Get your story out there. Share your experiences – I’m all ears.

    Those of you out there hosting meetings and starting projects, keep a record of what you’re doing. This is my one request.

    We’ve already lost a lot of history. Let’s try saving some.


    Mining Bitcoin for Fun and (Basically No) Profit, Part 4: Aftermath

    If you have not done so already, please read parts 1, 2 & 3 of this series.

    As of writing this, I’ve spent one week running my setup with one USB Block Eruptor and one week running my setup with three. In my first week, I received about two payouts of 0.01 bitcoin each while in the second week I received that payout almost daily.

    The current average Bitcoin rate in USD (as of this writing) is $144.99322. This means my payout, one hundredth of that value, is $1.4499322. Now, this doesn’t sound like too bad of a payout. However, there is a lot to consider when figuring out whether or not I will actually make any money off of this in the long run.

    First, we have to consider that the price of a bitcoin is constantly fluctuating. When I started this project, the exchange rate was ~$119.00 USD. This amount could change at any time as the value inflates or deflates. Next, we have to consider the change in mining complexity – as more people start mining, the harder it will be. This is not only a problem of competition, the difficulty of generating a block increases systematically every 2016 blocks (roughly two weeks) Thus, as time goes on, you’ll make less money.

    Aside from these variable rates, we have some constants to think about. The initial investment wasn’t enough to break the bank, but it wasn’t anything to ignore.

    Recall our initial build list, this time with some prices:

    • 1 x Raspberry Pi ($35 + $4.98 shipping = $39.98)
    • 1 x ~4GB SD Card ($5.01 + $0 shipping = $5.01)
    • 1 x Micro USB Cable ($2.60 + $0 shipping = $2.60)
    • 1 x Network Cable ($5.49 + $0 shipping = $5.49)
    • 1 x Powered USB HUB ($19.95 + $0 shipping = $19.95)
    • n x USB Block Eruptor (($42.99 + $3.99 shipping) * 3 = $140.94)

    Total = $213.97 USD

    Pretty big when you put it all together, but this is worst case scenario – when you don’t start with anything. I already had most of this around the house. Besides the USB Block Eruptors, I did need to purchase a USB hub, but I wouldn’t consider this part of my investment as I needed one anyway (the project more or less gave me an excuse to get it). I’m more concerned with making back my money from the Block Eruptors, which total $140.94 USD.

    Next, we should consider power requirements. Again, this doesn’t matter to me much, I’m just focused on earning back money for the USB Block Eruptors, but let’s hook the whole rig up to my Kill A Watt electricity usage monitor and see what it says.

    Kill A Watt reading for kWh over 44 hours.

    Kill A Watt reading for kWh over 44 hours.

    The Kill A Watt states that the consumption is 0.55 kWh, this was taken over a period of 44 hours. Now let’s say our monthly electricity rate was 15 cents per kWh. We can plug all of those numbers into this handy formula: 0.55 kWh / 44 hours * 732 hours [hours in a month] * $0.15 [price per kWh] = $1.37 per month. So overall the power cost isn’t too bad, especially compared to old GPU rigs.

    Okay, now we know the power consumption, have our initial costs, are mindful of the changing rates, etc. How do we put it all together?

    The Genesis Block has created the Mining Dashboard just for this sort of thing. We can plug in all of our information here and see what’s what. They do have some fields for power, but that doesn’t take into account the Raspberry Pi and the hub. Plug in what matters to you. You cannot retroactively compute values, so I’ll have to base my start in September. However, this doesn’t take into account that I’ve already mined $9.96 (in the current exchange rate), so I’ll subtract that from my investment of $140.94 to get $130.98. It’s a dirty workaround, but this is an estimate after all. After putting in all the values, hit ‘Calculate.’ Here are my results:

    My Mining Dashboard projection.

    My Mining Dashboard projection.

    From the projection, I will never break even and will forever be $44 in debt because my setup will be completely obsolete in around 10 months time.

    Now as I said, this is a projection but it’s likely closer to being accurate than it is to inaccurate. I likely won’t make my money back unless the value of a bitcoin continues to rise and/or the mining complexity grows at a slower rate (which is unlikely).

    I’m not the only one in this boat. As more and more powerful ASIC rigs are being produced, the window for profit gets smaller and smaller. Some new ASICs sold now won’t even be able to turn any profit for owners because the time between ordering and arrival leaves too small a window to mine back the initial investment at the current complexity.

    While it is unfortunate to (likely) not turn a profit, this still proved to be a fun and incredibly interesting project. I may not have come out of it with financial wealth, but the ability to look down at my little Raspberry Pi chugging away (actually turning electricity into money, who knew?) was completely worth the time and effort I put into it. I’ll likely end up sitting on the bitcoins I mine now for a little while, just like I did back when my wallet got its first deposit. I’m more infatuated with mining and collecting the currency than I am with spending it, at least for right now..

    Hopefully you, one way or another, have learned something from my little journey.

    I know I did.


    Mining Bitcoin for Fun and (Basically No) Profit, Part 3: Mobile Development

    If you have not done so already, please read parts 1 and 2 in this series.

    So I have a mining rig that’s successfully rewarding me with bitcoins. Normal people would probably stop at this point. One nice thing about mining in Slush’s Pool is that it has a handy email notification option that tells you when credit is being transferred to your Bitcoin wallet. This is pretty cool, but what if I want more in-depth information? For example, what if I want to know my hash rate, or if my miner is alive (did the system crash?) or how many bitcoins I have total?

    The next step for me was to create a mobile application which could provide all this information – whenever or wherever I wanted it. So, I got to work.

    The platform I chose to work with was Android. A logical choice for me as I had prior experience developing Android applications and own an Android phone myself. Programming for Android, as many know, means programming in Java. If you have any prior Java experience, you’re already have a head start if you ever wanted to get into Android development.

    A fantastic thing about Slush’s Pool is that it offers an API (Application Programming Interface) which allows users to pull down information on their miners using the de facto JSON format. So from this I can get at my mining information, but what else do I want? I decided it would be wise to pull down the average value of a bitcoin in USD, at any given moment. This way, I can do some simple calculations to determine a rough estimate of how much I’m generating and getting payed in USD. Lastly, I wanted to get the balance of my Bitcoin wallet, again to be displayed in both Bitcoin and USD.

    I already had the API information for Slush’s Pool, as it is linked on everyone’s profile and accessed via a common base url and unique key for each user. Here is an example of the JSON output for my account:

        username: "Famicoman",'
        rating: "none",
        confirmed_nmc_reward: "0.00000000",
        send_threshold: "0.01000000",
        nmc_send_threshold: "1.00000000",
        confirmed_reward: "0.00145923",
        workers: {
            Famicoman.worker1: {
                last_share: 1378319704,
                score: "70687.6038",
                hashrate: 1004,
                shares: 1906,
                alive: true
        wallet: "1DVLNHpcoAso6rvisCnVQbCFN8dRir1GVQ",
        unconfirmed_nmc_reward: "0.00000000",
        unconfirmed_reward: "0.00612688",
        estimated_reward: "0.00046390",
        hashrate: "1006.437"

    Next, I needed an API for the average value of a bitcoin in USD. I went on the hunt. Finally, I found that Mt. Gox, the largest Bitcoin exchange, has a public API for bitcoin rates (located at this ticker URL). This works perfectly for my needs. Here is some sample JSON output from this API:

        result: "success",
        return: {
            avg: {
            value: "143.97798",
            value_int: "14397798",
            display: "$143.98",
            display_short: "$143.98",
            currency: "USD"

    So far, so good.

    Lastly, I wanted wallet information. I discovered that Blockchain shows records of transactions (as they are all recorded in the block chain), so I did some probing and found they also offered an API for attributes of individual wallets (Here’s a link using my wallet info, it’s all public anyway). This includes balance, transactions, etc. The units for bitcoins here is the Satoshi, one millionth of a bitcoin. Some sample JSON output from this service looks like so:

        hash160: "88fd52ba00f9aa29003cfc88882a3a3b69bfd377",
        address: "1DVLNHpcoAso6rvisCnVQbCFN8dRir1GVQ",
        n_tx: 7,
        total_received: 8434869,
        total_sent: 0,
        final_balance: 8434869,

    So now I had the APIs I was going to use and needed to put them all together in a neat package. The resulting Android application is a simple one. Two screens (home and statistics) with a refresh button that pulls everything down again and recalculates any necessary currency conversions. Android does not allow you to do anything system-intensive on the main (UI) thread anymore, so I had to resort to using an asynchronous task that spawns a new thread. This thread is where I pull down all the JSON (in text form) and get my hands dirty manipulating the data. I utilize a 3rd party library called GSON to parse the data I need from the JSON string. Then, it’s just a little bit of math and we have all the necessary data. After all of that is done, the application prints everything on the screen. Pretty basic, and with plenty of room for potential additions.

    When running the application, provided there’s network connectivity and all the servers are up, you will be rewarded with a screen like this:

    The app in action

    The application in action

    Not too shabby. If you wanted to use it yourself, it would be necessary to hard-code your own key from Slush’s pool. There doesn’t appear to be an API call by username (by design), so it needs to be implemented manually at some point (which happens to be in code as of right now).

    The source for this application, which I call SlushPuppy, is freely available on GitHub. Feel free to fork it, or just download and mess around with it. If anything, it provides a small example of both Android-specific programming as well as API interaction.