Why do we have a different root derivation for deposit wallet and Shelly wallet?

[abailly]

The Deposit wallet's Agda specification uses 1857 as its root derivation key whereas the Shelley wallet uses 1852 as prescribed by CIP-1852.

I don't understand the reason why there needs 2 different root keys. On the contrary, it seems to me using the same root key in the deposit wallet than in the Shelley wallet will considerably smoothen the transition from one to the other and therefore foster adoption of Deposit wallet.

Could someone more knowledgeable than me shed light on this decision? @HeinrichApfelmus @david-a-clark

[HeinrichApfelmus]

The devil is in the details. Essentially, the wording of CIP-1852 implies that it uses BIP-44-style account discovery — but a key difference between "Shelley" wallets and the Deposit Wallet is that the latter does not do address discovery.

The question is: What information do I need in order to restore the entire wallet balance from reading the blockchain? The answers are different:

• CIP-1852: You need the root private key.
• Deposit Wallet: You need the root private key and the number of customer addresses.

Hence my decision to introduce a new prefix 1857 for the Deposit Wallet.

For reference:

CIP-1852:

Cardano extends the BIP44 by adding new chains used for different purposes. This document outlines how key derivation is done and acts as a registry for different chains used by Cardano wallets.

BIP-44:

When the master seed is imported from an external source the software should start to discover the accounts in the following manner:

derive the first account's node (index = 0)
derive the external chain node of this account
scan addresses of the external chain; respect the gap limit described below
if no transactions are found on the external chain, stop discovery
if there are some transactions, increase the account index and go to step 1
This algorithm is successful because software should disallow creation of new accounts if previous one has no transaction history, as described in chapter "Account" above.

[abailly]

Great, so it seems I wasn't too far off after all :)

I agree the latter could be confusing, but on the other hand, we are talking about a case where someone has 1/ switch to a deposit wallet first then 2/ done operations through this new interface then 3/ reverts to using Shelley wallet.
While I can imagine this scenario could happen, it seems to me a bit contrived and a corner case we could mitigate relatively easily.
On the other hand, the scenario where a user previously using a Shelley wallet migrates to use exclusively a deposit wallet is much more likely to occur should we succeed to deliver a usable and useful wallet, and providing a smooth and cheap (actually free) migration path would be great.

[HeinrichApfelmus]

While I can imagine this scenario could happen, it seems to me a bit contrived and a corner case we could mitigate relatively easily.

If you are the one who explains to users why "their money is gone", be my guest. 😅 Personally, I'd preter to escalate subtle incompatibilities to obvious incompatibilities.

On the other hand, the scenario where a user previously using a Shelley wallet migrates to use exclusively a deposit wallet is much more likely to occur

I'm not sure that this scenario is likely to occur — users have historically used Byron-style wallets for this use case.

[abailly]

If you are the one who explains to users why "their money is gone", be my guest.

Sure, because we know their money is not gone and we will provide migration plans explaining in details what to do and not to do. Again assuming this is actually something people would do of course.

I'm not sure that this scenario is likely to occur — users have historically used Byron-style wallets for this use case.

Not sure I understand what use case you mean here: They use Byron wallets to migrate funds between wallets? Or they just use keep using Byron wallets and not care about Shelley wallets? Then shouldn't we want to migrate Byron users to Deposit wallet?

[HeinrichApfelmus]

Sure, because we know their money is not gone

Just to be clear: With this, the Deposit Wallet would be a wallet that uses the prefix m / 1852' for address derivation, but will not be compliant with the CIP-1852 standard. Users who stumble on this out-of-context will definitely believe that "their money is gone".

I once talked to someone who believed that they have lost everything on their hard drive, I never want to have that experience again — and I refuse to.

Or they just use keep using Byron wallets and not care about Shelley wallets?

Pretty much. As usual, more detailed insights into user behavior are not available to me.

[abailly]

With this, the Deposit Wallet would be a wallet that uses the prefix m / 1852' for address derivation, but will not be compliant with the CIP-1852 standard.

Standards are meant to evolve so I don't see this as a major hurdle. Especially if evolving the standard comes with benefits and can be communicated to users.

I never want to have that experience again — and I refuse to.

Understood.

more detailed insights into user behavior are not available to me.

That's indeed a problem: It might be the case we are trying to solve a problem nobody has.

[abailly]

A derivative question would be: If we want to define a new derivation scheme separate from CIP-1852's, shouldn't we go through the CIP process in order to receive feedback from potential wallet users and experts?

[HeinrichApfelmus]

Sure. I just felt that formalizing the CIP after having polished the ideas in an implementation would be the best way forward.

[abailly]

Here is a summary of the above discussion.

About addresses derivation:

• CIP-1852 is a standard that's implemented currently by the cardano-wallet and possibly other tool implementors (do we know if this is the case?), built on top of BIP-44 standard
• This standard not only defines the structure of derivation keys, eg. 1852H/1815H/0H/0/<index> but also how a wallet can reconstruct its state from the chain
• By using predefined address gap limit $g$ as a "stop marker", a CIP-1852 compliant wallet can only discover addresses derived from indices $i$ lower than some index $k$ s.t. $k$ is the first index of slice of empty addresses of length $g$
• In contrast, the deposit wallet can discover addresses using a similar derivation structure but at any index lower than some predefined bound $m$

If a shelley wallet and a deposit wallet, parameterised respectively by gap $g$ and bound $m$, share the same "address space", ie. use the same derivation structure with the same keys then:

1. Should the deposit wallet use an address (ask a user to deposit funds at some address, or use it as change, or issue a payment to that address) that's lower than $m$ but separated from other used addresses by a gap larger than $g$, then this address will be "invisible" to the shelley wallet. In practice this means the balance of the shelley wallet would go out of sync with the chain
2. On the other hand, this makes it trivial to "migrate" a shelley wallet to a deposit wallet: just set $m$ to the expected number of "accounts" and such that $m$ is larger than the largest index in use by the shelley wallet

If a shelley. wallet and a deposit wallet use the same root key but different "address spaces", e.g starting at 1852H for the former and 1857H for the latter, then:

1. Balances of the two wallets will be completely disjoint and each one will be able to reconstruct its state without any possibility for the other to interfere
2. Migrating a shelley wallet to a deposit wallet will require making transactions to map addresses from one space to the other

In the current design of the deposit wallet, it's been decided that preventing the risk of misuse in case a user would use both a shelley wallet and a deposit wallet was high enough to warrant introducing a new derivation structure.

@HeinrichApfelmus @david-a-clark Does it summarise faithfully the situation?

[HeinrichApfelmus]

Does it summarise faithfully the situation?

Yes, thank you! 👍