<p>Hardened derivation requires knowledge of the private keys to be able to derive additional public keys. Since both Casa and their customer only control a subset of the private keys in the quorum, neither would be able to derive additional addresses without interacting with the other party, overall activating each and every private key in the quorum. This would be arduous given the intended setup with the customer's hardware wallets in multiple locations and one of the keys held by Casa staged in a key recovery scheme. Even worse, if any of the private keys got lost, it would not be possible to regenerate any of the prior addresses: only money from addresses already known would be recoverable, even if the remaining four private keys were available.</p>
<p>It follows that using non-hardened derivation in this setup provides a better user experience and arguably a better risk trade-off.</p>

CC BY-SA 4.0
2023-01-01T22:17:30.093Z
thanks for the response, but I still don't understand how would hardened path prevent them from generating addresses. If for example they would extract m/49'/0'/1' xpub from my HW, they'd still be able to derive m/49'/0'/1'/0/1..N. Maybe it doesn't make much sense to harden their key, but on the user side it creates a theoretical risk of exposing(by user) e.g. m/49/0/1/0/1 xpriv and being able to derive the master PK doesn't it?
beefgroin
CC BY-SA 4.0
2023-01-01T22:24:30.020Z
maybe I didn't make myself clear in the question. the addresses they derive are on top of the m/49/0/1, e.g. m/49/0/1/0/5. That's why I don't understand why wouldn't they ask for hardened m/49'/0'/1' instead when you add the key.
beefgroin
CC BY-SA 4.0
2023-01-03T16:41:37.197Z
Ah good question. I'll have to think about it.
Murch
CC BY-SA 4.0
2023-01-01T20:57:47.083Z
2023-01-01T20:57:47.083Z
Murch
<p>I've noticed that Casa uses non-hardened derivation paths for both their key and my HW keys.
The path is the following <code>m/49/0/1</code>.
Does anyone have an idea of why it's the case? I mean, the risk of exposing their child xpriv or HW's one is minimal but wouldn't it make sense to harden it just to be safer?</p>

<multi-signature><bip32-hd-wallets><xpub><hardened-derivation>
Why doesn't Casa use hardened derivation?
beefgroin
# Why doesn't Casa use hardened derivation?

(Asked by: username_0 on 2023-01-01)

I've noticed that Casa uses non-hardened derivation paths for both their key and my HW keys.
The path is the following `m/49/0/1`.
Does anyone have an idea of why it's the case? I mean, the risk of exposing their child xpriv or HW's one is minimal but wouldn't it make sense to harden it just to be safer?

**Tags:** multi-signature, bip32-hd-wallets, xpub, hardened-derivation


---

## 1 answers

### Answer by username_1 on 2023-01-01. Score: 2

Hardened derivation requires knowledge of the private keys to be able to derive additional public keys. Since both Casa and their customer only control a subset of the private keys in the quorum, neither would be able to derive additional addresses without interacting with the other party, overall activating each and every private key in the quorum. This would be arduous given the intended setup with the customer's hardware wallets in multiple locations and one of the keys held by Casa staged in a key recovery scheme. Even worse, if any of the private keys got lost, it would not be possible to regenerate any of the prior addresses: only money from addresses already known would be recoverable, even if the remaining four private keys were available.

It follows that using non-hardened derivation in this setup provides a better user experience and arguably a better risk trade-off.

> **Comments:**
> **username_0**: thanks for the response, but I still don't understand how would hardened path prevent them from generating addresses. If for example they would extract m/49'/0'/1' xpub from my HW, they'd still be able to derive m/49'/0'/1'/0/1..N. Maybe it doesn't make much sense to harden their key, but on the user side it creates a theoretical risk of exposing(by user) e.g. m/49/0/1/0/1 xpriv and being able to derive the master PK doesn't it?  
> **username_0**: maybe I didn't make myself clear in the question. the addresses they derive are on top of the m/49/0/1, e.g. m/49/0/1/0/5. That's why I don't understand why wouldn't they ask for hardened m/49'/0'/1' instead when you add the key.  
> **username_1**: Ah good question. I'll have to think about it.  

---

