120% agree with what @rainer said.
The upgrade is irreversible and maybe should take more considration and debate.
2 Likes
I respect where you’re coming from, but I think this argument is fundamentally misguided for several reasons:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
7 Likes
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.
1 Like
In the Hiro Developer Call yesterday, @nickgamma suggested these improvements:
- Remove 1 per address limitation
- 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)
- Add associated addresses from other blockchains (e.g. associated ETH address).
- Add unicode support so we’re not an english-focused ecosystem only + emoji support, etc.
- Figure out how to handle the punycode → unicode situation and how we can make sure users have a good experience between the two
- Ensure the contract is upgradable without another SIP being required – perhaps using Executor DAO (a flexible, open source DAO framework on Stacks)
1 Like
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.
2 Likes
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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
1 Like
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
1 Like
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.
1 Like
what can prevent people from registering 1:1 even through they will have possibility to register 1:many?
1 Like
To everyone has contributed in this thread—thank you for helping to move progress on BNS forward!
Jeff and I have been chatting with a few of you and reflecting on these challenges. We’ve also been studying ENS, HNS, and Unstoppable and thinking about the future of decentralized identity—especially in connection to Bitcoin. With that said, we’re happy to announce that we’re heads-down building a protocol to upgrade BNS without requiring a hard fork.
Funny enough, Jeff and I first worked on BNS over 4 years ago, back when it was the “Blockstack Naming System”. We share the view that on-chain naming systems are a core part of a decentralized future. Today we’re letting the community know that we’re picking up the BNS torch again. We want to join with the rest of the community to move continue to improve BNS.
We’ve been trying to figure out the right way to do this. A separate hard-fork right now is way too messy, and it would impede shipping clear improvements in the short term. Instead, we’ve designed a system that starts out as a soft fork and allows users to opt-in and opt-out. We think this design is the right first step so we can improve BNS quickly and with little friction. In the long run, if this new system is successful and what the community wants, then it can be adopted as the “official” BNS.
We’ll share more details soon but wanted to highlight some key benefits we will include in our first release:
- A single address can own multiple names while having a “primary name” to keep things consistent
- SIP9 compliance for out-of-the-box wallet and marketplace compatibility
- A wrapping mechanism that will ensure backwards compatibility with BNS
If you want to follow our progress, follow and reach out at @mechanismhq, @heynky and @stackatron.
5 Likes
Louise thanks for starting this thread! Everyone else thanks for contributing all the great feedback. We’re super excited to work on BNS again!
Hank mentioned this but I’ll mention again: Migrating to a new version of BNS would require a hardfork. Trying to reach consensus on these types of design decisions has historically been slow (this thread demonstrates that and also the thread on mining).
We wanted to fix these problems fast but also felt a bit stuck by this hardfork requirement—that was until Hank conceived of this wrapping mechanism for backwards compatibility. We’re just going to try building it. We will work in public and deploy a version of BNS that can run in parallel, and be backwards compatible, forever if needed. If our upgrades are successful then eventually this new system can become adopted as the official BNS V2. If our changes suck, or another team wants to release an even better version, then no harm done. Flexibility and speed are our guiding principles on this one.
If you’re not familiar with my cofounder Hank: He was an early engineer at Hiro from 2018–2021 where he built the Hiro web wallet from the ground up. Hank is very knowledgable on BNS and Clarity. He has also gained a ton of trust with the Stacks engineering community over the years. I know he can do a great job taking the feedback above and swiftly shipping an 80/20 solution.
If you are a Stacks builder and have integrated with BNS please say hi. We are eager to help you succeed and would love to hear from you. We are busy coding but will be sharing more updates soon!
4 Likes
I very, very, very much doubt this.
1 Like
I think we’re on the same page - we’re working on plenty of cool stuff without hard forking. There are a whole class of features that would require a hardfork, though.
Sort of like PoX - could you build lots of great stuff on the original contract? Yes. But we needed to hard fork to add other things.
1 Like
EDIT: So, I’m a real heel here.
After speaking more with Hank about what he and Jeff intended to do, I was wrong to think that they were suggesting hard-forking the blockchain to change BNS. Instead, they were suggesting that a new version of BNS be incrementally deployed and that the ecosystem surrounding it would be “hard-forked” to use the new BNS contract. Hard-forking the blockchain was never on the table. This is in-line with what we had discussed earlier.
I would like to apologize to both Hank and Jeff, and to everyone here, for being too dismissive. I cannot think of a more qualified team for making these changes to BNS. Jeff and Hank have been pioneers in building products around decentralized identity since the mid-2010s, and I can’t wait to see what they have in store for us!
Original retracted comment below.
No, we are definitely not on the same page.
First, PoX is not a smart contract. It’s a piece of the Clarity VM that, for implementation simplicity, has a Clarity component to facilitate interactions with other Clarity contracts. Most of PoX is implemented in Rust; it’s Clarity-facing API is implemented in .pox.
Second, adding a .pox-2 contract is only necessary to expose new features of the PoX subsystem. The original .pox contract still exists and can be accessed in a read-only fashion. However, mutations are prohibited at the VM level because that version of the PoX subsystem itself is getting switched off.
Third, BNS is not part of the Clarity VM. It is just another smart contract. It has no special properties or hooks into the system, and it has nothing at all to do with the blockchain’s inner workings. Put another way, we could have launched Stacks without BNS, but we could not have launched it without .pox.
So, please do not use the fact that .pox-2 will exist in Stacks 2.1 and .pox will be defunct as precedent to hard-forking the blockchain to alter the behavior of an existing smart contract, because that is not what is happening here. It’s not even in the same category.
Again, I very much doubt it. You could soft fork the chain to get miners to ignore transactions that cause mutations to BNS v1, and once that soft-fork activates, BNS v2 could be instantiated to implement the de-facto BNS. BNS v2 would use (at-block ...) to resolve names in BNS v1, but would otherwise implement its data space in a copy-on-write fashion such that subsequent mutations to a name’s state would supersede any such state in BNS v1.
In general, I will not endorse a SIP that retroactively changes the behavior of a smart contract through a hard fork. This isn’t Ethereum.
1 Like
To be fair, we wrote a bunch of ambiguous language, with not much detail, and so your reaction is understandable! We’ll share more details soon, and then we can all debate the nitty gritty.
2 Likes
Hi Everbody!
Handshake are some of the most noble and altruistic builders I have ever come across. The only other blockchain which I’ve come into contact with which resonated the same has been… you guessed it, Stacks.
Handshake imo is also the only chain among the trio you mention which builds for noble reasons along the lines of a Bitcoin cyber-hornet. Money was the main impetus for ENS and Unstoppable existing it felt like. Handshake however was built on OSS principles, airdropped a huge amount of tokens to open source devs on GitHub. Even Satoshi wanted to implement a decentralized naming system to replace the current corrupt authorities who hold dominion over TLDs (Top level domains), After he had invented Bitcoin of course.
A Top level domain is the .com .net .org of the domain world.
A Domain could be considered the middle of the domain naming system and a subdomain is considered the prefix before the juicy middle domain. Handshake are the ONLY truly dedicated Proof of Work blockchain that lets you own your own TLD. ENS forces you to take a domain and subjugate yourself to their .eth TLD and is it Unstoppable that has the .crypto TLD? Anyways I digress…
Owning your own subdomain or domain, frankly feels quite silly and kiddy after the potential for what can be done for humanity and the world’s languages which are increasingly becoming more homogenized. By having access to the entire TLD range for every single hobbyist/user, decentralized identities become very interesting and extremely simple to create. Punycode on handshake is very liberal and gives the the ability to adopters to own the world’s words in their native alphabets.
I guess what I’m saying here ultimately is to plead that only the most altruistic of reasons come into play with the rollout of the inevitable beast that is and will be BNS. This is ground zero of the new internet as Handshake calls it. And they don’t refer to it as web3. They think of that term as broken and hijacked by centralized chains. dWeb or Decentralized Web is their term and it’s all about NO ONE being left behind… ideals which the crypto world need to take into consideration more if mass adoption and mass education is to occur.
Sorry I’ve been rambling, lack of sleep 
. Will check in with your twitter accounts for updates 
.
Kindest of regards,
tigs or Ollie W
1 Like