Overview
BNS is currently the most popular contract in the STX ecosystem. As one of the first contracts that were launched, it is filled with tons of limitations, but it doesn’t mean it’s wrong; it is important to remember that certain design decisions were made by brilliant engineers and there are several good reasons why one-name-per-address; you can have more context on this GH issues #37 and #2211
The Main Problem
The million-dollar question is, “How do we upgrade the BNS contract?” currently, it has the following constraints:
- It is a hassle to take BNS handles into custodial. According to @friedger someone deployed 500 contracts in a marketplace before, which is not ideal. (chain congestion due to STX limitations)
- Another pain point is the UX from Hiro Wallet, where users see a lot of code.
- Currently, BNS only allows 1 handle per address. This results in a lot of dormant addresses being created in STX, and we don’t want that as an ecosystem. A user sometimes owns 300 addresses just for this.
- ATM, the current BNS working group, is also missing in action @larry
The Proposed Solution vs. The New?
There are various conversations about the approach, and we keep going back and forth; it’s been two years, people, let’s bite it, keep building and solve this.
One approach was from @jude who proposed we do not need to change BNS
One-name-per-address in BNS does not prevent you from making separate identifiers, nor does it stop you from writing an app that registers names to your BNS keychain.
There is no client-side algorithm to stop users from accidentally sending multiple in-flight name-registration transactions to the same address. Please stop assuming that there is. I’m not going to entertain technical solutions that depend on this mythical algorithm’s existence. The best we can do is deal with the consequences. - Jude Nelson
Ask: Make BNS names tradeable.
Solution: Due to the existence of a block limit, there can be at most N name trades per block. So, we can instantiate a set of N escrow contracts to facilitate pair-wise trades. The seller transfers ownership of the name to an agreed-upon contract, and if the contract is paid by the buyer within B blocks, it transfers the name to the buyer and transfers the payment to the seller. There only need to be NB such contracts, and they only need to be instantiated once. Any pair of users Alice and Bob can decide which contract to use together in a decentralized way. One really simple way is to label all contracts from 0 through NB - 1, and have Alice and Bob each calculate i = SHA256(name ++ alice_address ++ bob_address ++ sale_price) % (N * B) to select escrow contract i to use. If it’s in use, then they calculate (i + 1) % (N * B) until they either find an available contract, or they determine that there’s no such contract free and will have to try again later (blocks would be full anyway).
Ask: Make it possible for there to be multiple identifiers per address.
Solution: Deploy additional naming contracts that point additional names to BNS state. Each naming contract can have its own identifiers and its own rules; the example I used in the previous thread showed how to bind a telephone number to an address. When a user transfers a name in BNS to a new address as part of a re-key operation, they will do so for each other naming contract they happen to use so that all their names continue to point to the key (assuming that’s even desired). There would probably need to be a trait written up somewhere that defines the standard naming contract APIs (along with a SIP that describes it) to help identity wallets do these transfers, but I’m certain this can be done. I’m happy to help guide this process if someone wants to take a crack at it.
The New Approach
Think of identities as assets since they are NFTs; Why are we making this complicated by building more contracts? Let’s fast forward to the future → STX will get expensive, and the last thing that we want is to put the burden on users where they spend too much on a simple marketplace listing. Second, for people who are concerned with privacy above all else, they should not (and likely won’t be) sharing private keys. If you have the same private keys and are sending STX between your accounts to fund other accounts, the blockchain will expose your identities anyway - prioritizing privacy above all else is forcing us to sacrifice UX.
The proposed solution is to simply take a page on ENS playbook, the most successful domain name. Let’s be honest here they succeed in identities more than we ever did on namecoin.
We create a whole new BNS contract and get everyone onboard so that one account can own more than one like ENS and a couple more features to make it more innovative.
Friedger already started to work on BNS v2, but needs help on how we should handle migration from v1 to v2.
- Mark from Megapont proposed a strategy where we can just make people burn the v1 to get the v2. For example, lock all reg v1 names for like 180days or something.
- we can airdrop the v2, give everyone fresh five years
@whoabuddy has a nice proposal about a DAO to deploy a registry and we let this DAO set new versions of the BNS interface that owns .btc
- The registry is simple.
- The app would need to call the update BNS version function. Is that possible for the eco DAO?
- a base dao
- an extension for the bns registry v1
- an extension to interact with the original BNS contract
Then you could start adding small pieces. Define an escrow contract, then deploy a few as extensions.
For upgrades, extensions can be disabled and new extensions implemented.
The main DAO and the extensions have access to all contract assets by default (though is-dao-or-extension), so migrating BNS names between registries should be possible. And a way for the people in control to submit changes - whether that be simulated multisig, by vote, etc
Other or Short-term Approaches
-
@marvin.id proposed a strategy that involves generating ad hoc private keys. Basically, like an atomic swap, a secret is revealed that allows recalculating the key. There must be some clever math for it or something ZK. Thru this, we can also build a BNS marketplace that relies on ad-hoc contract deploys.
Here’s the user story:
Since a user has to send a Tx anyway to “list” or transfer the BNS name to escrow, might as well get the user to deploy a contract (if it doesn’t already exist). Little painful, but at least it is compatible.-
The contract can just contain the name transfer on the top level.
-
This wouldn’t feel any different for the user from a UX perspective as they wouldn’t even need to know they’re deploying a contract.
-
-
The short-term solution for marketplaces: Daniel from Tradeport would probably be easier to build something that just deploys a new contract every time (instead of reusing), at least in practice would be easier.
-
The tradeoff is way easier for us but more expensive for the end user. A registry contract with a linked list could keep track of the last empty contract.
-
This is pretty much the same as what @Jude Nelson suggested the use of a reusable escrow contract with a public function that
(1) takes possession of the seller’s name
(2) takes possession of the buyer’s money
(3) exchanges the two.If Bob wants to buy a name from Alice, Bob will submit payment to the escrow contract (which would hold it for a time-out period, should the seller not submit the name), and once Alice sees the money arrive, she would send a transaction that transfers her name to the escrow (which gives it to Bob), and verifies that her account’s token balance increases by the appropriate amount.
From Friedger: The escrow contract is really simple.
-
-
@dartman also built one master controller with many servant contracts holding one name each:Transaction - Stacks Explorer by Hiro
The question here is, why are we deploying more contracts here 
do we want a simple marketplace listing to get super expensive = cost hundreds of dollars and congest our network?
TLDR;
Now, as a community, we need to achieve consensus on “what’s the right solution and what’s the best approach for this?” time to vote, decentralization, FTW. 
Shoutout to @nickgamma for providing insights and comments on this forum post.
Tagging other respective parties @markmhendrickson @muneeb @Jamil
human friendly addressing in crypto, once ubiquitous, is such a big UX unlock for mass adoption. It makes you wonder why it has been so long in coming, at least to the Bitcoin and Ethereum ecosystems. Stacks bringing this to Bitcoin is a BIG deal! 