What is the rationale of the “internal” key chain?

Developers Misc Dev Talk
1

In CIP-1852 (https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852), the keys with the derivation paths m/1852'/1815'/0'/1/<n> are defined to be the “Internal Chain”.

These are the ones that, e.g., in Yoroi are shown at “Base – Internal” and in ccvault as “Internal Change Addresses”. They are used by all wallet apps (that are not single address) for the change coming back from transactions. And they often have warnings to not give them out as receive addresses, e.g., ccvault: “Don’t share internal addresses, always give out external addresses.”

What is the rationale behind this? CIP-1852 unfortunately does not have a rationale section.

It can’t be privacy (although Yoroi gets this totally wrong, at least in the texts in the user interface) and ccvault knows that very well, but they still advise against giving them out. Why?

2

Not sure if you are asking for rationale for existence of internal key chain or rationale not to give away your change address for inputs. So, I’ll try for both :smiley:

Guessing here: Rationale for light wallets asking to not share change address maybe because they only put a public key for generation of new external addresses on their server(s). So, using up change address may not generate new unused address automatically if code checks for that.

Could be just keeping as least amount of public keys as possible associated with their server/users in one specific location (making it harder to be tracked, although not much harder).

Also, they may have separate servers with different levels of security. They could keep ‘all’ keys they can have from you on one server/storage and just public external chain key on different server/ storage that has different permissions/uses/code.

Could be something as bad as not being able to give correct balance if wallet checks only for existence of UTxO in predetermined number of addresses. So, if you manage to create an address pass what it checks and use change address from that it may not search for it.

Maybe that UTxO selection algorithm has preference for change addresses in order to get rid of dust and they don’t want to run a large code to sort out by size (or randomness).

Kind of hard to tell since ccvault doesn’t seem to be open source.

Rationale for existence of internal key chain goes back to Bitcoin. (This one is not a guess) They try to organize a wallet to be multilayered in order to increase anonymity and layer controls and permissions. This is the origin of Hierarchical Deterministic Wallets. Also, made watch-only wallet possible. That was BIP-32 :

Hope at least some of this is useful in your search.

2 Likes
3

I guess, I was asking for both. :grinning:

Thank you for the detailed answer!

It never occurred to me that they might put anything wallet-specific on their servers. I thought everything was done on the client side. But yes, is possible that they cache on the server to provide a faster user experience. But I really do hope that only public keys are stored on server if any keys at all.

Possible, but: I’m using a lot of apps at the same time with the same wallets and so far they did not have any problems to synchronise transactions done by the others. If they were that bad in keeping track, (change) addresses used by other apps would also be a problem, wouldn’t they?

That’s a very interesting point, although you are right: Selecting from all UTxOs irrespective if internal or external chain probably gives better results.

I could at least look at the others that are open source. One of the very few disadvantages of my favourite wallet app that it is not. :unamused:

Ah, yes the web shop example (it only needs to derive public keys on the external chain, not the internal one) is interesting. Seems to be kind of voided by Cardano’s (or at least its wallet apps’) decision to encode the stake address everywhere, so it is all very much non-anonymous, anyway. And – even in Bitcoin or with undelegated Cardano addresses – you can, of course, still do a lot by tracing transactions and guessing, which of the outputs might be a third party and which might be a change address belonging to the same person.

Watch-only needs the derivation tree structure, but not necessarily the division into external and internal chain. Chain and single address are derived non-hardened, so it should be enough to store the extended public key of the wallet (m/1852'/1815'/0' for single account wallet apps, m/1852'/1815'/1', m/1852'/1815'/2', … for the wallet apps that support multiple accounts) to derive all public keys, all addresses on all chains without the possibility to ever generate a private key.

I have to take a closer a look at which public keys they request from the Ledger, when next connecting them all. And if the different apps do something differently there.

Yes, thank you very much!

I’m still not ruling out that they just do it out of “tradition”.

4

I found a possible reason, here: https://input-output-hk.github.io/cardano-wallet/concepts/hierarchical-deterministic-wallets#account-discovery

We scan just the external chains, because internal chains receive only coins that come from the associated external chains.

Would be a reason.

Perhaps a little strange, because it does not add so much overhead to also scan the internal chain. (Yes, it doubles, but it also only doubles.)

Moreover, the semi-official wallet apps Daedalus and Yoroi, do not provide account functionality, anyway, and all wallet apps that do that I have seen do not do this automatic discovery, but require you to manually add additional accounts if you know they have been used.

1 Like