Megathread: BNS upgrade discussion

[hank]

Ever since the launch of Stacks 2.0, the Stacks and BNS community has engaged in discussions for what a BNS upgrade could look like. The BNS Working Group has made an effort to gather these discussions and contribute a set of proposals for discussion.

If you have feedback or something to discuss about a specific proposal, please respond in the respective proposal’s thread. Feel free to respond to this thread with overall feedback and suggestions.

The goal of these proposals is to focus solely on changed functionality. There are other topics, such as how these proposals can be decided on and how a BNS upgrade can occur, but those topics will be introduced at a later date.

Individual topics:

SIP9 Compatibility
Approvals
More than 1 name per address
Managed namespaces
Renewals
Registration flow
String data structures
Zonefile resolution
.btc pricing changes
sBTC

[larry]

Thank you for sharing this @hank!

[RagnarLifthrasir]

Thanks Hank. I’ll read these topics and share my feedback, if any.

[ThomasButcher]

Thank you Hank. I’ve made some comments and will continue to review and give feedback.

[snazzy]

Great work Hank! Left a few comments also.

[Pablo]

The only thing need to do is to fix bugs, which not need change the BNS contract itself.

SIP9 Compatibility:

CryptoPunks doesn’t hard fork to support ERC721.

Approvals:

The function isn’t that good. Many attacks in Etherum are caused by approval(e.g., phishing website, forget to cancel approval, approved contract has bug).

Currently, user won’t lost his name even when login in a phishing website. Because if attacker wants to steal his name, post-condistions will show that and user will refuse to sign.
However, if attacker calls the approval function only, user won’t realize that and probably will sign it, which leads to his name stolen.

Besides, marketplace isn’t a big thing. User can buy a name even it’s listed on another marketplace logically, user can also bid names in the marketplace, or upgrade to BNSx for convenience. In the future, there will be an aggregate marketplace probably.

More than 1 name per address:

rainer‘s opinion is convincing. BNS is a namespace ecosystem, rather than only support 1 namespace like ENS.

Managed namespaces:

Many things can be done by deploying a manager contract. It’s not good to add such specific and complex logic, which will also introduce extra attack vector.

Renewals:

1. Require payment for renewals:
   Can be fixed without change the BNS contract itself.

2. Set expiration to period after current expiration & Allow paying for multiple renewals at once:
   Probably better, but there are some tradeoffs. On one hand, it can help the namespace owner earn more, and reduce the probability that users forget to renew their names; While on the other hand, suppose situations as below:

   • Namespace owner set a wrong price(too low), then attackers can register/renewal plenty names to expire many years later.
   • Namespace owner wants to change the price 10 times higher for 1D/2D names, but founds that all these names have been renewed to expire many years later.
     
     

Registration flow:

The namespace owner can add logic in the manager contract if wants to forbidden front-running.

String data structures:

It’s better, mainly a UX improvement.

zonefile-resolution:

Can deploy a zone-file manager contract(if need).

.btc change:

1. Change the namespace’s lifetime:
   People register and trade .btc with the promise of 5 years renewal period, changing to 1 year is more like robbery. DON’T BE EVIL is a basic principle when make proposals.
2. Change the pricing formula:
   Need an accurate vote system to make sure the change is fair rather than decided by several people.
   
   

sBTC:

A namespace owner can add logic in the manager contract if like. Not need add such complex logic into BNS.

At last, I'd like to point out that(especially for 1-1 vs 1-N):
Anybody can deploy contracts and create his own name system. If it attracts the most people, it will be official certainly.

[hank]

Do you have a recommendation for how to fix bugs without making changes to the contract? Unless I’m missing something, I’m not sure how you could do something like make payment required for renewals without modifying the contract.

[larry]

Thanks again @hank for this and to everyone that commented on all the threads.

At tomorrow’s BNS Working Group meeting, let’s plan to discuss next steps and then any remaining time on the call can be used to further discuss the contentious proposals here:

mainly .btc pricing changes and multiple names per address.

We’ll also try to record the call for those that can’t make it.

Meeting details are here: BNS - New Internet Labs

[prc]

Hey guys, I’m Pedro and I am a blockchain engineer joining the Bitcoin and Stacks ecosystem. This work group interests me, how can I help out?

[hank]

Hey everybody,

I wanted to provide an update and some next steps here. Earlier this year, I joined Trust Machines, and since then my main focus has been to contribute to the Nakamoto and sBTC launches, which I believe are crucial for the entire Stacks ecosystem. I’ve always been invested in BNS, including the work we did to build BNSx and Dots at Mechanism. Even though my focus has since shifted away from BNS development, I’m as excited as ever about the potential for BNS. While I’m not working on BNS directly, I have been advising the Orange Domains team regarding ways to help BNS move forward. Orange Domains has been allocating a ton of resources to both BNS core upgrades and app development.

To that end, I’m excited to share that we have collaborated on next steps for nearly all of the technical upgrades discussed by the community over the past ~1 year with strong support. Below is an updated proposal for the work.

The following features have been determined doable:

1. SIP9 Compatibility - make BNS more composable and market-friendly
2. Multiple names per address - allow Stacks addresses to own more than one name
3. Managed namespace improvements - extended functionality for fully-customizable managed use-cases such as token-gating mints or paying with sip10 fungible tokens
4. Registration flow - improve both the UX and security of registrations
5. Require payment for renewals - a bug in the current version of BNS doesn’t actually charge users for renewals, even though that was the intended (and previous) functionality

There were a few items originally suggested for an upgrade, but were determined to either lack broad support or add too much complexity:

1. String Data Structure: the proposal was to change the underlying storage types for name and namespace to string-ascii, instead of the current buff. This was always considered a “nice to have,” but after looking more into the complexity of implementing this, it was determined that it wouldn’t be worth it.
2. Supporting sBTC for payment; managed namespaces support native name registration via any SIP010 token, including sBTC down the line. Additionally, wrapper contracts can provide functionality to pay for name registrations with sBTC and other tokens.
3. .btc pricing changes - overriding pricing and expirations for .btc names violates the original parameters of the namespace
4. Zonefile resolution changes - updates to how zonefiles are resolved and updated don’t need to be part of the v2 upgrade, as those changes can be implemented separately.

The development work on the BNS V2 smart contract is set to be completed by the end of May, 2024, to be followed by a transition and upgrade period for apps and protocols.

We’ve been gathering early feedback on the best path to provide users the option to use this upgraded BNS protocol. It’s not technically possible to automatically update the BNS contract from BNS V1 to BNS V2. The other paths worth considering are 1) forking BNS and providing everyone with their same name on V2, or 2) having users individually upgrade and migrate their names to BNS V2. Both options have pros and cons with complexities, costs, and considerations to be further explored. It’s important to note that any upgrade path will not allow names to be registered on BNS V2 that are already registered on V1.

We’d love to hear your thoughts and feedback. Cheers to further progress of the original Bitcoin Naming System

Thanks,

Hank

[Gina]

Thanks for sharing this update, Hank! As someone who has been in the BNS space since it first launched, I’m eager to see more tools available to builders and community members alike for a more robust and comprehensive naming system to go live with BNS V2. Let’s build!

[druiztm]

Hank, the team at Orange Domains want to express our gratitude for your leadership in kickstarting this necessary upgrade and carrying it forward to this point. The enhancements introduced in V2 are crucial for the growth and sustainability of BNS and the broader ecosystem. Your commitment to prioritizing user needs is evident, and we wholeheartedly endorse the decision for a hard fork, provided it is feasible to do so. Streamlining the process should not only alleviate technical complexities but also align seamlessly with the principles and values of Web3 culture.

Don

[3.id]

This is awesome, thanks for the update Hank!

A couple of things I was hoping for but don’t explicitly get a mention:

1. Bulk renewal (I presume this will be enabled by the multiple address per wallet move?)
2. Ability to register a domain for multiples of the underlying period - i.e. register a .id name for 3 years rather than the standard 1 (3 x 1 year), in the same tx.

Any thoughts on those?

On another note, is there a specific rationale for re-instating the fee to renew? Given that even if the bug weren’t present, the stacks would only be burned, is there an argument here to remove the renewal fee rather than bringing it back? I see that of huge benefit to the community, without any adverse effect on anyone. Interested in your thoughts.

[hank]

@3.id

Bulk renewal (I presume this will be enabled by the multiple address per wallet move?)

This won’t be a part of the core contract, but it’ll be 100% enabled by multiple addresses per wallet. A developer would have to build a “wrapper” contract that lets you renew multiple names in one tx. That would be pretty straightforward.

@3.id

Ability to register a domain for multiples of the underlying period - i.e. register a .id name for 3 years rather than the standard 1 (3 x 1 year), in the same tx.

I’m not actually sure what the latest is on that functionality, I think we’ll have more information once more details comes out.

[larry]

Thanks for the update @hank and congratulation on your new role!

All of this sounds great - look forward to giving more constructive feedback once we have some code to review!

Really excited to see the project finally moving forward…thanks to Orange Domains and @gina and @druiztm for picking up the ball and running with it!!

[nickgamma]

Really great to hear this — a massive step forward for BNS / Orange Domains. And no better person to be leading the initiative than Hank.

On behalf of thousands of Gamma users who’ve requested many of these features, and with an understanding of the poor user experience tradeoff of a manual per-user migration, we at Gamma support a fork of the BNS contract provided all V1 name provenance is preserved, which it sounds like it would be.

These changes will allow for a drastically improved experience for registering, collecting, trading, displaying, updating, and transferring BNS names, so we’d make it a priority to migrate to the new contract as soon as it is deployed and sufficiently tested.

[muneeb]

Thanks for sharing, Hank! It’s great to see the progress made. I’m excited for the future of BNS with the new V2 version live. I support the suggested changes to enable the next generation of BNS products. To me, it makes sense to optimize for the least amount of friction for users. I’m supportive of the hard fork path for users to see the benefits of the new BNS V2. Looking forward to hear what others think – thanks!

[peekaboo.btc]

@hank

of

Great update. Always support hank.
Just a suggestion: bnsv1 migration v2 emoji domain punycode can claim unicode?
Or is it more effective to prevent fakeways?

[snazzy]

Thank you for the update Hank, it’s amazing to read that BNS V2 is right around the corner! Thank you also @Gina, @druiztm and the other developers for forging ahead with this!

I’m in full support of the hard fork path for BNS V2, as it makes the most sense I believe. I’ll put this forward to the community now and encourage everyone to provide feedback.

Just a few questions on the upgrade:

1. Pricing - What happens when STX get’s to $100? Apologies for the speculation, but registration/renewals are going to become very expensive for the community! Is there a way that we can apply a $ ceiling to the cost of .btc names? I can see the arguments and counter arguments to this.
2. Renewal - If it isn’t possible to apply a ceiling, as per 3’s question could we allow holders to double or triple (2/3x) the expiry period? With ENS you can pay for 10’s or 100’s of years if you preferred until renewal. I personally don’t think this is the right approach, but it’s about finding a balance between cost and accessibility - if that’s possible. Cost shouldn’t be prohibitive, which is what we are seeing with ENS and of course the price of ETH.
3. The 2 STX Fee - I still believe the fee shouldn’t be burnt and should contribute to funding a treasury that can be used to support innovation and builders on Stacks. I’m seeing first hand the success that the DeGrants program has had and is having spearheaded by @HeroGamer. Thus far over 300k names have been registered equating to over 600,000 STX burnt, that’s $1.2m at current prices. Let’s put this STX to work to fund the ecosystem!

That’s all I can think of for now, thank you for all your hard work Hank & TM!