CHIP-0054: XCHandles - #192
Conversation
|
Hey, all! Wanted to provide some more context along with these CHIPs. I've been working on these dApps since I've come up with a solution to the problem of uniqueness - which translates to the past 1.5 years. The 'alpha' version has been working for over a year, which is why you'll see that most documentation pages were created ~1 year ago. I've spent the remaining time on major redesigns that resulted from private feedback. I'm now happy with the current design, and I'm releasing these CHIPs as drafts to start discussion about them in the broader Chia community. The latest version is written in Rue (Rue vs. Chialisp; cost/size comparison) and is currently undergoing another security-focused review. chia-wallet-sdk and the CLI are currently using the previous version, but will be updated after the review is finished. I have put a lot of effort into getting these applications to be as good as possible. If you have any feedback but don't want to post it here, please feel free to DM me to discuss on Twitter, Discord ( |
|
CHIP-54 is now a |
|
CHIP-55 is now a |
|
Please leave your reviews of CHIPs 54 and 55 here, and feel free to discuss them in the #chips channel of our Discord. |
|
We are going to hold a Zoom discussion of these CHIPs on March 13 at
Visit the #chips channel of our Discord for more details. |
|
The recording of Yak's presentation for these CHIPs is now available on Youtube. |
|
On XCHandles: curious how you think about XCHandles versus BIP353-style payment instructions. You mention in the FireAcademy announcement that XCHandles are DNS-inspired, and I'm wondering what you think about embracing DNS directly, paired with a human-readable encoding like name@domain? It's battle-tested at global scale (via email) and already familiar to every internet user. On CATalog: do you see it as potentially complementary to a separate registration proposal like Titled CATs? (Disclosure: I drafted that CHIP, so I'm biased here.) My view is that registration and curation are separable concerns. Asset identity is what users anchor trust to, so mutability there seems rarely desirable, whereas curation genuinely benefits from active stewardship. CATalog's unique value prop IMO is the curation layer. Folding registration into it conflates two things that could each be stronger as independent primitives. Would love to hear your thoughts! |
You could see handles as a blockchain-native DNS (esp. a potential DIG sub-registry). I think the goal here is to minimize (and eventually eliminate) trusted parties involved in the registration/resolution processes. The user would have full custody of their handle, which would coincide with that of their funds (hopefully much less likely to be compromised, which we see with DNS a bit too often). Another big advantage of doing things natively is convenience - asking the users registering the handles to pay, manage, and use an on-chain system is much easier than having them go to a registrar and navigating interfaces that were mainly designed for other purposes (websites/email/etc.). All in all, this is a chain-native option because Chia can support it - I see DNS as a work-around.
I've written about mutability in the discussions section of the linked CHIP. I think CATalog's strongest property is that the registration criteria is so flexible - it can become a repository of information for all TAILs. For special/non-ordinary cases where you need to register a lot of CATs (which I believe is why you started the new CHIP) or you can't predict the TAILs in advance (e.g., TibetSwap liquidity CATs), I think the curation layer can just be used with overrides (so you can have your own verifier containing all your CAT data - e.g., TibetSwap maintaining a verifier just for LP CATs that frontends would trust). I agree these are two separable layer, but they only form a solution to the problem of figuring out CAT details when taken/used them together, which is why I've grouped the system inside a single CHIP. If another solution becomes popular in the future, the verification layer can be extended to refer to data from outside the CATalog registry with enough support (likely a CHIP + community adoption). |
Yakuhito
changed the title
|
Hey all, I have two updates for you today. First, in case you missed it, I'm aiming to launch XCHandles soon. Please review the launch allocation methodology and let me know if you have any thoughts - I'm aiming to finalize the allocation as soon as the contributor allocation application window closes (~10 days from now). You can easily check your allocation on the main website. The on-chain code is working and has been reviewed a few times since my last update; as such, I'm requesting CHIP-0054 to be moved to Second, CHIP-0055 (CATalog) has been moved to a different PR. It will remain in |
|
This CHIP is now in |
|
I have no critiques of the design or the motivation for human-readable address names. I concede the point on trust-minimization, but I think it optimizes for a sophisticated minority, and the history of the web points toward a BIP353-style solution. There's clear precedent for users adopting a free name (email) provisioned by a trusted third party with the option to self-host, and BIP353 uses DNSSEC proofs to keep resolution verifiable client-side (with full sovereignty still available to anyone who holds their own domain and manages DNS). The overwhelming majority of email users have chosen a free hosted tier over paying recurring fees for a self-custodied domain and mail server, and no attempt at solving naming on other blockchains has broken out of its silo yet (though I'm optimistic on BIP353). The cost to providers is negligible so they can offer names for free and make it back through related services (e.g., CashApp could provision a free BIP353-style address for each user and recoup the cost through fees on Bitcoin sales in the app). One potential argument against this: wallet addresses are higher-stakes than email in that a provider that alters a record can redirect funds. In response I would say: sending wallets can pin previously-resolved addresses and flag changes, and anyone whose threat model rules out hosted names can hold their own domain. Any naming system where ownership can lapse or transfer carries some version of risk that "the name now points at someone new". My main concern is with establishing an on-chain paid registry as the ecosystem naming standard. I'd love to see wallets standardize on DNS-based resolution as the universal layer, with XCHandles as a fully decentralized namespace within it, so that the market can weigh trade-offs across options. This would give users the most optionality and avoid a multiple-standards problem for wallets if someone brings a BIP353-style solution to Chia in the future. Edit: There's even a pattern from TOR that is applicable here in that RFC 7686 reserves .onion as a special-use domain name, so software recognizes the suffix and routes resolution to the Tor network instead of DNS |
|
@EvanWinget quick question on BIP-353 use. What's the intended average user registration path? Power users can update their own DNS but most folks can't do that. A central service that propagates DNS for them? |
Correct - chia.net could offer addresses for all vault users, for example, and create DNS entries for everyone who sets up a human readable name I would expect that most exchanges and custodial wallet providers (CashApp, Coinbase, etc.) will add support for this type of a solution over time |
You can have a sub-registry that allows people to register handles for zero or near-zero registry fees too. You can also, as Josh Painter suggested, require just an annual ping/proof-of-activity to keep a handle registered (the pricing program format has been updated to support such a pricing puzzle). Fair handle allocation still remains a problem in that sub-registry, but, if you wanted to use it like we use emails today (long, specific names), it wouldn't be that big of a problem. Point is, easy/cheap onboarding is possible within the current system as well. I think the real deal-breaker for me is ownership. DNS is hierarchical and intermediary-dependent - even with DNSSEC, if most users have identifiers under Pinning helps after a trustworthy first resolution. It cannot protect a new sender looking up the address for a first time (what if In terms of standards, wallets and apps will ultimately decide whether to adopt this CHIP, DNS-based names, or something completely different. I think XCHandles is better viewed as a different solution rather than a namespace given the wildly different properties and trust model it has. There's no reason it should depend on a DNS parent layer. |
|
I can see your point @EvanWinget, but here's what I'm thinking about it: XCHandles should represent the sovereign choice. It does not need to standardize the separate use case of provider-issued names for users who are willing to register under a subregistry controlled by someone else, and I think that separation is fine. XCHandles already provides the generic subregistry primitive. In the future, a separate CHIP could standardize a particular kind of hosted subregistry: how free provider-issued aliases are created, resolved, revoked, transferred, and presented by wallets. That would allow a company such as Google to offer familiar aliases without registering a sovereign root handle for every user. Such a standard would complement XCHandles rather than change its underlying ownership model. I do not think that use case needs to be solved by this CHIP, but it is valid. Ideally, the standard should be driven by the first service that genuinely intends to offer it, so its design follows concrete operational requirements rather than a hypothetical feature nobody is yet implementing. On the DNS point, I agree that Tor is a useful example. The .onion suffix is a standardized convention, but onion addresses are still not resolved through DNS. Tor-aware software recognizes the suffix and routes the request through the onion-service protocol instead. I could make a Tor Browser fork that accepted .potato, mapped it internally to .onion, and reached the same onion services over the same network. The meaning of the suffix is therefore established and enforced by participating software rather than being inherently tied to DNS resolution. That is also the direction I think should be taken here in the future if we want Tor-like behavior: define a recognizable application-level convention and resolve it explicitly outside DNS, rather than making that behavior part of this CHIP. |
|
@Yakuhito you're right on the limitations of DNS and the (recommended) address rotation making pinning an issue with the BIP353-style approach Overall I'm excited about XCHandles going live as a decentralized system not dependent on DNS. My concern is that if XCHandles sees meaningful adoption, it will set the de facto user-facing format and the de facto resolution behavior for every Chia wallet, whether or not anyone specifies it, and that retrofitting a shared convention across wallets later is far more expensive than agreeing on one now. If a hosted or DNS-anchored alternative shows up in a year, I think we'll be paying that cost as a community. I could be wrong about how much it matters, and it don't want to hold up review. Thanks for the engagement and all of the work that has gone into building XCHandles! |
|
XCHandles will launch soon. More info here. |
5 participants
No description provided.