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.
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
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!
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.
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.
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.
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 .
Sorry but figured if people wanted to do some research into HNS, then Zach Brown does excellent blog coverage.
Just wondering Hank, is this soft-fork that the user’s opt in for akin to Handshake’s opt-in system? Installing resolvers on DNS servers, then you point your local DNS lookups to include the Handshake blockchain? Or is this something like a whole new browser being needed for lookups. (Puma Browser and Impervious). Either way or another… I’m pretty excited about this direction!
So you would shut out humanity’s hope by raising the domain registry and renewal price to almost blackmail amounts because you’re angry someone had the foresight to register alot of 3 letter domains?
I’m getting broggled. Mind boggling + Mind Broken.
We’re working on publishing more details and documentation, but we wanted to share details for app developers who have expressed interest in building with us on what we’re calling “BNS X”.
. Will check in with your twitter accounts for updates 
.