Monero namespace

[silverpill]

CAIP-2

Suggested namespace: monero.

There is one mainnet and two public testnets: https://monerodocs.org/infrastructure/networks/. These networks don't have universally-agreed chain IDs. Most of the time people use labels mainnet, stagenet and testnet, and the software returns these labels in some RPC responses, for example here:

https://www.getmonero.org/resources/developer-guides/daemon-rpc.html#get_info

nettype - string; Network type (one of mainnet, stagenet or testnet).

Internally, software defines NETWORK_ID constants for each network, but I don't know where these identifiers are used:

https://github.com/monero-project/monero/blob/v0.18.1.2/src/cryptonote_config.h

It is also possible to create a private testnet, often referred to as regtest.

---

There's a number of Monero forks, most notable of them is Wownero: https://wownero.org (as far as I know it is a separate chain which has a different genesis block).

Wownero community uses the same network labels (mainnet, stagenet, testnet), but in the source code Wownero has different NETWORK_ID constants:

https://git.wownero.com/wownero/wownero/src/tag/v0.10.0.3/src/cryptonote_config.h

---

If forks will not be included in the namespace, we can just use network labels. Otherwise, it might make sense to use NETWORK_ID, truncated hash of genesis transaction or some other identifier.

CAIP-10

Monero currently has three types of addresses:

• https://monerodocs.org/public-address/standard-address/
• https://monerodocs.org/public-address/subaddress/
• https://monerodocs.org/public-address/integrated-address/

The length varies between 95 and 106 characters, so it exceeds 64-char limit set by CAIP-10 (which is being discussed in ChainAgnostic/CAIPs#179).
The public spend key has the size of 32 bytes, so it potentially can be used as CAIP-10 account identifier, though I'm not sure if it's safe to do that.

[bumblefudge]

CAIP-2:

Wownero and future forks would ideally be included in the namespace, unless it's a drastically different VM Set of shared assumptions about chain integrity, node RPC definitions, and addressing/cryptography patterns [edit 23Jan 23.]? The point of CAIP-2 is to allow private chains and forks that share the same VMs/node software to address chain-specifically, so the default barring exceptional reasons not to is always to write VM-wide (or at least addressing-system-wide) namespaces.

CAIP-10

I think the max will be bumped to 128 officially soon, which would be preferable to forcing exposure to public spend keys as a precondition of CAIP conformance! I'll circle back

[silverpill]

Wownero and future forks would ideally be included in the namespace, unless it's a drastically different VM?

Wownero is very similar to Monero. There's no "Monero Virtual Machine", but these projects belong to the same software ecosystem.

[bumblefudge]

Hehe, you're right to point out the pro-smart-contract bias in my EVM mental model, of course each namespace doesn't map to a shared "VM"! I guess it would be a good modeling exercise to get more precise about what actually a ChainAgnostic Namespace shares, I'll open a separate issue to track this going forward.

As for the Monero namespace, let me know how else I can help bring this PR to fruition!

[sneurlax]

Monero's next major hard fork will be to move to an addressing scheme that's much longer than 128, more like 200

[silverpill]

@bumblefudge If we decide to identify Monero chains with genesis block hashes, perhaps we can simply use bip122 namespace?
I agree, any clarification on namespace boundaries would help

[bumblefudge]

I would say that Monero seems to me to be a namespace apart from BTC, in that there isn't a 1:1 relationship between monero chains and BTC/bip122 chains, or a roundtrip conversion possible between addresses, etc. If you click around on various namespace profiles, you'll see specific BIPs referenced in many non-bip122 namespaces, since so many ecosystems took core components of the BTC toolchain and made them integral in various ways elsewhere (more than half use the base58 BTC alphabet, for example, not just you guys!).

Many L1s that have their own consensus mechanisms, block/ledger formats, and node RPC interfaces are increasingly adopting an additional "EVM mode" RPC and a chainID in the eip155 namespace (e.g. Hedera or Filecoin), which complicates the namespace system and will probably be the subject of a new CAIP some time this year, or at least a reformat of the "readme.md" files. This doesn't seem like an example of that, though, as the Monero and BTC namespaces still seem quite distinct and aren't being bridged or made interoperable on some deep RPC or transaction or address/UTXO level, right?

All this to say, I'm learning as I go (I have to admit I'm pretty ignorant of Monero and glad for the opportunity to change that!) and hope I can help this namespace get written in a way that reduces the guesswork and educational lift for multi-namespace wallets and dapps looking to incrementally increase Monero support.

[bumblefudge]

I would also note that CAIP2s, CAIP10s, CAIP19s, and various others are best conceived of as export formats or translations of native addressing and identity schemes for the benefit of external consumers. just as genesis hash substrings are a one-way translation, would there be any possible deterministic re-encoding (using a bigger alphabet, for example) to get the same key represented in under 128 characters? I'm assuming base116 wouldn't be enough of a space-saver, but maybe something along those lines might work?

[silverpill]

...This doesn't seem like an example of that, though, as the Monero and BTC namespaces still seem quite distinct and aren't being bridged or made interoperable on some deep RPC or transaction or address/UTXO level, right?

Right, in terms of RPC endpoints and tx/address structure Bitcoin and Monero are very different.

I'm assuming base116 wouldn't be enough of a space-saver, but maybe something along those lines might work?

Yes... I think we can use base256 "binary-to-emoji" encoding

[bumblefudge]

i mean, on a quick search, it seems that for encoding and decoding things the base256 way, there is:

• a C library
• some C++ sample code
• a Rust crate
• an npm package

so... maybe that's an interesting direction to go in with this! it's definitely worth checking whether fits under 128chars (===64emojis???), as well as whether the emoji character set would create complications for non-HTTPS transports. if either snag proves fatal, perhaps running gzip on the longform native base58btc representation might also be a direction to look at?

down the road, the 128 character limit might be flexible (as kdenhartog mentioned in another thread, the post-quantum group at IETF is pushing VERY LONG key formats so privacy-oriented chains will surely join monero in the long address club over time), but in the meantime, today's CAIP-based and tooling could probably implement alternate characters sets (and/or compression)...

[silverpill]

@bumblefudge Is CAIP-10 required for CAIP-122? The spec is a bit ambiguous. According to data model table, address field must be a CAIP-10 identifier. But messages in "Examples" section include address and chain-id as separate fields, and CAIP-2 and CAIP-10 encodings are not used.

Does this mean that CAIP-10 identifiers are supposed to be used internally by the application, but not displayed to a user?

[silverpill]

I've submitted a PR with CAIP-2 spec for Monero: #65

While working on it, I also noticed a couple of documentation issues:

• The Contributing section of README.md points to the rejected CAIP-92 pull request. I guess the correct CAIP is 104?
• The Reference Formats and Templates section of CAIP-104 contains broken links to templates.