Monero: Add CAIP-10 spec

[silverpill]

For issue #41

[bumblefudge]

Hey @silverpill !

This is awesome! I enjoyed reading through all the links and learning about Monero's system, which I've never used and have only learned snippets about here and there before today.

Instead of going through and doing the purely editorial/uncontroversial stuff as one commit and the more substantive suggestions as "change requests" in github, I just went ahead (not entirely on purpose, haha) and did both in one huge commit which I pushed to the PR. Please review and change-request whatever you don't love about my edits, which might be factually or connotatively off in many places, or just do your own big commit before I re-review.

Thanks!

[silverpill]

@bumblefudge To be honest I don't think the updated text is an improvement over the one I submitted. It would be better to revert this commit and discuss issues one by one.

In particular, the Semantics section has become too verbose. It was meant to provide a concise introduction to Monero addresses, similar to CAIP-10 specs in other namespaces. The "payee" and "actor" terms are confusing and not used in the Monero community.

Also, it is not correct to say that CAIP-10 defines a common URI scheme because even if you think of CAIP-10 IDs as URIs, there's a different scheme for each namespace (bip122:, eip155:, monero:).

[bumblefudge]

Apologies for the over-edit, many CASA authors are inexperienced with this kind of thing and prefer a swift resolution to an editorial back-and-forth. As for verbosity or aesthetics, neither ranks very highly in my priorities as an editor here, but I do think that:

the best namespaces provide all the links and entry-level explanations of the context needed for developers to build wallet and/or dapp interfaces that interact with assets, contracts, and accounts of a given namespace

Note the and in links and entry-level explanations: given how these documents are read and who reads them, linking to the docs is necessary but insufficient, and I strongly encourage authors to surface (in spec text, not just in links) any footguns that someone very unfamiliar with Monero would thank you for pointing out to them interop issues in multichain contexts, particularly false equivalences between namespaces. This is why I brought out of the base58 links the crucial information that standard base58btc libraries won't work because of the padding, and also why I detailed that UTXO and other multi-address blockchains are NOT functionally similar to accounts in [almost every registered] namespace, where an EVM-style account model maps address 1:1 to wallets/actors in some contexts. It may feel excessively verbose compared to, say, an EIP or an IETF RFC, but the goals are different here: these are part specification and part implementation guidance for outsiders.

I'll reopen with all my edits as change requests, and you can wordsmith them as much as you like (your name will be on this, after all!) but please try to include these interop considerations-- the detail here is educational!

[bumblefudge]

Suggested change

	Monero chains use UTXO model and [Monero addresses][] are functionally similar to accounts in other namespaces.
	Monero chains use the UTXO accounting model, making [Monero addresses][] functionally similar to other UTXO-based namespaces, in that CAIP-10 identifiers represent **payee identifiers** (of which a given actor has many) rather than stable **actor identifiers**.

[silverpill]

CAIP-10 identifiers represent payee identifiers (of which a given actor has many) rather than stable actor identifiers

I think this is not correct. Each Monero address represents a separate identity. It has its own balance, it can be re-used, etc.

[bumblefudge]

Hmmm, you make a good point, they are independent and stable identities and in that sense a good analogue to an EVM-style account-address; what I'm confused on is the independent balance part, which is where I thought the analogy broke down (to the glee of privacy maxis who ridicule EVM 😅 ).

As for payee, I was kind of leaning on my admittedly superficial understanding of BTC terminology, where P2PK, P2PKH, and P2SH addresses are all "payees" (legitimate targets of a txn) even though they're not all actors or accounts.

Can you say more about the independent balance? I was under the impression that I send 10 coins each to 10 different subaddresses of an empty wallet, each will have a "virtual balance" of 10 but the raw address that owns all those subs could then send 100 to some third party and drop all those sub-balances to 0? I.e., I thought the "balances" of subaddresses were independent (but partial) views of a single balance (in the underlying ledger/accounting sense). Am I wrong?

[silverpill]

For practical purposes, subaddresses are distinct "boxes" with separate balances. See this RPC endpoint for example: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_balance

I don't know enough to say how it works under the hood. Generally, addresses in UTXO-based systems are abstractions, and on the base level there are discrete "notes" which you can spend only if you know the secret.

[bumblefudge]

Do you mean that in a Monero wallet, counterparties' various addresses are grouped into a logical unit representing the actor? This would align with other UTXO systems and my mental model, but making it painfully explicit is usually my goal here :D

Also, does the term also organize transactions on, say, block explorers or other ledger views?

Suggested change

	CAIP-10 "accounts" should not be confused with [Monero accounts][], which are used in Monero wallets for grouping related addresses and transactions.
	CAIP-10 "accounts" should not be confused with "[Monero accounts][]", a term used in Monero wallets for grouping related addresses and transactions by actor.

[silverpill]

Do you mean that in a Monero wallet, counterparties' various addresses are grouped into a logical unit representing the actor?

No, there are no on-chain links between addresses. Accounts only exist in the wallet, mostly for convenience. There was a similar entity in Bitcoin software, although they removed it later (see this RPC method: https://bitcoincore.org/en/doc/0.16.0/rpc/wallet/getaccount/).

Overall, Monero addresses are very similar to Bitcoin and Ethereum addresses.

Also, does the term also organize transactions on, say, block explorers or other ledger views?

No.

[silverpill]

a term used in Monero wallets for grouping related addresses and transactions by actor.

I think accounts are usually used to categorize one's own finances.

[bumblefudge]

Right, so it's a UX construct, not any kind of onchain data structure. That makes sense-- definitely worth warning people new to Monero that they will see the term "account" used in this way and it will NOT be a 1:1 map to CAIP-10s!

[silverpill]

@bumblefudge I accidentally committed the line... I shall fix it, but let's discuss it first.

CAIP-10 has the following summary:

CAIP-10 defines a way to identify an account in any blockchain specified by CAIP-2 blockchain id.

It uses the term "account". For CAIP-10 spec and many namespaces that totally makes sense. This is why I started Monero CAIP-10 document with a similar line, and then elaborated that "address" in Monero is similar to "account" in other namespaces (like Ethereum).

Do you think we should connect CAIP-10 "accounts" with Monero addresses in a different way?

[bumblefudge]

To be totally honest, CAIP-10 is final but I feel like the semantics of "account" aren't really explicit enough; if I can get some UTXO people to help me write it I might try writing an Informational CAIP to caveat and nuance this mapping a little, which is why I'm being so stubborn here about what does and doesn't work in the equivalence!

CAIP-10 doesn't really say if by "account" it means:

1. a "unit of accounting" (as in balance, whether public or requiring a key to see),
2. "distinct unit of account" (as in, a balance independent from any other),
3. "address" (string expresses a stable, addressable identity), AND
4. "actor" (as in payer/payee in a ledger-like transaction system).

In EVM and similar "account-based" networks, each wallet's address or CAIP-10 represents exactly one of each. But in a system where there are not 1:1 relationships between the four, it's not self-evident which interpretation best serves interoperability across systems.

I have been going on the assumption that # 3 above is the most important, because the other three options make far less sense reading them against the ## Semantics section of btc/caip10.md, which says P2SH addresses are "close enough" to the EVM account model and implies by omission that earlier P2PKH addresses are not. Since a given wallet/privatekey can generate multiple P2SH addresses and these payscripts can impose conditions, timelocks, etc, none of the other 3 seems valid. To further undermine my confidence here, though, the example given by that profile is not, in fact, a P2SH address, but a P2PKH one (it starts with 1 instead of 3 in base58 form). Later address types (taproot, segwit) aren't addressed at all!

I guess what I'm saying is that I'm over-editing your first line because I'm trying to make your summary of CAIP-10 more explicit than CAIP-10 is 😅

[silverpill]

I think of accounts as boxes that hold certain amounts of money. In Ethereum-like systems the balance is continuous: you can subtract or add any amount. In UTXO-based systems the box actually contains discrete "notes": you can take one note out and put a smaller one back, for example. It's called "address" but it nevertheless works like an account.

Some Bitcoin and Monero software introduce another level of abstraction ("wallets" or "accounts") in attempt to simplify address management, but in my opinion it's outside of CAIP-10 scope.

So in most (if not all) cases 1 and 3 will be the same thing (I don't quite understand the difference between 1 and 2). 4 is largely depends on how account is used. Sometimes it represents a unique identity. Sometimes several accounts are linked to one person.

which says P2SH addresses are "close enough" to the EVM account model and implies by omission that earlier P2PKH addresses are not.

IIRC both P2SH and P2PKH can have balances and therefore can be viewed as CAIP-10 accounts. Same for segwit, taproot and others.

[bumblefudge]

I think the trick here is that wallets aggregate accounts. for example, wallet A has accounts X, Y, and Z in them. each have 10btc in them. A can send someone 30btc taking notes out of all three-- that's what I meant by "independent" in #2. they can operate independently and each have a different balance, yet a single key/actor controls all three so that "independence" is only contingent on the information assymetry between A and its counterparties who don't realize those independent accounts are really one actor and can function as one account at will 😄

anyways thanks for thinking thru this with me, I think there's no change worth making here I just wanted to explore the mental model a bit!

[bumblefudge]

hey @silverpill very sorry for the interruption of service here! I'm fine with it as-is but u mentioned wanting to rollback a commit or something so tag me again if you want a rereview! I promise a much faster turnaround until IETF Prague 😉

[silverpill]

@bumblefudge Thank you! I reverted the commit, and I think this document is ready for the final review.

Side note: I'm currently using CAIP-10 IDs in the URI form:

caip:10:monero:418015bb9ae982a1975da7d79277c270:4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge

I hope CASA will eventually standardize caip: URI scheme :)