A Brief History of Blockchain Name Systems

This past weekend I attended the Aaron Swartz Day Hackathon at the Internet Archive in San Francisco. This event, which celebrates the life and work of Aaron Swartz, is organized in multiple cities around the world every year around the time of Aaron’s birthday (November 8). Since 2015, I have been attending the SF event and giving variations of a talk about blockchain name systems.

Here’s the description of this year’s talk:

Aaron Swartz once published a blog post entitled “Squaring the Triangle“, hypothesizing that a blockchain could be used to create a name system that had secure, decentralized, and human-readable names, thus “squaring” Zooko’s Triangle.

Since that post was published, numerous blockchain name systems have been developed, putting Aaron’s idea into practice. This talk will give a brief overview of the most popular blockchain name systems in production and show some of their applications.

Systems covered include Namecoin (the OG BNS), Blockstack, and the Ethereum Name System. Without further adieu, here’s a video of my talk from Aaron Swartz Day 2017 Day 2, A Brief History of Blockchain Name Systems.

 

 

Aaron was an incredibly inspiring individual, and it was a great honor to be invited to speak at this special event celebrating and building on his legacy. If you have a chance to attend one of these events in a city near you, I encourage you to go and participate!

RIP Aaron Swartz, you are gone but not forgotten.

Join the herd on Mastodon

May 2017 update: I haven’t yet found a good workflow for cross-posting from birdsite to Mastodon, and I still don’t have a large network on Mastodon, so I have mostly stopped using it. I’ll keep checking in and posting now and then, but I do not see it becoming my new mainstay any time soon. Regardless, I will continue giving feedback in hopes that it will evolve into something that is “sticky” for me because birdsite is birdshit.

A few months ago I saw Aral Balkan tweet about a new social media app called Mastodon. With a Tweetdeck-like interface and compatibility with the GNU Social federation, I found the app easy enough to use, with a large network of interesting people to follow. I followed some people, sent my first “toot” (I am not sure if messages were called a “toot” yet) and… did not ever use the app again. This is not unusual: I’ve signed up and played around with many decentralized social apps before and most often I won’t use them more than once.

mdon

Today, something unusual did happen: I logged back in. I am officially a repeat user of Mastodon. Today, a bunch of people joined the network and it even got some press. So I dusted off my login credentials and went to check in on how things are going. Mastodon hasn’t changed much in the intervening time period but there are some subtle yet important improvements (such as 2FA support – gg).

I haven’t had a chance to look through every issue on GitHub or review every companion app so these might have been suggested or done already but here are the features that would make the app stickier for me:

  • A mobile client
  • Post scheduling
  • Post to/from other networks (including the big centralized ones)
  • Add search columns (and other types of columns that Tweet deck offers)
  • Mute whitelist (so you will see toots from people on your whitelist who would otherwise be muted)
  • Easy self-host options for muggles (e.g. Sandstorm is great)
  • Blockstack support (decentralized DNS, PKI, storage)
  • Search-by-word (this was intentionally not done for mastodon.social)
  • Data analytics and visualization tools (I ❤ dataviz)
  • And of course, a bigger network.

I’m probably missing a bunch of other things that I won’t notice until I use Mastodon more. There is a tool you can use to find the people you follow and who follow you on Twitter that helps with bootstrapping your network. I will see if I can add Mastodon to my Blockstack ID so people who use that can find me on Mastodon. And I might even continue using the app to find and share content. Toot me.

Bitcoin tips accepted:

Bitcoin address (what’s this?)

18CTU2EdrPC7DA77BSdorW7sVF4ZJaTVco

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

New year, new job

Yesterday I published a post on the Abra blog announcing that I have joined the company to help “extend [cash on- and off-ramps for Bitcoin] globally.” Most of the details about why I made the decision to join Abra are in that post, but for my friends who I’m sure will have more questions, I’m putting together an FAQ to answer questions about the new job and how it affects other projects I’ve been working on.

Why Abra?

I really like the team and the company’s mission. As I mentioned in the post on Abra’s blog, I started the Buttonwood SF meetup to make it easy and safe for people in my local community to get cash in and out of the Bitcoin network, and now I’m excited to work with Abra to make that possible worldwide.

What will happen to Buttonwood SF?

I actually turned over control of the meetup page to a prominent local bitcoin trader a while ago because I was traveling a lot for work and figured he’d be a better steward. Eventually he stopped paying the meetup dues and no one else in the community stepped up to take over. So right now the meetup page is inactive. But some of the folks in the community still meet to trade, and in the future we might decide to either reactivate the meetup page or create a new online community portal somewhere else so people can easily find the meetup. If you have any interest in helping with this, please get in touch!

Are you still working with Bitseed?

Yep! Bitseed has been a passion project of mine since we first started, and I don’t intend to change that any time soon. We’re working on the next iteration of the Bitseed node now, mostly focused on finding new hardware that can increase the power of the node and new use-cases that can be served by having a personal server self-hosted at home. If you have any ideas or want to help out in any way, please get in touch! We’re especially looking for software devs who are interested in helping us with the Bitseed Web UI and working on new software for Bitseed 3. To stay up-to-date with all Bitseed developments, you can subscribe to our newsletter.

When is the next edition of Bitcoin: Be Your Own Bank coming out?

I can’t say for sure! I plan to re-write a lot of it and add a couple new chapters. I am waiting for a couple of projects to do their first public releases before adding them to the book. After that, it should only be a month or two before the Second Edition is ready to be published. So I anticipate it will be ready by the end of the year, at the latest. Subscribe to the BYOB blog for updates.

Are you still working with Blockstack?

Yep! I’m not as active in the community as I used to be, but I still hang out in the forum and Slack and eagerly await all the software releases that the Blockstack community is working on. There’s a lot of really cool stuff happening there and I encourage everyone to at least follow the Blockstack blog and Twitter account to get alerts for important Blockstack announcements – you won’t want to miss it!

Will you still be working with the okTurtles Foundation?

Yep! I plan to publish a follow-up to my blog post about open-source Slack alternatives, and am also looking forward to helping them test the first public release of the Group Income app. If you would like to help support the Foundation’s mission to support beneficial decentralized technology, we appreciate all donations and volunteers!

Fin

I think that answers all of the important questions I can think of. If you have any others, let me know!

Bitcoin tips accepted:

Bitcoin address (what’s this?)

19ocrFSLF6S3ke5eAEUgV38rBz1ENGdbgo

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

Securing Bitcoin Core with Blockstack

Update September 15, 2016: I would like to thank the Bitcoin Core and Blockstack Core developers who have responded to this post in the threads here, here, and here. I will update this post again if I receive more relevant feedback.

A message recently appeared on the bitcoin.org website warning visitors that:

Bitcoin.org has reason to suspect that the binaries for the upcoming Bitcoin Core release will likely be targeted by state sponsored attackers.

The warning does not provide any evidence to back up these claims or specify what kind of attack will be attempted. However, the warning does suggest a mitigation tactic:

The hashes of Bitcoin Core binaries are cryptographically signed with this key.

We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries.

The focus on the use of signing keys, signatures, and hashes of the Bitcoin Core binaries to mitigate the risk of installing malware leads to the following assumptions:

  • The Bitcoin Core developers are not compromised.
  • The private signing keys of the Bitcoin Core developers are not compromised.
  • The computers the developers use to build the binaries are not compromised.
  • The SSL/TLS connections used to secure the download links for the public signing keys, signatures, and hashes are not compromised.

The conclusion here is that the author of the warning is concerned about an attack where the binaries available for download through official channels will be swapped out for malware, and users who do not check the signatures or hashes risk having their computers infected.

Note: here is a good discussion about the warning on the r/bitcoin subreddit.

Traditional mitigation tactics

The mitigation tactics suggested by the warning rely heavily on SSL/TLS to protect the integrity of the public signing keys, signatures, and hashes that users are expected to check against. Unfortunately, this is not enough to protect against a determined attacker. If the bitcoin.org website is compromised, then any information hosted on the site is suspect. It is also possible for an attacker to compromise an SSL/TLS connection by compromising a Certificate Authority and issuing a fake SSL certificate. The attacker would then use the fake certificate to launch a man-in-the-middle attack on people visiting the target website, in this case to trick them into downloading fake keys, signatures, and hashes (and possibly fake binaries as well).

If users don’t trust the bitcoin.org website or the Certificate Authorities that secure the connection used to download the Bitcoin Core signing keys, then there are two other verification methods that can be used: direct verification or the PGP Web-of-Trust. Direct verification is the strongest method, but can also be the most inconvenient. Users have to verify the PGP fingerprint of the signing key directly with the developer whose key they are trying to verify. This is challenging because it doesn’t scale well. Not everyone is able to meet developers directly, and it would be unproductive for developers to spend all their time verifying their keys with everyone who asks.

One way to scale direct verification is for developers to publish videos where they say their key fingerprints out loud. As long as people trust that the people in the videos are actually the developers and that the videos haven’t been tampered with in any way, this could work quite well. Another way to scale direct verification is through the Web-of-Trust. With the Web-of-Trust, user download the key they want to verify and then use PGP software to see if anyone they trust has signed the key in question to attest to its authenticity. If no one the user trusts has signed the key, or signed the key of someone who signed the key, etc, then the user needs to find someone they trust who they can use to create a chain of trust back to the key in question. Eventually, the user would find someone who trusts someone who trusts… the key in question.

Downsides of traditional mitigation tactics

Both direct verification and Web-of-Trust verification methods are effective, but can be inconvenient. Most users expect software to “just work,” without having to do any extra work to verify the integrity of the software. These verification methods also have a shelf-life. It is standard practice (and good crypto hygiene) for developers to rotate their signing keys after a certain period of time, creating a new keypair every so often to stay one step ahead of attackers. Every time a new keypair is created, the verification process has to be repeated by everyone who trusted the old keypair (unless everyone still trusts the old keypair, in which case developers can just sign their new public key with their old private key to indicate ultimate trust for the new keypair).

What if there was a way for Bitcoin developers to secure updates to their software with the same level of assurance provided by Bitcoin itself, and the same ease-of-use as popular applications like email? This is possible today with software called Blockstack, a decentralized key-value store built on Bitcoin.

Blockstack verification

Blockstack can combine the benefits of direct verification and the Web of Trust with the ease of use of popular apps like email by linking signing keys to easily-memorable usernames. A Blockstack username, also called a “blockchain ID,” is owned by a bitcoin address. Records associated with the blockchain ID are stored in a file called a “zone file” and cryptographically linked to every Blockstack transaction using the OP_RETURN field. These records can contain any information the user wants to provably link to their blockchain ID.

In this example, the user is a Bitcoin Core developer named Alice, and Alice wants to link her PGP signing key to her blockchain ID. These are the steps Alice would take to secure the next release of Bitcoin Core:

  1. Obtain a trustworthy copy of Bitcoin Core. This is easy for Alice because she is a Bitcoin Core developer. It is harder for other users due to the aforementioned challenges, but the good news is that a trustworthy copy of Bitcoin Core only needs to be obtained once for this method to work forever (assuming no epic pwnage, etc etc).
  2. Obtain a trustworthy copy of Blockstack. Same caveats as mentioned in step 1.
  3. Assuming the username isn’t taken yet, use Blockstack to register the blockchain ID alice in the .id namespace. The full blockchain ID is then alice.id.
  4. Create a PGP keypair if she doesn’t already have one yet. This will be used to sign software binaries, hashes, and other important messages.
  5. Update the zone file record for alice.id to include the fingerprint of her public signing key and a link to the key itself so that it is easy to find. Once the zone file update is confirmed in the blockchain, anyone can use Blockstack to look up the new contents of the zone file.
  6. Advertise ownership of alice.id as publicly as possible. Tell all her collaborators over secure channels, publish messages confirming ownership of alice.id on social media, conference presentation slides, business cards, etc. Anyone who can verify the authenticity of these messages can then use Blockstack to look up alice.id and retrieve Alice’s up-to-date public key. This key will then be used to verify the signatures on updates to Bitcoin Core.

Alice could go even further and register a blockchain ID for Bitcoin Core itself, then update the zone file to include the blockchain IDs of all the other Bitcoin Core developers, as well as the hashes of the latest Bitcoin Core software. The bitcoin address that owns the Bitcoin Core blockchain ID could be a multisignature address that requires signatures from multiple Bitcoin Core developers to update the zone file, preventing Alice from becoming a central point of failure. This is essentially a way to secure Bitcoin software with Bitcoin itself – very meta.

Once Bitcoin Core developers have established a jointly-controlled blockchain ID, users will be able to use the Bitcoin Core blockchain ID as the authoritative source for Bitcoin Core updates without having to rely on untrusted third parties like Certificate Authorities or go through the hassle of direct contact or the Web of Trust every time they need to verify a signing key.

Putting theory into practice

I have taken the initiative to register a blockchain ID for Bitcoin Core: bitcoincore.id. If the Bitcoin Core developers want to use this ID for the purpose described in this post, I am happy to donate bitcoincore.id to the project. To claim the ID, Wladimir J. van der Laan will need to send me a message signed by a key that I can confirm with any of the Core developers in the SF Bay Area who trust Wladimir’s key and are willing to meet me in person to confirm the key. This message must indicate a desire to claim bitcoincore.id and contain the bitcoin address that Wladimir wants me to transfer the ID to.

By the time I receive such a message from Wladimir, I will assume that he has familiarized himself with Blockstack and understands how to use the software. The exact protocols used to govern control of the blockchain ID address, updates to the ID, and contingencies in case private keys are compromised are to be determined by Wladimir (likely through consultation with the Bitcoin Core community).

Further reading

More information about the shortcomings of Certificate Authorities, how Blockstack works, and ways this technology can be applied to concepts like the PGP Web-of-Trust can be found in the following links:

Blockstack white paper – describes how Blockstack works.

Blockstack documentation – describes what Blockstack is and how to use it.

Decentralized Public Key Infrastructure white paper – describes how blockchains and similar technologies “address[] many usability and security challenges that plague traditional public key infrastructure.”

DNSChain – a similar project that pre-dates Blockstack and uses blockchains to fix SSL/TLS vulnerabilities.

DNSChain white paper – describes the problems with SSL/TLS and how DNSChain can fix them.

How to Decentralize Uber

It has been an oft-cited example that Ethereum can be used to create a “decentralized Uber,” and there have been several (as-yet unsuccessful) attempts to do just that. But what does creating a decentralized Uber actually entail? In this post, I propose that a) Ethereum is overkill for the task at hand, and b) decentralized Uber is not as sexy as it sounds, and may or may not actually make sense in the real world.

What Uber Is Today

Uber is a business that bundles several services together to create a seamless transportation application:

  • Technology development. Uber employs engineers and designers to make sure that all of Uber’s technology works to their standards, including server- and client-side applications for drivers and passengers. Uber also does R&D to test new business models, new app features, and new products.
  • Order matchmaking. When people press the button on their Uber app to catch a cab, their GPS location is broadcast to Uber’s servers where the order is algorithmically matched with a driver whose own Uber app is also broadcasting their GPS location to Uber’s servers. Once the order is matched and the driver accepts the order, the driver is told where the passenger is located. The passenger can also see where the driver’s car is at and follow their movement to the passenger’s location. Both are provided a communication link to each other via a proxy phone number so they can resolve any issues while the driver is en route to pick up the passenger.
  • Payments. Once the ride is over, credit/debit card payments are processed through the Uber application using a third-party payment processor called Braintree, a subsidiary of PayPal.
  • Insurance. While drivers are required to carry their own valid insurance with minimum coverage amounts, Uber also provides an umbrella insurance policy that covers any gaps while passengers are riding in the vehicle. In some states, companies like Uber and drivers that use their network are mandated by law to carry an insurance policy that meets certain minimum coverage levels.
  • Quality control. Uber checks to make sure drivers have a valid driver’s license, runs background checks to make sure drivers do not have a violent criminal history or a poor driving record, verify that drivers have valid insurance with enough coverage, and monitor both driver and passenger ratings to ensure that quality standards are being met by members of Uber’s network.
  • Customer service. If the driver or passenger has a serious problem with the transaction, they can escalate the issue to Uber customer service for resolution. Customer service is also responsible for following up if the driver or passenger reports a forgotten item in the vehicle.
  • Ancillary benefits and services. In addition to all the core services mentioned, Uber also uses its scale and reach to negotiate bulk discounts on many ancillary services for drivers such as healthcare, automotive maintenance, cell phone plans, and other products and services. Uber helps drivers obtain vehicle financing so that they can acquire a car to drive for Uber, and also lobbies governments to enact policies that are favorable for Uber (and usually, by extension, drivers and passengers) or oppose policies that are not favorable.

What Decentralized Uber Is Not

Decentralized Uber is not everyone broadcasting their location onto a blockchain and getting matched up by algorithmic oracles based on location proximity and bidding on the best price for a ride.

  1. Putting people’s current location and destination on a public blockchain is bad for privacy and personal security. People already get upset when they’re faced with the realization that Uber can track all of its users in real time.
  2. Putting people’s current location and destination and bids for fares on a public blockchain does not scale well and will be really expensive.
  3. Ridesharing is an inherently local service, so orders do not need to be broadcast to the whole world.
  4. Bidding for fares is a concept tried by the failed ridesharing startup Sidecar and has proven to add too much friction to the process. It is also an inherently different model than the intentional simplicity of Uber’s “press one button to hail a cab” model.

In short, Ethereum is not needed to build a decentralized Uber because most user interactions in a decentralized Uber app would happen off-chain, and Bitcoin supports all the on-chain interactions needed today.

What Decentralized Uber Could Be

Decentralized Uber – let’s call it “Doober” – is an unbundled Uber, with the possibility for redundancy in some areas to prevent there from being a central point of control or failure. Different companies can each be used for app development, background checks, GPS monitoring, insurance, matchmaking, payments, customer service, and additional benefits and services, and then aggregated together with the Doober app. These services could be re-bundled where it makes economic sense to do so, though it is possible many parts of the system will remain decentralized for economic or practical reasons.

Blockchain?

The blockchain is indeed a key component of the Doober application, but not in the way that has been previously envisioned. Doober uses the blockchain only for identity and payments, delegating the task of order matchmaking to a network of private servers called Matchmaker servers. Drivers and passengers can then choose which servers they trust with their location data.

Blockstack is a key-value store database that uses the blockchain as a decentralized mechanism for determining the order of database updates. Think of it like a global file directory with a trusted root in the blockchain e.g. alice.id/zonefile/apps/gps/link or alice.id/zonefile/apps/reputation. Blockstack is the glue that binds all of our unbundled services together in a decentralized way where the user remains in control.

Blockstack would be used to register a unique identity on the blockchain – called a “blockchain ID” – and link that identity to: public keys for message authentication and encryption; reputation ratings from other drivers and passengers; official endorsements for statements like “I have a valid driver’s license,” “I have valid insurance with this much coverage,” “I do not have a violent criminal history,” etc; and a link to a GPS API endpoint – all the components needed for a Decentralized Uber-like system.

How Decentralized Uber Could Work

  1. Register a blockchain ID like “alice.id” then link the blockchain ID to the Doober application.
  2. Link a public key, called an “ID Key,” to the blockchain ID and use the corresponding private key to sign and decrypt messages linked to the blockchain ID. This is how messages from the blockchain ID owner are authenticated. The ID key will go into Blockstack like alice.id/zonefile/id-key-fingerprint/public-key.
  3. Have an identity verification service sign tokens indicating that the person who controls the blockchain ID has provided proof of a valid driver’s license, insurance with adequate coverage, and no history of violent behavior or car accidents. Link these tokens to the blockchain ID. These tokens will go into Blockstack like alice.id/zonefile/apps/endorsements.
  4. Register for a unique GPS API endpoint service with the blockchain ID and link the unique GPS API endpoint to the blockchain ID. This endpoint will go into Blockstack like alice.id/zonefile/apps/gps/endpoint-url.
  5. Register an account with a Matchmaker server. The account will be linked to the blockchain ID and is authenticated with the ID Key. Each Matchmaker can have different policies regarding driver and passenger requirements e.g. background checks, insurance, minimum reputation ratings, etc. Drivers and passengers can register with multiple Matchmaker servers, and servers could federate for redundancy and scale. Users will give permission to each registered Matchmaker to access the user’s GPS location only when the Doober app is on and waiting to give or receive a ride.
  6. Passengers can broadcast orders to multiple servers at the same time. If an order is matched on multiple servers, then the customer can either manually choose which order they want to commit to, or they can set automated policies to choose for them. Drivers will then get pinged by the Matchmaker server(s) when they get a ride request, and can accept or deny the request.
  7. Payments can take place on-chain or (more likely) using a Layer 2 system like the Lightning Network. The Matchmaker or other pre-determined arbitrator could be a signatory on a multi-sig transaction between the driver and passenger to prevent either from getting ripped off. Of course, they could also use any other agreed upon payment method.
  8. Issues are resolved either by insurance companies or Matchmaker customer service (or both, or some other third party – this can all be negotiated manually or automatically beforehand via the Doober app). Matchmaker servers can broker reputation exchanges and keep track of the complete reputation history to ensure that quality standards are met. Drivers and passengers can link their reputation history to their blockchain ID so that it is easily portable. If the reputation rating of a driver or passenger falls below a pre-determined threshold, the Matchmaker can suspend or delete their account. Matchmaker servers can gossip the reputation ratings of blockchain IDs with other Matchmaker servers to help prevent hit-and-run/exit scam scenarios.

As you can see, there are quite a few steps involved, but really not that mcuh more than is involved with signing up for Uber today. Whether decentralizing Uber like this is worth the extra friction for customers or actually solves any real problems is up for debate.

I think there’s value in giving people more choice about who they share their data with, and breaking people out of silos and proprietary networks gives them more leverage to control their online relationships. The fact that there can be redundancy between Matchmaker servers via federation could make the Doober network more resilient against censorship in jurisdictions that do not have a favorable view of companies like Uber. Then the targets of regulators will have to be drivers and passengers instead of big companies like Uber, the same way end-users of BitTorrent are the target of copyright enforcement instead of BitTorrent Inc. Is this is a good thing or a bad thing? Maybe time will tell.

Anyways, that’s how I would decentralize Uber.

Synchronicity

It’s been a while since my last post; so much has happened that I’ve hardly had any time to stop and consider the awesomeness of it all. Towards the end of 2014, I began working with the okTurtles Foundation to help them with a crowdfunding campaign that they’d been planning. I met okTurtles co-founder Greg Slepak after I became interested in his DNSChain project and reached out to interview him for my P2P Connects Us podcast. Shortly after this interview, Greg posted a blog post about how okTurtles needed a fundraiser, and I offered to help.

As I have previously discussed on this blog, identity is an important part of the human experience, and I believe people should have a more secure alternative to the legacy identity systems in use today where someone else is in control of our identities. Whether by a website, an employer, or a government, identities have been controlled by third parties for too long. DNSChain, to me, looked like an opportunity for individuals to break free of that control, and I was – and still am – happy to support that effort.

Around the same time that I started working with the okTurtles Foundation, I began having conversations with my friend Harlan about projects we were working on and daydreaming about what it would look like if we put our ideas together. We started talking about what a “decentralized application stack” would look like, something that could be used to build a bunch of different apps – photo sharing, messaging, collaboration, etc – which could all seamlessly interoperate with open protocols. Harlan called it “the last social network,” because it would make all the centralized, proprietary walled gardens that people mistake for their social networks irrelevant.

This idea excited me, so I got to work jotting down some ideas and Harlan built a website that pulled all the info off of GitHub. We ended up calling the stack “DStack,” short for “Decentralized Stack.” All I did was point to some projects that already existed and said, hey if we put these all together somehow, we could build a lot of cool apps on top which are completely decentralized. We would just need something for user identities, some way to store and transfer user data, and interfaces for the apps. Then Harlan and I both got busy with other projects, and we haven’t really touched DStack since.

Around this same time, in early 2015, I met an entrepreneur named Jay Feldis through my friend Mike Doty, who I knew from the local bitcoin meetup. Jay and Mike had been working on a product they called “CoinBox,” since rebranded to “Bitseed,” which was essentially a small computer that you could use to host blockchain full nodes for mining, staking, or just relay transactions on one of these networks. Jay presented a Bitseed prototype at a bitcoin meetup hosted at the Internet Archive, and I was intrigued by the possibility for Bitseed to solve the problem of low bitcoin node count by giving users an easy way to run their own full node.

Jay and Mike were working with a guy from SoCal named Konn Danley, who was helping them build the ecommerce store for Bitseed, and they just needed someone to help out with writing content for the website. I had some free time so I offered to help. When the website was almost done, I scheduled a tweet to go out a few days later, went back to work writing content for the site, and promptly forgot about the tweet.

Right on time, the tweet auto-posted and ended up going semi-viral, getting over thirty retweets on Twitter while a Reddit post about Bitseed simultaneously shot to the front of r/bitcoin. Bitseed was out of stock within 48 hours. It seemed there was demand for plug-and-play bitcoin full node hardware, validating our initial hypothesis. The Bitseed team then went to work over the next few months fulfilling orders and working on version two of the device.

During the R&D period for Bitseed v2, I was invited to join a new community of decentralized application developers called Blockstack. The mission was to build common infrastructure for the development of decentralized applications, a common “decentralized stack,” if you will. Sound familiar? I had found my tribe! I soon started helping them out, writing content for the website and inviting more people to join in the effort. Summer 2015 has been, for me, the summer of Blockstack.

Today, the Blockstack community is comprised of some of the smartest and most talented developers working on decentralized applications today, growing to include developers from 2WAY.IO, Bitmarkets, Bitseed, Chord, Creative Work, Mine, Nametiles, OB1, the okTurtles Foundation, Stampery, Tierion, and ZeroNet. Developers for these projects have all have faced daunting challenges when thinking about how they will develop their applications – start building components from scratch? Use this or that library? Is this the right tool? Can that software be optimized for building decentralized applications? As Blockstack matures, many of these questions will be answered for developers, who will then be able to focus on building beautiful interfaces and great user experiences instead of worrying about infrastructure development and maintenance.

Using Blockstack, developers will be able to create decentralized versions of popular online services like AmazonYoutube, Twitter, and Reddit, and even a whole new way of publishing and browsing websites, all while costing less in time and deployment costs then was previously possible. Developers will be empowered to eliminate central points of control and failure in their applications, weaknesses which have previously led to Internet censorship, repression of political or social dissent, mass surveillance, billions of dollars in financial losses, and hundreds of millions of compromised identities.

As I recently mentioned on a panel at the American Banker Digital Currencies and the Blockchain conference, decentralized applications change the economics of hacking by eliminating the ability to compromise millions of accounts with one successful hack; instead, criminals will have to hack into every device owned by individuals in a network of potentially millions of people, meaning that the hacker has to work that much harder, most likely making the attack cost more than it’s worth. Combined with payment systems like bitcoin, which can enable microtransactions, do not require identity information to work, and are not subject to chargeback fraud, Blockstack could be used to build a new kind of network that is more secure and more resilient than the web 2.0 that came before it.

For all these reasons and more, Bitseed and okTurtles have both joined the Blockstack effort. At Bitseed, we believe our dedicated full node device is a natural fit for software like Blockstack, and we look forward to working with the community to spread Blockstack nodes far and wide. In the spirit of the Blockstack mission to collaborate on common infrastructure, Onename recently announced they are working with the okTurtles Foundation to merge their blockchain ID projects and help advance the state of the art of decentralized identity technology.

Bitseed and okTurtles will both be participating in the first Blockstack community event, Blockstack Summit 2015 at NYU in New York City on September 12th. This event will bring together over a hundred of the top developers working on decentralized applications and blockchain technology today. I’m helping to organize Blockstack Summit, and couldn’t be more proud and excited about the great lineup of presenters, panelists, and attendees who will be participating in this event.

Blockstack is effectively taking the late-night conversations I had with Harlan from dream to reality, with actual working code and a vibrant, enthusiastic community contributing to the effort. There are still some issues to iron out, particularly around the exact definition of the stack and the governance of this new community organization, all which we plan to discuss and work towards resolving at Blockstack Summit. I believe that if we work smart enough and agree on a shared vision, this community has the passion and talent to make something truly amazing and world-changing. If this sounds like something you want to be a part of, I invite you to join our community and come say hello at Blockstack Summit.