Making BNS ready for prime time

120% agree with what @rainer said.
The upgrade is irreversible and maybe should take more considration and debate.

1 Like

I respect where you’re coming from, but I think this argument is fundamentally misguided for several reasons:

  1. Not building a better experience in fear of a possible future congestion issue is never an approach that should be taken. If Stacks can’t scale (not even just for domains, but yes, that’s a core use case), then it is destined to fail anyway. In one way, it could be argued that if we don’t build a better experience, Stacks doesn’t even have a chance at success, let alone a strong likelihood. If we are to make Bitcoin programmable, we need dramatically better scaling solutions than we have today, and there are multiple workstreams building different solutions for this today. One can only expect that we have a better, more scalable network when we have 1 billion users.

  2. There has historically been a lot of focus on artificially increasing the difficulty of registering multiple names and making users jump through hoops in some ideological attempt to prevent squatting or speculative registrations. This concerns me for two main reasons. First, it seems quite anti-Bitcoin, and honestly even more so, anti Stacks’ mission. Why are few deciding what is the “correct” way to use decentralized identities or domains? Isn’t this the same Bitcoin maximalist argument that building applications on top (i.e. Stacks) is an incorrect use of the Bitcoin blockchain? Users and the market will determine how things will be used. Second, and more importantly, the goal at preventing this type of behavior is not actually working (and never will, as we are in a permissionless ecosystem and the market always dictates how things will go). We see from registration data that tens of thousands of names have been registered in a few weeks, and many users are breaking the existing wallet infrastructure due to creating too many accounts/addresses for it to support. I would argue that by making it difficult to register and own more than one name, all you are doing is ensuring that only the most technologically advanced and persistent people will have the means to go and do just that. In short, not only is it not working at prevention, it’s likely exacerbating the issue it sought to prevent and decreases accessibility for the average user, who already struggles to be onboarded to web3.

  3. If the concern is names running out, this is a baseless argument IMO for at least three reasons. First, BNS already supports the permissionless registration of new namespaces (TLDs), each with customizable rules, pre-registrations, and policies. This means that if .btc names were to “run out” of anything human readable, somebody could easily register (or already has registered) .bitcoin, .sat, .satoshi, .blockchain, .stx, .stacks, .crypto, etc., etc., and users would still be able to register a functionally equivalent BNS name. Second, at the time of writing, Twitter has 330 million users and Gmail has 1.5 billion; both of these platforms have unique usernames/addresses for each user, yet new users still have no trouble signing up and finding a name for themselves. It may not be exactly the name they wanted, but there are plenty of variations and combinations to make use of even just a single (e.g. .btc) namespace/TLD for all BNS names. Third, to bring this second point closer to home, we see how .com domains work on DNS, and we certainly see no prevention of multiple registrations (even on web2 — IOW more permissive than Stacks!), and we also see a healthy domain market for buying and selling domains secondhand. As I’ve stated before, the market will always find a way.

  4. I believe your understanding of the way BNS works from a technical/resolving perspective is a bit off (please somebody jump in if I am mis-stating this). It is still possible on Stacks, today, with one name per address, for funds being sent to you to not resolve properly to your address. I believe this is because BNS still contains the logic to support more than one name per address, even if it doesn’t support it today. This has actually caused issues for users (on a small scale) where they incorrectly transferred a name, or some other outcome occurred, and funds went to an old address or otherwise didn’t resolve properly. In one way, we’ve created this problem by making people believe that this one-domain-per-address means that it will resolve perfectly 100% of the time. There was a time, a few months ago, where we had to disable sending NFTs via BNS on Gamma, because the API endpoints could be unreliable and return the principal of a prior owner instead of the current owner. It could be argued that we, as an ecosystem, had/have not prioritized the tooling and infrastructure to transfer and lookup BNS names in the proper way because of this self-imposed restriction of one-per-address.

  5. With respect to anonymity and privacy, this is perhaps the weakest argument IMO, for at least three reasons. First, going back to the original Bitcoin white paper, the recommendation is effectively to use a new address for each transaction, and certainly not to tie together your name to your private transactions. The idea that one-name-per-address protects privacy is backwards in this regard — decentralized identities seek an entirely different goal than one seeking to protect anonymity and privacy (but both are valid). Second, the way in which users are funding wallets to register new names creates a public, immutable record of funds transferred from one wallet to another, thus linking them together as likely the same person. This is the most common method of funding new wallets to hold new domains, and this method cancels any argument regarding privacy protection. Third, for the most privacy-conscious, truly anonymous users, there are dozens of specific precautions that must be taken to prevent your transactions and identity from being exposed and/or connected to you or to one another; the idea that one-name-per-address is a shortcut to privacy protection is a dangerous supposition. Users who want the most privacy protection should use entirely separate private keys, on entirely separate devices, on private VPNs, funded through very specific means, etc., etc., the list goes on.

  6. This one is more opinion than fact, but I also personally believe that with the proliferation of new use cases and ideas (which we should support, encourage, and should expect to see more of in the future), like for example @louise’s social handles that are being pushed forward by Ryder, or Trajan’s social reputation platform and .trajan handles, won’t have a chance to properly succeed without the ability to have more than one name per address. For example, my primary identity for vanity/Twitter/Discord is nicksainato.btc, my primary wallet for trading NFTs is vanillabean.btc, yet I belong to many communities like Megapont, Bitcoin Monkeys, Satoshibles, Stacks Parrots, etc., yet I cannot actually signal my support since I don’t want to change my primary identity to nick.stacksparrot, even if I enjoy holding the name and have significant holdings in the project. It’s hard to argue that this is a “wrong” use case of BNS, yet I can’t do this because of this limitation.

  7. In somewhat of a summary and somewhat of an expansion on the argument that “the market will find a way” — perhaps one of the most pragmatic reasons to allow more than one name per address is simply that this is what seems to be what users want. And while Stacks has been slowly growing, inch-by-inch (this is in no way to suggest people aren’t working very hard, but just a fact looking at network growth, etc.), there is an opportunity to seize this moment and bring in many new users, developers, investors, liquidity, and interest to Stacks and its extremely important goal of building on Bitcoin, the most secure, decentralized, trusted settlement layer. Not being a touch opportunistic in this situation would be a mistake, and could possibly delay (or, in an extreme outcome, prevent) Stacks’ potential of ever becoming a top ten ecosystem in web3.

I know this was quite long, so thanks for those of you who took the time to read it through. These points, among others, have been on my mind for quite a while and I think we need to continue the mindset of moving forward swiftly here, while of course moving with purpose and intention.


the most efficentive way to reduce dormant addresses is to raise the register price , but not allowing 1 more names. i ever see some guy registered more than 4000 three letters .btc name because of the pretty low price. if the register price be raised to 5 usd /1year or 5 years, that will never happen.

In the Hiro Developer Call yesterday, @nickgamma suggested these improvements:

  1. Remove 1 per address limitation
  2. Figure a technical solution for consistently and properly resolving the owners of BNS names (technical thing, ignore if it doesn’t make sense to you)
  3. Add associated addresses from other blockchains (e.g. associated ETH address).
  4. Add unicode support so we’re not an english-focused ecosystem only + emoji support, etc.
  5. Figure out how to handle the punycode → unicode situation and how we can make sure users have a good experience between the two
  6. Ensure the contract is upgradable without another SIP being required – perhaps using Executor DAO (a flexible, open source DAO framework on Stacks)

Re 1., we need to spell out the details here: Do we want a naming system where users can login with different handles and still see the same data? Where users can sign with different names using the same public key? Do we want to have names owned by 1 user that all have the same public profile?

Re 2, this is a problem of the stacks node api, not of the BNS contract.

Re 3. In Developer Preview: Update Profiles | Sigle, I describe how to share crypto currency addresses in your public profile using chain agnostic format.

Re 4, how do we handle homoglyph attacks?

Re 6, as the whole stacks system is affected we need a SIP or a procedure where everybody can participate.

1 Like

1 name 1 address also has a big advantage that some great projects like Dappnet/Impervious/Bluesky or Musk‘Twitter they will have motivation to integrate BNS because they can create a new domain suffix on BNS Namespace which has the same priority rating with .btc domain, thus they can make income from BNS.

the most efficentive way to reduce dormant addresses is to raise the register price to the normal level, but not allowing 1 more names.

if allow 1 more names, all the advantage of BNS will be changed.

I don’t understand your argument here. It is good for me as a BNS owner when others can make profit? They can make profit with 1:1 names and with 1:n names, I guess. They will find ways.

i dont mean retaining 1:1 name is to stop others who holds BNS from making profit, that does not matter. the only things matters is that 1:1 name is good for BNS long-term development and mass adoption ,though not good for short term hype and speculation.

absolute freedom without law and rules always leads to disruption and disorder, that’s why laws exist to limit people behavior in really life. if people can chose the bitcoin block time and size,soon bitcoin will become centralized .

the limitation of 1:1 name is essential for the success of namespace. all the great projects will only support 1 name 1 address if Stacks wants them to integrate BNS

namespace gives other great project such as Bluesky/Dappnet/Imperivious driving force to integrate BNS thus they can earn register fees from BNS

great project integration is essential for BNS future mass adpotion.

with the same priority rating namespace, they can make income and dont need to develop a new chain to creat thier own domain.

anyhow 1 name 1 address is essential for the success of namespace , and the success of namespace is the key point for the success of BNS even same as Stacks.

if namespace make success, Stacks will be a appropriate chain to creat new domain for most great decentralized social project and will take 90% of the domain market share.

Because of 1 name 1 address, the new namespace has the same priority rating to show in a social media and dont have to resolve. if 1 more names, the only one showed in a media be the the only one .btc name that has been resolved.

If you have used ENS, in 1 address there are many domains, you want to show 1 of those domain in a dapp or social media you have to resolve the domain to the address.

whether from the perspective of bitcoin transfer or web3 social ID or ecosystem attraction, 1 : 1 name is much more safe ,anonymous,convenient and user-friendly and good to relieve the congestion than 1 : N names

to say the least, we can always update to 1 :N names from 1: 1 name at any time, but we can never go back to 1:1 name after we upgrade to 1:N names

The upgrade is irreversible maybe should take more considration

short term hype will never achieve the expected results without the basis of big quantity real users.
the temporary success and leading position of ENS is not because of 1 :N names but the big ecosystem of ENS and ethereum

The only way for BNS growing bigger is that some big projects creat their namespace on BNS and integrate BNS , 1 name 1 address is in the crucial importance to attract those big projects/companys coz they can earn registration fees from BNS.

We have seen that many projects in Stacks ecosystem has created their namespace such as .frien .citycoins, .app and so on.

We have 10+ namespace on BNS, That is the big advantage than ENS, no projects want to create their namespace on ENS.

Because in multiple names, their namespace is inferior to .btc name, the one stx address and btc address be occupied by .btc name, no one would like to mint names on new namespace.
But in 1: 1 name, their namespace has the same priority rating to .btc name, match with 1 stx address and 1 btc address just like .btc name does.

If 1 name 1 address be changed, BNS will lose its biggest competitive advantages.

what can prevent people from registering 1:1 even through they will have possibility to register 1:many?