BNS Upgrade: multiple names per address

BNS
1

This post is part of a larger effort to discuss potential features to be included in an upgraded version of BNS. Please see the megathread for more information.

Proposal: allow a Stacks principal to own more than one name

The current BNS contract requires that any Stacks principal cannot own more than one name at a time. For users that wish to own more than one name, this requirement results in a user experience with more friction. BNS users use various workarounds, including scripts and using multiple addresses, to custody multiple names.

Additionally, the single name requirement adds significant limitations or difficulties to the ability for smart contracts to be built on top of BNS.

There are various arguments in favor of keeping the “one name per address” rule:

Providing a “canonical name”

Only allowing an address to own a single name simplifies the answer to determine what the “canonical name” is for a given address. For apps like wallets, there is a benefit to this simplicity and can result in reduced confusion. When an address owns more than one name, this becomes more complicated.

Counterargument: To preserve the ability to determine a “canonical name” for a given address, a new version of BNS will provide a contract-based mechanism for keeping track of an address’s “primary name”. Addresses with one name will have this set automatically, and addresses with multiple names can call a method to update their primary name. Functionality will be included to automatically update an address’s primary name in the case that the primary name is transferred.

Reducing “name squatting” and other speculative use cases

A separate argument in favor of preserving one-name-per-address is that it makes it harder for speculators and name squatters to buy and own many names. The argument is that such behavior worsens the overall utlity of BNS, because it makes it harder for non-speculative users to own their desired name.

Counterargument: Regardless of arguments about whether speculation is good or not, the truth is that it’s not possible to build an open and permissionless system while preventing this behavior. Many users already utilize many workaround to the one name requirement, and can use tools to automate bulk registration and name management without friction. Apps like Gamma have demonstrated the ability to build marketplaces despite the challenges that the single name requirement adds. Protocols like BNSx further demonstrate the ability for abstractions to work around this requirement.

References:

2

This is a subject that I feel strongly about if we want BNS to actually get traction.

I discovered Stacks through BNS, which is a real possibility of how future users will find Stacks if BNS is successful. Regardless of how a user finds BNS, I’m providing a simple use case on how this affects onboarding and not only makes BNS difficult but goes against what the industry has set as a standard. Like it or not, this is what users are expecting. Now I ask that you think of this as if you were a new user or a business.

You’ve already purchased your domain/Identity on a service like UD or ENS. It was simple, straight forward and you could grab the multiple domains/identities you needed in one shot. It only took a few minutes.

You want to also get your .btc (.id, etc…) domains to cover all your bases. So you come over to BNS. You open a wallet and transfer some BTC to it. Now you realize you need STX, so you go to an exchange and swap some BTC for STX. You try to get multiple domains because most businesses and users hold multiple domains (redirects, additional spellings, etc…), but wait you can only get one domain per address. Crap, ok now you need to create a few more addresses, oh and you have to transfer enough STX to each address to cover the costs for each domain. This is a slow process so now you’re waiting for confirmation that the STX arrived at each address. You’re new, so you do this one address at a time about 30 minutes to an hour for each address. After hours of work, you try to get your domains. If you’ve made it this far, now you have to manage each domain under its own address. I think you can see all the friction points in this simple use case, this doesn’t cover errors, mistakes, frontruns, etc…

This is fine for well-educated Web3 people but adds so many levels of difficulty for the average user that many will simply move on and say nevermind. In order to get adoption, you have to look at how the average person will look to use your system.

Each step is a point of friction and will have users abandon the process.

If there are members of BNS that feel so strongly about having an address identified by a single address then compromise and allow multiple domains per address, with one address set as the Primary domain/idenity.

In marketing and sales it’s very important to get it down to as few clicks as possible, with each new click your abandon rate increases. This is business 101 and if business is a dirty word, it’s adoption 101.

2 Likes
3

The only way for BNS growing bigger is that some big projects like Bluesky,Damus, to 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. 1 address 1 name is the key design to make namespace pupular.

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. if 1 address 1 name be changed, namesppace won’t be popular like today.
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.

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.

And BNSx team has done very good job on making BNS name tradable, we dont need to change BNS 1: 1 name core design to mutiple names one addresse.

1 Like
4

Since your reasoning is based on ENS and the need for BNS to grow through partnerships, I’ll provide a real world and successful example of multiple TLDs, some custom, all under a single address if so desired.

Unstoppable Domains has about 10 of their own TLDs, and adds custom TLDs with some larger partners, i.E. .polygon, .hi, and .binanceUS as part of their 1,000 partners. In each case your able to hold multiple domains with different TLDs in a single address. I can have tommy.x, tommy.polygon, tommy.hi, tommy.binanceus all under one address (and hundreds more if I like).

If I were able to attach screenshots I would show a visual example. There is an option to identify a domain as a primary.

So if partnerships is the argument, this would show that large partners are willing and able to make this work and successfully sell their own TLDs. .hi, .polygon, .binanceUS, etc… Informational articles below. This single address didn’t stop UD from acquiring over 1,000 partners. It’s not going to hurt BNS. What hurts getting partnerships is a difficult onboarding experience.

Google Unstoppable Domains binanceUS.

1 Like
5

+1 to ThomasButchers view and suggestion. There are also already a number of workarounds including bulk register tools. Just let the user decide how many domains he wants to register and pay money for.

There are also a number of reasons why someone would register multiple domains unter the same address.

Imagine someone starts a Roulette website and wants to receive deposits in BTC. He registers roulette.btc but soon realizes that some users wrongly deposited to:
rulette.btc
roulete.btc
roulett.btc

There are many cases where it makes perfect sense and would actually be recommended to also register the most frequent typing error domains or your project. This is 100% common practice in web2 for big companies already and is important to reduce abuse.

2 Likes
6

Agree with Tommy about the ‘onboarding experience’.

In order to make the experience as smooth as possible BNS 2.0/V2 needs to enable users to register multiple names to a single address. The Stacks blockchain is the only one I’m aware of (I use a multitude of blockchains & wallets) where in order to register names I need to create a new account, send STX to it, register the name and then repeat the process. This experience alone is enough to put off the average user imo.

So it is of key importance I feel that BNS 2.0/V2 allows users to register multiple names to a single address.

With re’s to name squatting you will have that anywhere and having to create a new account to register a new name each time hasn’t prevented those currently using BNS to register 100’s/1000’s of names.

Couple of things that I think are worth mentioning, although a little off topic here are:

  1. I do think registration & renewal fees should increase an incremental amount, with renewals decreasing to 3 years maybe.
  2. There needs to be an ‘all-in-1’ for BNS - search, registration/multi-reg(?), renewal, stats and any other updates to Zone file etc.
1 Like
7

Just reading the thread, I think the happy medium here is to be able to buy and assign multiple names under one address.

So same as now, except the user (beginner) has the option to buy lots to one address, but when they want to “activate” they need to assign to a valid STX/BTC wallet address, otherwise, the points made by @rainer become a real-life problem. Maybe the option can be included in the buying process so that the user has a chance to create/assign on purchase.

This stays simple for beginners but still gives the same security and advantages coming from multiple accounts. When the user wants to build a site or service and attribute multiple domains/route payments, then they can then maybe perform a multi-sig function from each account the domains belong to.

Just throwing some thoughts out there.

8

100% for multiple names per address. We had this functionality prior to Stacks 2.0 when it was unilaterally removed without any input from and against the wishes of the community. Let’s bring it back and make BNS great again!

This is the way!

3 Likes
9

Multiple names per address is an absolute NO.
It turns BNS names into another speculative class of NFTs rather than its intended purpose as a naming system!

Multiple names per address at the contract level breaks BNS.

The argument for multiple names per address is that it would grow adoption of BNS. But that would grow the usage of BNS as a casino, not a naming system. To grow adoption, we need to bring identity utility to BNS, not trading utility. For example, at Trajan.App you receive endorsements in the form of non-transferable NFTs to your BNS name. Stacks users can finally build a reputation and identity with their name. If you want to grow adoption, grow identity integrations and create identity applications.

There SHOULD be friction to own more than one name.

Multiple names per address should be opt-in only.

1 Like
10

You might simply be using the wrong abstraction layer IMO. For example what is the plan if someone transfers their BNS - endorsements are voided?

If you created something like an “endorsement vault” that would give you an extra layer of abstraction to fine tune the management of that state and not need to worry directly about BNS.

1 Like
11

larry you said iris integration will come, but finally they dont, why?
If you ask some desocial projects like iris, bluesky,damus，to pursuade them to integrate BNS they will only support 1:1 name, if BNS cannot make them make money, they will build a chain and their own naming system

the more integration of BNS ecosystem is the key for BNS success.

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

1 Like
12

Sigh, I honestly can’t believe this is still being debated. But I’ll try to be respectful. I’m going to repost my very comprehensive thoughts here from the original megathread about six months ago.

It is speaking about a network and BNS protocol that has barely advanced (not for lack of trying, especially by great builders like Hank and Jeff), and a major fear I raised.

But I am just one voice, and if people are against the rapid advancement of the network in more ways than one, then the network just might not make it in my opinion.

I’ll dispute every seemingly credible argument against this that I’ve seen:

  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 @RagnarLifthrasir’s Trajan 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. I won’t do this for any other ending than .btc. 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’m still optimistic. Let’s get it going.

5 Likes
13

I agree.
And I’ll say again, that multiple names per address is a DOWNgrade.

14

Actually, multiple names per address is worse for Trajan. And not to sound arrogant, but Trajan can become THE identity and reputation system of Stacks. So why harm the application that can do the most for BNS utility and adoption?

Does Gamma make more money if your customers can have more than one name per address?

15

if BNS want to make success, .btc should to be small part of BNS, the more growing protencial comes from decentralized social network integration, the key of BNS success is to attract more decentralized social network projects to issue their own namesapce on BNS, decentralized social network is the only hope to bring BNS to mass adoption, coz sending bitcoin via .btc is super weak demand

1 Like
16

image
even most ecosystem projects from Stacks like Pravica, Sigle, Console and trajan, they dont agree mutiple names, let alone those projects come outside from Stacks

1 Like
17

Ok, I truly wish you the best, but my unsolicited feedback is that I think your odds of success are far higher if people could use their .btc as their primary identity — which represents about 90% or more of names (IMO, that’s a signal of what people prefer).

In terms of Gamma making more money, probably not. I mean, in general we never make decisions based on money alone (otherwise we wouldn’t be building on Stacks), but there’s an argument that the current model makes us more money, because people have to go through great lengths to procure names and therefore can hold them hostage over everyone else and charge exorbitant prices. Methods to prevent names from being hoarded actually just make the most persistent people more exclusionarily able to secure and squat on names on wallets they’ll barely ever touch versus making that anpproach accessible to anyone to even the playing field.

Most importantly, we (Gamma) want to see multiple names per address because we’ve had hundreds if not thousands of users ask for it, and we try to listen to what the ecosystem wants. At some point, you need to drop the principled game and get on board with what the vast majority of real users actually want to see — because ultimately, none of this really matters if Stacks dies because users aren’t finding value being here.

I don’t have anything more to add to this discussion. I’m hopeful we see some advancement and quickly.

3 Likes
18

What are you talking about? On Trajan users DO use their .btc as their primary identity. That’s the whole point.

19

100%

IF THE STACKS APPLICATIONS THAT ACTUALLY USE BNS FOR NAMING AND IDENTITY WANT 1:1 THEN THAT SETTLES IT.

The rest are gamblers.

20

Ragnar, relax. Jesus.

Also, Gamma has a whole social layer with thousands of users, all of which get a dedicated profile and can follow other users (based on DID). We don’t even offer usernames today, and that was to lean into BNS. So do not make blanket statements about 100% of apps, since that’s false. I’ve also not seen Sigle speak for themselves once yet. Maybe they agree or maybe they don’t, but I want to hear that from them.

On Trajan, my mistake. I thought you were doing .trajan as was an original plan I heard from you. If you’re doing .btc, that’s different.

1 Like