Skip to content

Latest commit

 

History

History
67 lines (48 loc) · 3.39 KB

2022-06-02.md

File metadata and controls

67 lines (48 loc) · 3.39 KB

BNSWG 2022-06-02 1400-1500 UTC

Attendees: Larry Salibra, Phillip, Yukan Liao, Werner, Hero G, Marvin Janssen

Agenda

  • Upgrade path for BNS
  • Creation of a SIP proposal to fix existing bugs
  • Other business

Upgrade path for BNS

We discussed the options: hark-forking the existing contract with Stacks 2.1 vs deploying a new contract and getting other people to use it. As a lot of things are hardcoded to the current contract address, the general consensus seemed to be hardforking was the better method.

Proposing a SIP to fix problems with existing BNS contract

Larry proposed these items to be included in a proposed:

  • name-renewal should burn fees stacks-network/stacks-core#2973
  • name-renewal should transfer name to new owner (it appears not to do this now - Mark mentioned this is a known issue but I haven’t verified it myself)
  • multiple names per account
  • conform to SIP-0009 NFT standard

Discussion:

  • Multiple names per contract is allowed already if you include subdomains
  • One participant is launching a service that gives the subdomain on bns to the owner of the same ICANN subdomain
  • Pricing of namespaces is too rigid: it prevents use cases like Chile's NIC buying .cl and selling names with their ICANN names.
  • Why don't we have a voting contract for BNS? We have this for stacks. (Discussed in relationship to the inflexibility of name/namespace pricing)
  • The intent of proposing these bug fixes / non-controversial changes is to start a discussion about what we want for BNS in the future.

Other business

Xverse wants to make it so that you can send bitcoin to a BNS name.

  • Discussed proposing a SIP vs unilaterally coming up with their own format.

  • We talked about how hypothetically in the future it might make sense for standards that only relate to BNS to go through BNSIP process separate from the SIP process.

  • Larry mentioned that we previously had support for adding a bitcoin (or other addresses) to profiles. This is from larry.id's profile and how it was previously done:

{
  "identifier": "1EyuZ8qxdhHjcnTChwQLyQaN3cmdK55DkH",
  "role": "payment",
  "@type": "Account",
  "service": "bitcoin",
  "placeholder": false
}

Discussed about using BNS via bitcoin.

  • Prior to Stacks 2.0 you could registered some names with only BTC
  • We agree that BNS should be more tightly tied to bitcoin
  • We liked the idea of making BNS the best name system it can be for bitcoin.
  • It's unclear if we still register .ids with only bitcoin
  • Discussed the possibility of two approaches to tying BNS more closely to bitcoin
    1. Making it so that certain namespaces require you to send/burn some BTC to register a name in that namespace
    2. Make it possible to register names only through bitcoin without having to interact with stacks nodes at all - using something similar to the Stacks 1.0 OP_RETURN format. These names would exist in stacks nodes as well. It's unclear if stacks would be able to read them with current functionality today

Action items:

  • Separate controversial items in a separate SIP: multiple names per account was the only controversial item we found
  • ask Friedger:
    • if he's encountered any other bugs in the BNS smart contract
    • using BNS with bitcoin, ask about SIP process
  • ask Jude about ability to register .id names with bitcoin