The Bitcoin Name System (BNS) has gained a lot of popularity due to the explosion of the .btc namespace.
What many users don’t know is that BNS started on Bitcoin L1 in 2015 and even has a pre-history on Namecoin going back to 2014—a whole three years before the Ethereum Name Service was founded.
Further, some BNS users who have .id names on the Stacks Network today can trace their names all the way back to that beginning in 2014, making .id names on the Stacks Network some of the oldest “NFTs.”
But how did BNS get its start? And how do the same users still have their names from 2014?
Our story begins with a decentralized app called OneName.
2014: Muneeb and Ryan start BNS on Namecoin
In March 2014, Muneeb Ali and Ryan Shea created the open-source Bitcoin Name System (BNS) and launched the OneName app as a registrar and client of that system—like a decentralized GoDaddy—where users could register and manage their BNS names.
Those names—and associated information like a Bitcoin address—were stored on the Namecoin blockchain in the custom /u namespace.

At a technical level, OneName was one of the first decentralized apps where users had control of their private keys. It simply enabled users to interact with the underlying BNS system.
OneName was originally billed as “The Decentralized Whitepages for Bitcoin.” (source)

So instead of copying and pasting a long, hard-to-read address to send Bitcoin, OneName users could simply look up a BNS name, which would then return the associated Bitcoin address—similar to how a web browser resolves “Google.com” to an IP address with the DNS system.
OneName was not, however, the only app that integrated BNS.
Bitcoin wallets—like RushWallet and Electrum—integrated BNS too, which meant users could send Bitcoin to a name like “satoshi.id” (instead of a long address) without leaving their wallet. This substantially improved the user experience of sending and receiving Bitcoin.
In addition to wallet integrations, notable early adopters of OneName and BNS included Naval Ravikant, Arianna Simpson, and Fred Ehrsam. So OneName was getting some good traction.
That’s partly because Muneeb and Ryan went through Y Combinator in the Summer 2014 batch, raising $1.45 million from Union Square Ventures (Fred Wilson), SV Angel, Barry Silbert, Naval Ravikant, and other prominent VCs. (source)
Beyond connecting a Bitcoin address to their BNS name, users could also associate other pieces of information, including a PGP key, a bio, a website, and social media accounts.
Again, all of this information was stored with the name on Namecoin in the custom /u namespace.
This worked OK for a while, but there were issues with spam and squatters on Namecoin.
One way the OneName developers dealt with this was by enabling linking social media profiles, personal websites, etc. to your BNS name and verifying them on the OneName app with public proofs—like a tweet from your personal Twitter account or a TXT record attached to your site’s domain name.
So a lot of tweets like this started to appear:

The more profiles you linked to your BNS name and verified with OneName, the more certain others could be that your BNS name was actually yours. (You wouldn’t want to send Bitcoin to an impostor!)
For example, here is the OneName profile of noted VC and entrepreneur, Naval Ravikant.

You can see that he had proven associations with his Twitter, Facebook, and GitHub accounts, making it highly likely that naval.id was actually him.
Sidenote: You may notice that usernames were formatted with a leading plus sign. On BNS, +naval became equivalent to naval.id.
However, the developers had other issues with Namecoin:
- Throughput: They had issues getting transactions to go through quickly.
- Security: F2Pool controlled 60%+ of the mining power, making Namecoin vulnerable to 51% attacks.
- Space limitations: Namecoin was limited to 512 bytes per entry, so multiple entries were needed for names with a lot of data (bio, PGP key, profiles, etc.).
- Blockchain size: Namecoin was rapidly increasing in size, threatening its long-term decentralization and usability.
- Protocol limits: Namecoin names expired every 10 months, and the price structure was rigid.
For these reasons, the developers decided to change their architecture and migrate BNS to Bitcoin: most popular, secure, and robust blockchain.
2015: Migrating BNS to Bitcoin L1
On February 17th, 2015, Ryan Shea tweeted a link to a blog post on a new type of data store that would enable BNS name operations anchored to Bitcoin with the OP_RETURN field.

Because Bitcoin’s OP_RETURN was limited to a mere 40 bytes (versus Namecoin’s 520 bytes), the plan was to only store essential information on Bitcoin—”logging” BNS registrations and operations with short entries and hashes.
Information attached to a name, such as a Bitcoin address, a bio, or social media accounts, was then to be kept in a “zonefile” on external nodes.
A zonefile hash or signature would then be stored on the Bitcoin L1 so that a node operator could not lie. For example, by replacing a Bitcoin address with their own.

Some notes on nomenclature: After extensive discussion on Github and other places, it was officially decided that the name BNS should be used. There has been some confusion about what BNS stands for, but over the years a consensus emerged that BNS stands for Bitcoin Name System.
BNS is a name system. The rest of the technology stack got the name Blockstack, a.k.a. “the blockchain application stack,” and evolved as an open-source project.
With BNS, it was possible for anyone to create a namespace by burning Bitcoin. It was also possible to specify expiration and pricing rules for that namespace, which the team did for the first time on September 8th, 2015, when they burned 40 BTC to create the .id namespace:

Some on Reddit speculated that the 40 BTC were burned due to a bug. But the OneName team then finalized the .id namespace creation with namespace-reveal and namespace-ready transactions.
And on September 10th, they began migrating names from Namecoin to Bitcoin:

Two days later, on September 12th, Muneeb Ali announced that migration from the /u namespace on Namecoin to the .id namespace on Bitcoin had been taking place.

Then an official announcement of the migration was made on the OneName blog on the 15th of September, citing issues with Namecoin and giving instructions for independent BNS users to migrate their names to Bitcoin.
Under the .id namespace on BNS for Bitcoin L1, users would pay renewal fees in BTC, and names would expire every 2 years.
Names kept being migrated from Namecoin to Bitcoin in real time until December 2015, when the OneName app stopped supporting the Namecoin /u namespace.
So everyone who had a /u name on Namecoin now had a .id name “registered” on Bitcoin L1 with BNS.
2016-2017: Beyond BNS: Decentralized Infrastructure
In early 2016, the early developers behind BNS started expanding the scope of use cases and, instead of just focusing on decentralized names and identities, shifted to building a user-owned internet and the decentralized infrastructure for it.
To introduce this vision to the world, Muneeb Ali gave a presentation at Usenix ATC 2016 titled “Blockstack: A Global Naming and Storage System Secured by Blockchains.”
This was really a natural progression. Once they had developed decentralized ID and a scalable storage solution for larger files (no longer storing data on Namecoin), they had all the pieces not just for BNS and identity, but for a whole new decentralized internet.

They started communicating that this would do two things: 1) let users own their ID, reputation, and data; and 2) let developers quickly deploy and change applications without having to worry about storage and identity management.
An additional $4 million in fundraising in January 2017 enabled them to pursue this expanded vision.
And by May 2017, the developers had built a stand-alone client app that functioned as a new browser for Web3: “A Gateway to a New, Decentralized Internet.”

With the release of the desktop client, the team notified web app (OneName app) users by email that they’d need to migrate their .id names to the new desktop app.
Names that were imported to the desktop client were renewed for an additional two years, free of charge.
2018-2020: The Stacks Network is Born
Bitcoin transactions were slow and expensive. So in late 2017, the developers started working on a more scalable Bitcoin layer for BNS and other operations.
This new Bitcoin layer was called “Stacks” in a whitepaper published in late 2017.
The team had closed out 2017 with a successful $50 million token sale for STX, adding a lot of fuel to the new Stacks project.
The plan was to use STX as a “gas token” to pay for network operations, including the execution of smart contracts.
In 2018, the team distributed STX tokens with an early version of the Stacks Network, and R&D work for Stacks 2.0 was actively moving forward. This included the development of the Clarity smart contract language and Proof-of-Transfer (PoX), the new consensus mechanism.
For BNS users (including those with .id names), not much changed in this timeframe. They could use, update, and renew their names as usual with the command-line interface or desktop client.
In October 2020, to simplify branding and avoid any name confusion, the project name officially became the Stacks project, and the original company behind it became “Hiro Systems” to prepare for the upcoming decentralization and narrow the focus on developer tools.
By December, it was announced that Stacks Layer was “feature complete,” a.k.a. almost ready to launch.
2021: Stacks Mainnet Launch
January 14, 2021, was a huge day for those with BNS names and the Stacks Network as a whole:
- The Stacks mainnet launched, with smart contracts enabled with the new Clarity language.
- BNS was rewritten as a smart contract in the Clarity language.
- BNS names, including those in the .id namespace, were distributed to the historical owners in the genesis block.
So, at this point, if you had registered a name on Namecoin in 2014, it was almost seven years old, having transitioned from Namecoin to Bitcoin L1 and finally to the Stacks L2!

The .btc Namespace is launched
On June 2, 2021, the .btc namespace launched on Stacks with the btc.us registrar, and a mad dash to register names ensued.

Twitter users began registering thousands of .btc names and changing their Twitter names to show off their new names, much like many .eth owners did.
2022: BNS Trading and Secondary Marketplace Takes Off
Because BNS had some technical limitations, it took until 2022 for a strong secondary market to form.
In October, NFT Marketplace Gamma.io shipped a solution:

This kicked off a new BNS craze, which led to the creation of a BNS DAO, bots that track sales, and a huge increase in the number of names being registered.

2023: BNS Upgrades and Integrations
As of early 2023, 86% of all BNS names belong to the .btc namespace, with almost 230,000 .btc names registered!

The community has continued to create additional integrations for BNS, including a wrapper contract called BNSx that allows a single wallet to hold multiple names.
And Leather Wallet (formerly Hiro) has enabled the sending and receiving of Bitcoin with BNS names.

So in a way, BNS is now right back where it originated in the OneName days: allowing users to send and receive Bitcoin with usernames instead of long and cumbersome addresses.
We expect 2023 to bring a lot more wallet integrations for BNS (as well as other app integrations).
In short, the years 2014–2017 can be thought of as the time when developers played around with Bitcoin L1 and learned about its scalability and programming limits. Starting late in 2017, work on Stacks as a new Bitcoin layer began. And after 3 years of R&D (2018–2020), the Stacks mainnet launched in early 2021.
The Stacks network is now very decentralized, with over 30 independent entities. The sBTC launch and Nakamoto release are the next big planned upgrades for the network and will bring increased interoperability with Bitcoin.
We can’t wait to see what else is in store for BNS and Stacks!
Special thanks to Jude C. Nelson for pointing us in the right direction, and to Muneeb Ali for his extensive input for this article.