Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monero: Add CAIP-10 spec #86

Merged
merged 10 commits into from
Nov 23, 2023
Merged

Monero: Add CAIP-10 spec #86

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
a89f7f8
Monero: Add CAIP-10 spec
Aug 31, 2023
e926da1
editorial
bumblefudge Sep 1, 2023
d313514
Revert "editorial"
bumblefudge Sep 5, 2023
8dab810
editorial
bumblefudge Sep 5, 2023
0285e47
Update monero/caip10.md
silverpill Sep 5, 2023
f4b0d92
Base58-monero
silverpill Sep 5, 2023
3952a37
Change references
Sep 5, 2023
0d05654
Revert "Update monero/caip10.md"
Sep 27, 2023
95fd4d9
Merge branch 'main' into monero-caip-10
ligi Sep 30, 2023
b5c22ce
Merge branch 'main' into monero-caip-10
bumblefudge Oct 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions monero/caip10.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
namespace-identifier: monero-caip10
title: Monero - Addresses
author: silverpill (@silverpill)
discussions-to: https://github.com/ChainAgnostic/namespaces/issues/41
status: Draft
type: Informational
created: 2023-09-01
requires: ["CAIP-10"]
---

# CAIP-10

*For context, see the [CAIP-10][] specification.*

silverpill marked this conversation as resolved.
Show resolved Hide resolved
## Rationale

CAIP-10 defines a pattern for identifying an account in a blockchain.
Monero chains use UTXO model and [Monero addresses][] are functionally similar to accounts in other namespaces.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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**.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@bumblefudge bumblefudge Sep 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Semantics

Monero has several types of addresses: [standard address](https://monerodocs.org/public-address/standard-address/), [subaddress](https://monerodocs.org/public-address/subaddress/) and [integrated address](https://monerodocs.org/public-address/integrated-address/).
Any address contains network and address type identifiers, public spend key, public view key, a checksum, and may contain additional data depending on the address type.
Note that the [Base58-monero][base58-monero] encoding algorithm is used to encode the address from a byte array into a string; it uses the same alphabet as [base58btc][] but should not be decoded using [base58btc][] libraries due to the additional padding step to normalize string length.

CAIP-10 "accounts" should not be confused with [Monero accounts][], which are used in Monero wallets for grouping related addresses and transactions.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!


## Syntax

Monero CAIP-10 account ID is a case-sensitive string in the form:

```
account_id: chain_id + ":" + address
chain_id: See Monero CAIP-2 profile
address: [a-zA-Z0-9]{95,106}
```

The syntax of `chain_id` is specified in [Monero CAIP-2][].

## Test Cases

This is a list of manually composed examples:

```
# Monero mainnet standard address
monero:418015bb9ae982a1975da7d79277c270:4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge

# Monero mainnet integrated address
monero:418015bb9ae982a1975da7d79277c270:4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK

# Monero private testnet subaddress
monero:00000000000000000000000000000000:86MD1PNx3vmKUQjLvxNnmUfGQoHXAg8x56Nq97KrziKj5K8ACnpNUYx2KjiNAczP3igo7uUUUoGssDvKuZ7UUEoM1A8cvZs
```

## Additional Considerations

In the future new types of Monero addresses will be introduced.
They will likely be longer and may exceed the 128 character limit set in [CAIP-10][] specification.

## References

- [Address documentation][Monero Addresses] from Monero documentation
- [Account documentation][Monero Accounts] from Monero documentation

[CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md
[Monero addresses]: https://www.getmonero.org/resources/moneropedia/address.html
[Monero accounts]: https://www.getmonero.org/resources/moneropedia/account.html
[base58-monero]: https://monerodocs.org/cryptography/base58/
[Monero CAIP-2]: https://github.com/ChainAgnostic/namespaces/blob/main/monero/caip2.md
[base58btc]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02
[base58btc-alphabet]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02#section-21

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).