I vote in favor of upgrading the BNS contract to follow the ENS approach. I agree that the initial proposed solutions are way too complicated for most users. If BNS is going to be a staple of decentralized identity, which I hope it will be for the next millions (billions?!?) of users, it will need to be extremely simple. ENS already does this; no need to reinvent the wheel unless there would be major benefits from the other solutions, but it doesn’t seem like there will be.
I also vote in favor of @whoabuddy’s suggestion to form a DAO (based on the ExecutorDAO framework) to manage the BNS contracts. Decentralized identity requires decentralized governance. We also agree with @whoabuddy that using the ExecutorDAO framework for this DAO would be the way to go (indeed, it is the framework that StackerDAO Labs builds all of its product on) because it includes automatic smart contract execution, is extremely modular, and its structure can be easily changed as time goes on.
A DAO could be deployed that first functions as a multisig with members of the BNS working group as members. Then, as time goes on, different extensions can be enabled and disabled, allowing for progressive decentralization. For example, the working group can then add an extension to enable anyone with a .btc NFT to submit a proposal, but only the working group multisig signers could vote on proposals. This will allow more participation from the community, but still keep control among the multisig members in the early stage. Then, when it’s ready, the DAO can disable the multisig extension and enable an extension allowing .btc holders to vote on proposals (or issue a token like ENS and use that), achieving full decentralization.
StackerDAO Labs has actually just developed a product called Teams that uses the ExecutorDAO framework for this very purpose–a multisig primitive to manage assets and smart contracts. We have one Team being used by a small NFT project live on mainnet right now. The BNS working group could use a Team on our app, and then continue to use the StackerDAOs app when ready to decentralize to a full DAO. We would also happily facilitate the development of a UI for governance of the DAO on the BNS site if the community would prefer that governance lives there instead.
The benefit of this approach is that the core, which will own the BNS contracts, and the treasury contracts remain the same. Thus, there will be no need to transfer ownership of the BNS contracts or assets from the multisig to the DAO as they will be using the same core and treasury contracts–significantly reducing the potential for error when moving assets and changing contract ownership.
I think an improved BNS contract is the way to go too, one that takes the learnings from v1 to improve it. Modelling it after ENS seems like a great idea too with our own improvements on top sounds brilliant.
I think one of the things I would love to see in the new contract is non-custodial listing because that also removes the need for custodial/escrow contracts and still have the benefit of not requiring approval after a bid is made.
If a replacement contract is made I think airdropping the v2’s will be preferred, it will give the best user experience: even users that do not check in as often aren’t surprised by lost BNS names because they missed an arbitrary (180 days) window to burn the old one.
If you do not burn the old names it can also help in the period where software that relies on BNS has not been fully upgrade to BNSv2 (i.e. it can default to showing the BNSv1 name as long as it is not burned but left in the wallet).
I’m generally in the camp of working on BNS v2 and figuring out migration e.g., a snapshot of BNS v1 taken at a pre-announced block can work and v2 can just import all the state from the snapshot.
A general rule of thumb should be that devs shouldn’t be afraid to make re-write contracts and make them better. The ecosystem is in a relatively early stage and it’s easier to make more drastic changes now vs say years down the road.
Since we are upgrading BNS, I would like to propose an additional product requirement that would be immensely helpful not only to .btc names but Stacks in general?
Being able to send/receive BTC using .btc names.
The v2 contract should include a registry of addresses that correspond to each name. And users should be able to update it via contract calls. This should not be limited to Bitcoin addresses, it should support addresses for other blockchains as well.
I believe there are too many people who want this feature, and if implemented, spring is coming soon for Stacks! And is expected to break into the top 10 cryptocurrency rankings
The snapshot approach essentially means that each BNS operation (including lookups) are gated at a particular block. For lookups, this is straightforward: if the name doesn’t exist in BNSv2, then fall back to looking at BNSv1 as it was at the snapshot block and compensate for name expiration in the present.
For mutations (transfers, updates, revokes, renews), the logic is a little bit more involved. Basically, you’d lazily mint the name’s NFT in BNSv2 and copy over its state on its first post-snapshot mutation:
If this is the first mutation on this name since BNSv2 went live (synonymous with the snapshot block), then look up the name’s state from BNSv1 as of the snapshot, instantiate the name’s record and NFT in BNSv2, and carry out the operation on it in BNSv2.
Otherwise, just carry out the operation in BNSv2.
Looking at the BNSv1 code, there’s not much we can do for users whose preorder and register happens to straddle the snapshot since there’s no public function for querying BNSv1’s preorders (same for namespaces). Instead, name registrars and wallets would need to put up a banner informing users of the transition and/or temporarily suspend new registrations until BNSv2 went live.
If BNSv2 ever comes into existence, the creators would create a SIP for it so as to coordinate the transition in order to minimize the chance that users would be duped. The announcement would get blasted out on all the usual social channels as well.
I’m not too worried about this tbh, because this “attack” exists today, is trivial to pull off, and yet isn’t a problem in practice: today, someone could just make a fraudulent BNS site that eats your STX and mints you an NFT that originates from a copy of BNS they deployed for the purpose.
Will @friedger be the only person and Stacks resource applied here?
Where does Hiro and the Stacks Foundation stand today with regards to the storage and identity parts of the Stacks “Web3” platform? Is the future of these two explained in a roadmap or other doc somewhere? Maybe I missed it.
Granted, I realize v2.1 and subnets is the focus atm,
but it would be nice to know what the longer term plan is. @HeroGamer maybe this info was put forth in Hiro Engr meetings but not shared more broadly?
Was there consensus among the growing Stacks ecosystem entities that these things would no longer have much attention/work/resources?
I’m generally supportive of the BNS v2 approach laid out here as well. We’d look to support it fully in Hiro Wallet (with graceful fallbacks to v1 in the UX where needed).
We’re additionally looking to support BTC and STX transfers to BNS names (.btc and otherwise) in Hiro Wallet, so I’m also in favor of @yukan’s suggestion that we address those either as part of this v2 upgrade or soon after as part of the new DAO’s subsequent work.
This will be human friendly addressing in crypto, once ubiquitous, is such a big UX unlock for mass adoption. It makes you wonder why it has been so long in coming, at least to the Bitcoin and Ethereum ecosystems. Stacks bringing this to Bitcoin is a BIG deal!
Big +1 to this. You can think this as a directory or a phone book. muneeb.btc can point to my Bitcoin address and/or Lightning address and only I can update it in the registry/directory. The directory is stored on the global ledger of the Stacks layer (because you don’t want to store such extra data on the Bitcoin base layer) but the data on the Stacks layer is itself secured by Bitcoin (we can get into exactly how it is secured by Bitcoin and the answer will be different for 2.1 and earlier version and the next major upgrade that can bring Bitcoin finality).
I think the issue is similar to contract upgrades of other systems where it’s not possible to shutdown the v1. So there needs to be some social consensus e.g., if Hiro wallet, Gamma, explorer.stacks etc all start using BNS v2 and not v1 then you’ve hard forked to the new version.
Such a hardfork happened successfully when BNS moved from the earlier version implemented directly on Bitcoin to this version implemented on the Stacks layer. Theoretically, someone can go and register names on the old BNS on Bitcoin mainchain but practically it’s a non issue as that feature is not supported by any wallet, marketplace, CLI etc.
I’m supportive of more resources going to this. The Stacks Foundation is independent and can decide to do more grants for this (looking at you @blocks8 and @cuevasm!) but I’m happy to personally contribute grants and/or get some more engineering resources. I’d assume the Hiro wallet and Xverse wallet team have a business interest in this and would like to see movement on this front as well.
@larry wanted to work on a BNS working group back in the day. If there is enough demand, which I think there is, then I’d suggest forming a quick working group. Pulling in all the relevant parties and start making rapid progress towards the BNSv2. Excited!
Yes! We will need to educate people on the privacy implications though. Attaching these names to your main wallet can leak your transactions history to the world i.e., tie it with your identity.
Agree with @muneeb and @jude that writing a v2 and convincing people to switch is probably the best approach.
Sending assets to names is of course great - Stacks got started as “whitepages for bitcoin” back in the pre-Stacks v1.0 Onename days, so it’s awesome to see that there’s finally demand for the original functionality!
While we’re making product requests, I request that BNS stands for The Bitcoin Name System and that we figure out how to make v2 integrate more closely with Bitcoin.
Any group member (or anymore) can set up a meeting - there’s no need to ask my permission to do so. My goal was to herd all of the interested cats into the same virtual room.
Still happy to help and excited to contribute…either through a new group or the existing one.
It would be epic for BNS to support native BTC sending and receiving functions, but there would still be a question of how people would think the wallet was secure, how they would feel comfortable storing large amounts of BTC in Hiro wallets, whether there would be security audits, etc. In addition, the introduction of Hiro Wallet, a mobile client, will be more convenient
allow 1 more names will be a big mistake update, only in the early age people will hold a lot of names, one day there are billion people use BNS, most people will own only 1 name. And compared to the huge ammount user，name trade transation will much less , 1 adress 1 name hold a big advatage is that people dont need to resolve their address to domain in order to use like ENS，wilch will cause much more congestion problem in the future, because most people dont have the demand to trade names,but most people have to resolve name on chain. 1 name 1 address also provide porfect perfect anonymity ,people dont want to expose all thier tansation in a address.
allowing 1 more names will be a big mistake update, only at the early stage people will hold a lot of names, one day there are billion people using BNS, most people will own only 1 name, because 1 name 1 address reducing extra idea when people want to resgister more names due to the complex operation. At 1 MB Stacks block size ,now Stacks only support about 30million transactions every year, if there are billion BNS users, 1 name n address needs every BNS users to resolve BNS to address, that will cause really serious congestion problem.
And name trade transactions will be much less compared to the big quantity users. 1 address 1 name hold a big advatage that people dont need to resolve their address to domain in order to use like ENS, which will cause much more serious congestion problem in the future, because most people dont have the demand to trade their names,but most people have to resolve name on chain to use and show their name. 1 address n names also impedes BNS integrating with bitcoin and lightning, it will makes BNS users make a more step of resolving .btc to bitcoin address, that’s super inconvenient and not as safe as 1 native bitcoin address mapping 1 .btc name. 1 name 1 address leave users free from the resolving step,that will save huge block space for Stacks and makes BNS more convenient to use
1 name 1 address also provide perfect perfect anonymity, people dont want to expose all thier transactions in a address.
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.
human friendly addressing in crypto, once ubiquitous, is such a big UX unlock for mass adoption. It makes you wonder why it has been so long in coming, at least to the Bitcoin and Ethereum ecosystems. Stacks bringing this to Bitcoin is a BIG deal! 