Allow more than 1 BNS names on a contract with a deactivate feature

[314159265359879]

I want to record the following here after discussing the ideas for a BNS marketplace with @friedger and @dantrevino . Some community members have shown an interest in trading BNS names and people frequently ask for one on the telegram channels.

The difficulty to make a marketplace contract for BNS names currently arises from the fact that a principle can hold a maximum of one name.

Proposed solution: If we could allow a contract to wrap a BNS name and 'deactivate' it for the purpose of trading it that would make it developer and user friendlier to make a marketplace for BNS names.
-- perhaps a bit like an expired name, which an address apparently can hold several of, but only one can be active.

Questions

1. What are the reasons to limit a principle to have a maximum of one address again? I believe there to be a good reason because prior to Stacks 1.0 it was possible.
2. @friedger you devised a way to work around the current limitations with proxy contracts. Could you explain this in summary and explain the main objections in your view working with those (trusted) proxy contracts?
3. @Exulansis with your work on the stacks-did-resolver you have a unique perspective on BSN names, what do you think of the proposed solution?
4. @jcnelson what do you think of this? do you have an alternative idea of how to work with the limitation or a solution?
5. and could this be added to Stacks 2.1 if we can come to an agreeable (yet consensus breaking) solution?

[friedger]

For upgrade procedure see stacks-network/stacks-core#2685

[jcnelson]

What are the reasons to limit a principle to have a maximum of one address again? I believe there to be a good reason because prior to Stacks 1.0 it was possible.

This was a deliberate design decision, because it prevents a race condition whereby people would accidentally register two names to the same address, and thereby create two accounts with the same private key. There are dire privacy consequences to this -- it creates the illusion to the user of having two distinct compartmentalized app accounts where in fact there is only one (recall that the user's identity is their key, not their name). This was a chronic problem in Stacks 1.0, which was fixed in BNS 2.0.

The difficulty to make a marketplace contract for BNS names currently arises from the fact that a principle can hold a maximum of one name.

However, this shouldn't prevent you from building a marketplace. As long as buyers and sellers can discover each other -- something that does not need to be done on-chain -- then they can trade names.

The trade could be facilitated by 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, and (3) exchanges the two. If Bob wants to by a name from Alice, Bob would 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.

[friedger]

As the name is just a label for the user's key, I don't think there is any disadvantage when user/user's key can have several names that redirect to the one main name.

This could help to avoid errors by typos and also allow for a user to hold more than one name. Probably I haven't understood the problem with the race-condition.

While we talk about improvements of BNS, I want to suggest to make names unique across namespaces.

[314159265359879]

While we talk about improvements of BNS, I want to suggest to make names unique across namespaces.

I do not think this should be a default and it may be impossible to do because if you register a name today, you can at best register it on the existing namespaces but not on namespaces that are created in the future.

I do like the idea of dapp that will check across all the namespaces for you to find a unique name that can still be registered across all existing namespaces... and then make it as easy as possible to register them all.

I think an important reason to have namespaces and the ability to add new ones is so that users can create new ones to have the ability again to register every possible BNS-name.

[jcnelson]

This could help to avoid errors by typos and also allow for a user to hold more than one name. Probably I haven't understood the problem with the race-condition.

So, first of all, I'm very strongly against multiple names per address, since I consider it to be a severe security flaw. This was a hard lesson learned from Stacks 1.0 -- I'm not talking about hypothetical scenarios; I'm talking about real-world experiences here.

The main use-case for BNS usernames is to implement user accounts. Users naturally expect that different names correspond to different application accounts, since the whole point of registering a BNS username is to use dapps in a single-sign-on fashion. As a user, if I own jude.id and jude.btc, I expect these usernames to refer to different private keys, and thus different Gaia storage buckets. Making it so both these names correspond to the same key would lead to a surprising privacy violation, since then both jude.id and jude.btc would resolve to the same application state. This is essentially the same as having two separate Gmail accounts resolve to the same inbox -- surprising (in a bad way), and almost certainly not intentional.

The race condition I mentioned stems from the fact that there's a window of time between when a user registers a name and when the name arrives in their wallet. Because Stacks 1.0 let an address own up to 25 names, it had been the case that multiple users would accidentally register multiple names to the same identity address. The reason this happens is because users don't understand that their name is in-flight. This can't be helped -- transactions take time to confirm, but new users don't understand this (no matter how much we try to warn them). In fact, they would go out of their way to reset their wallets in a misguided attempt to register a second name to the same address, not knowing that they simply have to wait for the first name to confirm. Moreover, in at least one case, the user used the same private key on multiple devices to register names in parallel, and accidentally ended up with multiple names bound to the same identity address.

If the whole purpose of re-introducing this security flaw is to introduce the ability to trade names, then perhaps it would be better to think of a way to do that without allowing an address to own multiple names.

[LNow]

Maybe we could make a clear distinction between owning and using/identifying with names? So that one private key can own multiple names, but use or identify with using one and only of them.

If I would own lnow.id, lnow.btc, lnow.xyz and lnow.abc then I would have to make a deliberate choice which one of them I want to use as my identifying name.

[friedger]

If the whole purpose of re-introducing this security flaw is to introduce the ability to trade names, then perhaps it would be better to think of a way to do that without allowing an address to own multiple names.

Something like: we create a tradable NFT name and then the user can create from one of these NFTs a BNS username?
Why is this security flaw not an issue for other naming systems?

If I would own lnow.id, lnow.btc, lnow.xyz and lnow.abc..

@LNow Why would you own a gmail account that has the same email address but just a different fee and expiry model?

[LNow]

@LNow Why would you own a gmail account that has the same email address but just a different fee and expiry model?

@friedger it was just an example. You can replace in it lnow with multiple different phrases 😉 My goal was to show how I think we could allow people to own multiple names and at the same time not create security flaw described by @jcnelson.

[markmhendrickson]

I'd be interested to get @GinaAbrams and @MarvinJanssen's input on how the dynamic around having just one BNS username per address has played out for the .BTC app this year.

We last debated this question here before the launch of Stacks 2.0 when we had to make a bunch of assumptions, but now we should have real-world learnings.

Note the issue raised here recently in Discord in regards to losing fees when failing to register a second for a given address.

My intuition continues to tell me that the race condition issue raised by @jcnelson would be best handled client-side, not on the protocol level. Wallets and the like are ultimately responsible for informing the user accurately about transaction state and guiding them to take the right actions in regards to pending transactions.

Also, this seems less like a "security" flaw and more a "usability" issue?

[larrysalibra]

Just caught up with the pre-Stacks 2.0 BNS launch debate thread about this. I remember when we had users registering more than one name with a private key and they were confused. This was a client side issue.

I didn't realize multiple names per account had been disabled in Stacks 2.0. It seems like we've re-hashed this debate many times over the years.

Names are just pointers to public/private key pairs. Multiple pointers to the same thing are very useful in computer science and in life. Many of us have multiple email addresses that go to the same email addresses and multiple names people call us. Places have multiple names that point to them: "The White House," "1600 Pennsylvania Avenue," "Joe's House" all refer to the same place. We use this construct all the time and we handicap BNS by disabling it.

I agree with @jcnelson's comments elsewhere that the 1 name to 1 key pair can potentially simplify things for app developers using names for usernames. But that's just one single use case of names. If developers using names in this way find multiple names confusing or troublesome to deal with, they can still just use the first name by convention. There's no need for this to be enforced at the protocol level. This would be similar how some bitcoin wallets only use one address while others generate new addresses for each transaction. The first is easier the second is better and neither is enforced by the protocol.

Agree with @markmhx - fail to see the security flaw here. Seems like re-enabling multiple names would be major improvement and solve @314159265359879's problem!

[MarvinJanssen]

Totally agree with @larrysalibra, I always thought the decision to artificially limit names to one per address was very strange.

[jcnelson]

So, I'm not too fond of having to repeat myself. This issue has resurfaced before, and each time, we all come away with the understanding that 1-name-1-address is actually the superior solution for BNS, because nothing stops you from creating additional naming contracts that interop with BNS to give you as many names per address as you'd like. Every single issue that has been brought up here has been talked over already. I invite everyone here to please go re-read the notes from the last time we all discussed this: stacks-network/stacks-core#2211.

[jcnelson]

I'm going to lock this thread for a couple days to give everyone a chance to do so.

[jcnelson]

Since this myth refuses to die, let me drive a stake into its heart right here, before I unlock the thread.

My intuition continues to tell me that the race condition issue raised by @jcnelson would be best handled client-side, not on the protocol level. Wallets and the like are ultimately responsible for informing the user accurately about transaction state and guiding them to take the right actions in regards to pending transactions.

In an N-names-1-address world, ensuring users don't accidentally register multiple names to the same address fundamentally cannot be addressed client-side. You cannot stop users from sending multiple in-flight registration attempts, because you cannot stop users from clearing their wallets and re-registering multiple names in the time in-between two Stacks blocks. Users can, will, and continue to do this.

Let me say that again for the people in the back. 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.

Given that BNS is used primarily as an SSO system, enforcing 1-name-1-address is less surprising than permitting many names to land on the same address by accident. If you want a different rule, you can deploy your own naming contract today and start using that instead -- there's no need to wait around for a hypothetical BNS upgrade. Also, you can bind your own naming contract's names to BNS addresses if you want, thereby getting multiple identifiers for the same address without creating BNS name-registration problems for the user.

That said, before anyone suggests that the client should nevertheless be responsible for dealing with any problems that arise from this, I'll remind everyone here that users getting multiple names stuck on their ID-addresses has been a chronic problem for the Blockstack Browser and Stacks 1.0 wallets throughout the entirety of Stacks 1.0's existence, back when it was 25-names-1-address. Given that the wallet teams have never addressed it, despite multiple users complaining, I will no longer take in good faith any suggestion from them that this should be the client's responsibility. They had their chance -- they had years of chances -- but no one delivered. Clearly, it is unreasonable for the ecosystem to expect wallets to deal with this problem.

[jcnelson]

Okay, I'm unlocking this thread. Again, please revisit the earlier thread if you have not done so already.

It sounds to me like there are two major asks in this thread (please correct me if I'm wrong). The good news is, I do not believe it will be required to modify the BNS contract to do both of these things! So if this is something y'all want to execute on, you can proceed to do so without waiting for a network-wide upgrade.

• 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 N*B 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 N*B - 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 a contract that's available, 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'd 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.

---

Now, I realize I may have been too fast to lock this thread. I am sorry -- I acted too quickly, and did so just as much out of my own personal frustration as out of a desire to make sure we didn't end up re-hashing the same arguments over and over. We'll put in place some moderation rules so that if it becomes necessary to do so in the future, it'll be clear as to why. I welcome any and all suggestions on what that might be.

In general, the two asks I'd have from the community regarding moderation rules are (1) to be sure to revisit prior threads that discuss similar issues, so we don't end up re-hashing the same arguments over and over, and (2) in the case of requests that require hard forks (like this one), to first spend time considering ways to address the issue at hand that do not require such a drastic action. In general, hard forks are a procedure of last resort, are very laborious and time-consuming, and are very hard to get through the SIP process. Finding ways to solve problems while avoiding hard forks, such as the above suggested solutions, would get them solved much more quickly.

[markmhendrickson]

Now, I realize I may have been too fast to lock this thread. I am sorry -- I acted too quickly, and did so just as much out of my own personal frustration as out of a desire to make sure we didn't end up re-hashing the same arguments over and over.

Thank you for expressing this sentiment and for unlocking the thread.

All the same, I feel compelled to emphasize how important it is that nobody lock these threads simply because of their own frustration with other people's suggestions, inquiries and points of view.

This is especially the case when there's an apparent need (or simply a desire by anyone in the community) to revisit decisions made months ago. We should be completely open to new data and experiences, even if it means repeating ourselves sometimes. Though if anyone simply wants to link back to their previous thoughts and arguments, they're certainly encouraged to do so. It's not that hard – here are my previous arguments for example.

This sort of thing discourages me as an experienced member of the community to engage with discussions about the protocol. I can only imagine how discouraging it could be for less experienced members or newcomers who reluctantly conclude they must be "missing something" or couldn't "do their homework" adequately.

This issue has resurfaced before, and each time, we all come away with the understanding that 1-name-1-address is actually the superior solution for BNS

I've reread the previous thread as insisted, and I don't see anyone expressing agreement with the idea that "one name per address" is superior. To the contrary, several of us are pleading with you to reconsider, which you refused to do. You simply left a final comment and closed it at will, effectively shutting down the conversation.

The irony here is if we had continued this conversation before the launch of Stacks 2.0, we could have perhaps avoided the issue you point out here that moving away from "one name per address" now requires a hard fork.

Given that the wallet teams have never addressed it, despite multiple users complaining, I will no longer take in good faith any suggestion from them that this should be the client's responsibility. They had their chance -- they had years of chances -- but no one delivered. Clearly, it is unreasonable for the ecosystem to expect wallets to deal with this problem.

This comment is baffling to me. @larrysalibra is one of the best people positioned to create something amazing with BNS on Stacks 2.0. And as the product manager of a wallet these days, I'm incredibly grateful that he contributes to these sorts of conversations, given his extensive experience with creating authenticators for Stacks 1.0.

We're all going to ship suboptimal code – all of us. Instead of writing each other off, let's learn from each other.

Ask: Make BNS names tradeable.
Ask: Make it possible for there to be multiple identifiers per address.
Solution: ...

I invite everyone who's interested in making these asks to consider Jude's recommended solutions here seriously, and I appreciate his offer to help with guidance for the second solution in particular. I'd certainly love to see how it goes.

At the same time, I encourage anyone to raise any questions and concerns they may have if these solutions don't appear to meet their needs.

I hope we can then continue this conversation in service of the use cases faced by these particular developers.

[aulneau]

Wow there is a lot here lol — happy to see this discussion come back up, as I feel as though pre-2.0 much of this sentiment was here, but due to pressures around launching it was not possible to work through.

To me it seems that there is a real community need and desire around this feature. @jcnelson — I know you have very strong feelings and ideas around this, however, it seems to me that those are clouding your vision around this. I don’t think it was appropriate for you to lock this thread — the only one who is getting heated here is you. @314159265359879 came here in good faith and had plenty of valid questions, but you immediately skipped over them.

Now here are some of my thoughts on all that has been talked about here:

As a user, if I own jude.id and jude.btc, I expect these usernames to refer to different private keys, and thus different Gaia storage buckets.

This is entirely subjective. To me, if I had aulneau.stx and aulneau.btc, I personally would expect them to resolve to the same underlying identity. Maybe there are exclusive chat rooms that only work if you own a name in a given namespace. Your position and mine are both valid, it’s impossible to say one of them is more correct.

Given that the wallet teams have never addressed it, despite multiple users complaining, I will no longer take in good faith any suggestion from them that this should be the client's responsibility. They had their chance -- they had years of chances -- but no one delivered. Clearly, it is unreasonable for the ecosystem to expect wallets to deal with this problem.

I feel like this is a very unfair characterization. You are referencing a small set of folks who may or may not even work on projects in the ecosystem anymore. Why restrict this or make this claim to prevent anyone from ever trying? It’s incredibly dismissive and reductive.

Names are just pointers to public/private key pairs. Multiple pointers to the same thing are very useful in computer science and in life. Many of us have multiple email addresses that go to the same email addresses and multiple names people call us. Places have multiple names that point to them: "The White House," "1600 Pennsylvania Avenue," "Joe's House" all refer to the same place. We use this construct all the time and we handicap BNS by disabling it.

I want to say I agree very much with @larrysalibra and everything he stated. There are many, many reasons why it might be advantageous to have many pointers to a single keypair. To me, all the commentary around race-conditions or concerns at that level are implementation details, and not the responsibility of BNS to control. I also have spent a long time trying to understand the real security concerns here, and I cannot really see it.

Agree with @markmhx - fail to see the security flaw here. Seems like re-enabling multiple names would be major improvement and solve @314159265359879's problem!

This 1000x.

I think there is talk around forming a working group for this set of features/needs, and I think that makes sense as a path for moving forward. This is a decentralized network, and the community is the ultimate actor when it comes to what should or should not be included or added. No single person should (or even be able) prevent something that the community wants or needs.

@314159265359879 @friedger @LNow @larrysalibra thank you for all chiming in, this kind of discussion is important — I think we should work together to push this forward.

[jcnelson]

The irony here is if we had continued this conversation before the launch of Stacks 2.0, we could have perhaps avoided the issue you point out here that moving away from "one name per address" now requires a hard fork.

This does not require a hard fork to fix -- you can fix this today without the SIP process. I'm sorry if that wasn't obvious. Let me explain.

If you are really want N-names-to-1-address, you can deploy a modified copy of BNS and make the authenticator point to that contract instead. There's nothing special about the one in the boot code. The only reason BNS is in the boot code is because we needed to migrate the old Stacks 1.0 names over, and we needed a contract in place to hold that state. Now that that's done, please feel free to deploy your own versions of BNS with your own rules, and have them reference the state in the old BNS smart contract. There's no need to involve the governance process in this -- anyone can deploy a smart contract to do this without anyone's permission.

You will likely want the new BNS to reference state in the old BNS in a read-only fashion. Fortunately, Clarity was designed to make exactly this sort of thing seamless. You would have your new BNS's resolver functions to use (at-block) to reference the old name state as it was at a fixed point in the past. The new BNS logic would work by first trying to look up a name in the new contract's data maps, and if the name is absent, it would use (at-block) to look up the name in the old BNS state as it was in the block right before the new BNS contract went live. Subsequent state-changes in the old BNS would not be reflected in the new BNS's resolver, effectively rendering the old BNS state read-only from the perspectives of the new BNS's users.

This strategy also works if you need to directly query the data maps (e.g. so you can get a Merkle proof). If the name record isn't in the new BNS contract's data maps, then to access historic BNS state, you simply supply the id-block-hash of the Stacks block whose block hash is passed into (at-block) as the tip= query string parameter when you issue the query against /v2/map_entry. (Note that the id-block-hash and block hash are different identifiers for the same Stacks block -- the former is a globally-unique identifier for the block in the MARF, and the latter is simply the hash of the block header (which is not guaranteed to be unique across PoX forks)).

This was always possible. No one is locked into using the BNS contract in the boot code. Again, sorry if this was not obvious.

To the contrary, several of us are pleading with you to reconsider, which you refused to do. You simply left a final comment and closed it at will, effectively shutting down the conversation.

We seem to have very different recollections about this conversation. Here's what I said at the end of that thread:

I don't think it's a good use of the blockchain team's time to be
re-writing significant portions of BNS this close to the release
when viable alternatives exist. So, I'm going to close this issue as
"not-a-bug." Please re-open only if you are able to come up with
a plausible app that is truly impossible to create without it.

Have you since come up with a plausible app that is truly impossible to create without N-names-1-address? And now that the system is live, what is the specific reason that this plausible app requires that this particular BNS contract in the boot code be retroactively modified in a hard fork, instead of the alternative approach I described above? If there aren't any compelling answers to both of these questions, then I stand by the design choices the blockchain team made in BNS. It's bad practice to build features that we have to live with forever which don't have a clear and unambiguous need.

You and others are free to disagree with that decision. But keep in mind that you are not and have never been locked into using the boot code BNS contract. You've always had the option of making a new BNS contract that does what you want, and reuses the state in the old BNS. You could have done this the day Stacks 2.0 launched. You could have done this before btc.us launched.

We're all going to ship suboptimal code – all of us. Instead of writing each other off, let's learn from each other.

The blockchain team did learn. It is factually true that all of the Stacks 1.0 wallets were broken in this way. The hard-won lesson learned is that this isn't a problem that wallets could be relied upon to solve in practice. Not only is there no fundamental way to prevent users from registering multiple names to the same address when they did not intend to do so, but also it was never a high enough priority for any wallet project to try and mitigate (hence "they had their chance"). So the blockchain team took it upon itself to fix it, and in doing so, fix all wallets with one fell swoop. Per the above issue thread, we did ask for compelling reasons for preserving N-names-1-address back in January, but heard nothing back -- neither from the wallet devs, nor from Hiro management (which I took as acquiescence).

However, I haven't seen any similar learning from the wallet teams. Instead, I see some devs asking to revert the system to a familiar but known-broken state, via the most disruptive, least thoughtful means possible (i.e. a hard fork), despite the existence of reasonable alternatives that are ready to ship today (i.e. deploy a new BNS contract), without so much as a suggestion on how they intend to address the accidental-name-registration problem that would result from the reversion. The wallet teams may have the best of intentions for wanting this (and for what it's worth, I believe that they do), but good intentions aren't enough. Also, "known-broken state" is an accurate characterization of the state of affairs since there is a multi-year history of bug reports and user harm stemming from the design decision made in Stacks 1.0 to permit N-names-1-address.

That said, I actually like @314159265359879's proposal, since I think it would both solve the accidental-multiple-name-registration problem while permitting multiple names per address for use-cases where it doesn't matter (i.e. trading). It takes the lessons learned into account. I think if either @314159265359879 or someone else here wanted to build a new BNS that had this behavior, it would be well-received.

---

You ultimately don't need to prove anything to me. No one does. Feel free to ignore everything I just said about the philosophy of 1-name-1-address vs N-names-1-address. Maybe from your perspective, N-names-1-address is not setting users up for failure (despite the history of bug reports). Maybe I'm in the wrong for considering their plight to be worth changing the behavior of BNS.

I can't stop you from deploying a modified version of BNS that restores N-names-1-address, and will not try to do so. If you feel this strongly about, I sincerely hope you do so. I'll even help you design and implement it if you need guidance. And if it gets enough traction from the ecosystem, I'll also gladly help shepherd a SIP that declares this new BNS contract the authoritative BNS contract and officially deprecates the one in the boot code. I will do all of this and more, despite my personal reservations, because I ultimately want the blockchain to meet the needs of its users.

But, I currently see no reason at all to do this via a hard fork.

[314159265359879]

Thank you all for adding to this discussion, I think this thread will be a go to reference for years to come. @markmhx thank you in particular for this post where you reference the old discussion I think that is very valuable and that is exactly what I was missing when I started this thread.

I started this thread with a problem statement, a proposed solution, and 5 questions I would like to get back to those and abstract the answers.

Statement: difficulty to make a marketplace with current limitation of 1 name per address.
I think rickey.btc proved that building a BNS marketplace is possible with the limitation: price.btc.us and he provides two ways to bid on and trade names. I think his second approach is the most elegant one where names are not even transferred to a proxy contract. The bidder escrows the STX-bid to the market-contract and when the seller accepts the BNS name is send straight to the buyer and the STX on the contract go to the buyer. Only addresses that have no name can bid.
Read more here: https://forum.stacks.org/t/brought-a-simple-domain-market/12388
Help test it and provide feedback if you can.
A third way to trade BNS names is described by jcnelson here I think in this example the escrow contracts are used after the buyer/seller settle on a price. Price.btc.us uses the proxy contracts to allow straight buy (comparable with the buy-it-now option on ebay).

Starting questions and abstracted answers
1. What are the reasons to limit a principle to have a maximum of one address again? I believe there to be a good reason because prior to Stacks 1.0 it was possible.

• Enforcing the one name limit on the protocol level is a way to make sure we do not repeat the problems in Stacks 1.0 where user (or dapp) would unknowingly and unwillingly register more than one name to a principle causing bugs and privacy issues.
• Using a public key or BNS name = a pseudonym: it is bad privacy/crypto practice/hygiene to allow such user error (or evil code?) to connect pseudonyms.
• Personal note: I agree that doing this at the protocol level is a good idea otherwise "can't be evil" does not apply.
• If you do want more than one name to point to a single principle that is possible today as described here. This would be a deliberate action by the user. @jcnelson How do you make this possible with a user friendly Dapp?

2. You can work around the limitations by using proxy contracts. How does that work and what are the main objections?
Rickey.btc found a limit in the number of contracts he can use at the same time, he wanted 500 but 250 seems to be a (clarity?) limitation he could not fully explain (see forum post) I have only ever seen about 170 BNS transactions in a single block so perhaps you do not even need that many if you would use Jude's approach. I can understand why Rickey.btc would like more buy-it-now auctions (Ads in his app).

3. If we deploy a new BNS contract how would that influence the work already done on the stacks-did-resolver by Jolocom?
No answer on this yet but I expect it would need to be reworked as was required for going from Stacks 1.0 to Stacks 2.0 but the difference would be smaller.

Proposed solution: If we could allow a contract to wrap a BNS name and 'deactivate' it for the purpose of trading it that would make it developer and user friendlier to make a marketplace for BNS names.
-- perhaps a bit like an expired name, which an address apparently can hold several of, but only one can be active.

4. @jcnelson what do you think of this? do you have an alternative idea of how to work with the limitation or a solution?
(yes, alternatives above and)
jcnelson quote from 23rd of September

That said, I actually like @314159265359879's proposal, since I think it would both solve the accidental-multiple-name-registration problem while permitting multiple names per address for use-cases where it doesn't matter (i.e. trading). It takes the lessons learned into account. I think if either @314159265359879 or someone else here wanted to build a new BNS that had this behavior, it would be well-received.

5. and could this be added to Stacks 2.1 if we can come to an agreeable (yet consensus breaking) solution?
Any change to BNS can be made by deploying a new BNS contract this is not a consensus breaking change (details).

All in all I think the proposed solution would make it more user and developer friendly to trade BNS names but there are already solutions live that make trading BNS names possible today, one of which imposes no limit to how many names can be listed on the marketplace at once.

[joberding]

I would like to note that no community conversation should ever be shut down unless there is a violation of the code of conduct. When I drafted the COC, I knew that there should be enforcement/moderation guidelines and mentioned it at that time. It looks like now is the time for that work to begin.

Kudos to all viewpoints expressed in this thread. It looks like you may be moving forward in the same direction.

[314159265359879]

A little more context and ideas.
First of all thank you @larrysalibra for this initiative: the BNS Working Group: https://forum.stacks.org/t/creating-a-bns-working-group/12491

I had a conversation with Rickey.btc who build price.btc.us and he thinks the current solution with one name is easier to work with and acts better for privacy. He agrees that there is value in having the option to allow more than one name on a principle. Based on this thread he thinks that allowing more names is more popular.
He fears that people who have already registered a name with the current BNS name will not be happy if a new contract is introduced if that means they can "lose" their name. I think we can make sure that if a new BNS contract (lets call it BNS v2) is deployed current names are imported and registered to the existing owners to avoid this issue.
Example:
If someone owns 1874.btc in BNS contract 1v0 (current contract)
They will also get 1874.btc in BNS contract 2v0 (new), the import function can be used to that end before the BNS name is launched (=before the namespace-ready function is called).

We may need additional code so we can do an "import" of the current (BNS v1) namespaces too. That would avoid needing to burn STX to register the same namespaces in the BNS v2 contract.

[aulneau]

I think the suggestion of forking BNS or implementing a new contract is generally unrealistic. The level of organization and changes to implementations across the entire ecosystem (things like APIs, SDKs, App chains even implement the BNS contract) to support it would be nearly impossible in my opinion. In addition, it would be very confusing and hard for anyone who doesn't have an in-depth understanding of BNS to know which one to use. There are a myriad of additional reasons for why it would be less ideal to have to create either an abstraction on top of, or an entirely new BNS contract in place of the current one.

I'm excited to be apart of the BNS working group and look forward to what can be explored as alternative solutions to this problem and others, and to form a community around BNS to show it the love it deserves.

[jcnelson]

I think the suggestion of forking BNS or implementing a new contract is generally unrealistic.

I think it's your most realistic option. The alternative is a hard fork to replace the contract. Not only would that a mighty technical undertaking that I don't think anyone here has both the desire and technical competence to carry out (i.e. the blockchain code assumes basically everywhere that contracts never change), but it would utterly defeat the purpose of using a blockchain at all.

In the spirit of this, the governance process currently does not provide any general provision for altering already-deployed smart contracts. The closest we have is SIP-011 (which is still in draft status), and it explicitly declares that the only excuse for altering the consensus rules (which would include altering a smart contract retroactively) is if the blockchain is dead in the water and unable to operate in its current state with the current rules. We are nowhere near that with BNS.

In a similar vein, you might be interested to know that we're not replacing .pox in Stacks 2.1. We're creating a new contract .pox-2.1, and having users individually migrate their locking state to it. That's less painful than trying to replace the code. Likewise, SIP 012 proposes adding .costs-2.05 to define new runtime costs -- it's not replacing .costs.

Also, the only reason Stacks 2.1 and SIP 012's new contracts need to be deployed as breaking changes is because these contracts hook directly into consensus rules. The return value of stacking operations in .pox and .pox-2.1 are used to alter a user's balance directly in the Clarity VM to prevent them from spending. The code bodies of cost functions in .costs and .costs-2.05 are evaluated each time the VM does something that fills block space.

This is not true of BNS -- there's nothing special about it. The system treats it like any other smart contract; it doesn't hook into the consensus rules. This is why you don't need a network upgrade to deploy a new BNS.

The level of organization and changes to implementations across the entire ecosystem (things like APIs, SDKs, App chains even implement the BNS contract) to support it would be nearly impossible in my opinion.

Why not just make the BNS contract upgradable? Like, what's wrong with this approach?

1. Create a "BNS pointer contract" that does the following:
   1. Store the address of the "authoritative" BNS smart contract as a data-var
   2. Implement a way for Stackers to vote to change the "authoritative" BNS smart contract address
2. Have this "BNS pointer contract" point to the current .bns smart contract
3. Have the SDK and API try to query this "BNS pointer contract" to identify which BNS smart contract is authoritative, or if it's absent, fall back to the one in the boot code.
4. Deploy your new BNS smart contract
5. Convince Stackers to vote in the "BNS pointer contract" to change the authoritative BNS smart contract.
6. If there's ever a new BNS smart contract you want to use, repeat steps 4 and 5 to migrate the ecosystem over to it.

Steps 1-3 only have to be done once. After that, the community can publish updates to BNS whenever it wants, and the rest of the ecosystem will automatically learn which BNS contract to use.

In addition, it would be very confusing and hard for anyone who doesn't have an in-depth understanding of BNS to know which one to use.

Isn't the wallet / SDK / API responsible for determining which BNS contract is the "real" BNS contract today? There's nothing special about the current BNS address -- it's just a constant right now. If you made it so that the constant is instead learned from a BNS-specific governance contract, then the act of determining which BNS to use can be fully automated.