Search content
Sort by
Showing 20 of 61 results by aesthete2022
Quote
I was thinking less about forgetting your derivation path and more about if you ever needed to use some different piece of software.
As I said above, you can easily back up your derivation path alongside your seed phrase, and therefore have no additional risk of losing your coins. The issue would come if you want to import your multi-sig in to a different piece of software for whatever reason that does not let you specify arbitrary derivation paths.
If you back up your full descriptors and always use the same version of Sparrow then of course there will be no problems. But it is fairly easy to imagine a scenario where you need emergency access to your funds and you are forced to recover the seed phrases using different software, perhaps on a different OS, perhaps on mobile instead of a computer, and so on. In such a case it is always going to be an easier process if you have used the widely accepted standards rather than done something unique.
It is of course up to you - just explaining my rationale behind preferring to stick to standard practices.
As I said above, you can easily back up your derivation path alongside your seed phrase, and therefore have no additional risk of losing your coins. The issue would come if you want to import your multi-sig in to a different piece of software for whatever reason that does not let you specify arbitrary derivation paths.
If you back up your full descriptors and always use the same version of Sparrow then of course there will be no problems. But it is fairly easy to imagine a scenario where you need emergency access to your funds and you are forced to recover the seed phrases using different software, perhaps on a different OS, perhaps on mobile instead of a computer, and so on. In such a case it is always going to be an easier process if you have used the widely accepted standards rather than done something unique.
It is of course up to you - just explaining my rationale behind preferring to stick to standard practices.
I appreciate that. I have Electrum back ups too, but I know what you're saying.
Quote
Simply because it is the standard. I am not aware of a single wallet which derives P2SH address at m/49/0/x by default, while there are hundreds which follow the BIP39 standard of m/49'/0'/x'.
Just like there is nothing stopping me deriving a single sig wallet at m/3894329'/284760'/1609266' and backing up my derivation path, it is much safer to just stick to the standard m/84'/0'/0'.
Just like there is nothing stopping me deriving a single sig wallet at m/3894329'/284760'/1609266' and backing up my derivation path, it is much safer to just stick to the standard m/84'/0'/0'.
Ah ok, yes that is a fair point. However, I think so long as I backup the derivation path I should be ok. This thread will serve as an extra back up
Quote
However, I would highly recommend sticking to the standard of using hardened paths for the first three levels if you are using 49 at the purpose level, not least of all to make your life easier when recovering your wallet in the future.
Forgive my ignorance, but how does a hardened path help wallet recovery? I have the output descriptors and Sparrow and Electrum wallet files backed up on multiple media.
Quote
Of course in MultiSig, it needs the "N" number of cosigners, not just one.
And the other cosigner's xpub and private keys are unrelated to each other, that unhardened derivation vulnerability isn't applicable to each cosigner's keys.
And the other cosigner's xpub and private keys are unrelated to each other, that unhardened derivation vulnerability isn't applicable to each cosigner's keys.
Thanks for the above. So, ultimately unhardened vs hardened doesn't matter a great deal in multisig?
Quote
The relevance is that unhardened levels can be derived only using public keys, while hardened levels require the private keys. In short, they are entirely different numbers and will derive entirely different addresses.
I see. So the main tradeoff is privacy? Is that correct?
Quote
If your output descriptors either include your derivation path, or are using the xpubs already derived from the relevant derivation paths, then yes.
Just be careful with hardened paths. You've said m/49/0/4, but I suspect you mean m/49'/0'/4'.
Just be careful with hardened paths. You've said m/49/0/4, but I suspect you mean m/49'/0'/4'.
Thanks. So, the xpubs will point to the right addresses with or without the derivation paths?
What is the difference between m/49' and m/49? So far as I can see, the derivation paths for all my multisig wallets are hardened (i.e., m/49).
Just revisiting this topic for verification/reassurance.
As my (thoroughly backed up and tested) keys are geographically distributed, I have used the derivation path (m/49/0/4) and xpubs derived by my collaborative custodian to create a 2 of 3 fully self-sovereign multisig. It signs fine. My one concern is that I'm using a non-standard derivation path (I would have preferred to have used m/84/0/0). However, so long as I have the output descriptors fully backed up, I should always be able to sign from this wallet, correct?
As my (thoroughly backed up and tested) keys are geographically distributed, I have used the derivation path (m/49/0/4) and xpubs derived by my collaborative custodian to create a 2 of 3 fully self-sovereign multisig. It signs fine. My one concern is that I'm using a non-standard derivation path (I would have preferred to have used m/84/0/0). However, so long as I have the output descriptors fully backed up, I should always be able to sign from this wallet, correct?
⭐ Merited by ETFbitcoin (1)
I am wondering what the best practice is for storing output descriptors. Currently I have them offline on USB drives. However, there is an obvious risk of physical/environmental degradation over time. My instinct is that it would be foolish to save them on a cloud. I guess the tradeoff is physical degradation vs. being hacked. I'm guessing the latter is probably more likely.
Quote
Maybe you have the safety setting "Validate Derivations" disabled that enabled you to use the single-sig derivation paths to MultiSig.
No, it is on. BIP 49 is a multisig derivation path though.
Quote
I have no means to test this but you may be able to sign by creating a new MultiSig wallet with the correct derivation paths to the provided extended public keys.
I think you're right. The $30 locked in that wallet is the cost of tuition.
Quote
Perhaps.
If those Nested SegWit extended public keys are derived from your master private key with m/49'/0'/0' path,
But used it in a MultiSig setup and provided the standard path of m/48'/0'/0'/1' (BIP48 - Nested SegWit), then your hardware wallet will derive a different xpub key than what you've provided.
What does the descriptor looks like? You can edit the extended public keys for privacy reasons.
BTW, in Sparrow, you can't use the standard derivation path of BIP49 in a MultiSig setup by design.
If those Nested SegWit extended public keys are derived from your master private key with m/49'/0'/0' path,
But used it in a MultiSig setup and provided the standard path of m/48'/0'/0'/1' (BIP48 - Nested SegWit), then your hardware wallet will derive a different xpub key than what you've provided.
What does the descriptor looks like? You can edit the extended public keys for privacy reasons.
BTW, in Sparrow, you can't use the standard derivation path of BIP49 in a MultiSig setup by design.
I think the fatal flaw in my understanding was that I thought the xpubs were generated solely by the hardware devices and were independent of the derivation path, and that the derivation path specified the receive and change keys from the child xpubs of the devices. That's strange, I currently use BIP 49 in a collaborative multisig 3 of 5 setup, and imported it into Sparrow with no issue. I was also able to form a 2 of 3 setup using the same xpubs and derivation path in Sparrow.
So, given I imported two xpubs from a BIP 49 setup and one from a BIP 84 wallet, then used the derivation path BIP 48 to derive all the receive and change keys, have I just made a huge spaghetti soup that I won't be able to sign?
Ok, so I'm learning through doing here. I took what I know to be valid xpubs from my three keys and used the derivation path for nested segwit. However, I can't sign from that quorum. I'm thinking this is probably because the xpubs I am using were not generated by the derivation path I specified?
Quote
Absolutely.
The derivation path tells your software how to turn a seed phrase in to an extended private key and extended public key. So if you use m/49/0/3, this tells the wallet to derive the extended key at the 50th index, then use that to derive the extended key at the 1st index, then use that to derive the extended key at the 4th index. This final extended key is the xprv/xpub used in your multi-sig wallet.
It doesn't matter if every seed phrase in your multi-sig uses a different derivation path - each one will end up with an xprv/xpub which are combined to create your multi-sig. In fact, the wallet does not even need to know the derivation paths at all. Indeed, there doesn't even need to be a seed phrase in the first place. You could just generate an xprv directly from some entropy source.
As long as you feed it it the same xprvs/xpubs, it will always generate the same addresses, regardless of where these xprvs/xpubs came from.
The derivation path tells your software how to turn a seed phrase in to an extended private key and extended public key. So if you use m/49/0/3, this tells the wallet to derive the extended key at the 50th index, then use that to derive the extended key at the 1st index, then use that to derive the extended key at the 4th index. This final extended key is the xprv/xpub used in your multi-sig wallet.
It doesn't matter if every seed phrase in your multi-sig uses a different derivation path - each one will end up with an xprv/xpub which are combined to create your multi-sig. In fact, the wallet does not even need to know the derivation paths at all. Indeed, there doesn't even need to be a seed phrase in the first place. You could just generate an xprv directly from some entropy source.
As long as you feed it it the same xprvs/xpubs, it will always generate the same addresses, regardless of where these xprvs/xpubs came from.
That’s super interesting, thank you.
I am having trouble wrapping my head around derivation paths in multisig setups. I had a multisig quorum with the derivation path m/49/0/3. I wanted to swap a key to set up a new wallet. I used Sparrow and, even though the new device used the derivation path m/48/0/0/2 and the other two had m/49/0/3, it still generated the multisig wallet (i.e., Sparrow detected no error).
My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.
My question is, can each device in a multisig setup have a different derivation path? I always thought every device had to refer to the same one.
I use my wallets on a Linux system with full disk encryption. Stealing the device should prevent an attacker to gain access to the filesystem. I do wallet password protection even for watch wallets, just a habit I don't want to break with. I only make an exception if I do something with a test wallet which doesn't control any worth.
Even my Testnet Bitcoin wallets are password protected, but not with my stronger passwords. For convenience I relax passwords strength where appropriate.
Even my Testnet Bitcoin wallets are password protected, but not with my stronger passwords. For convenience I relax passwords strength where appropriate.
Do you keep your private keys on hardware wallets, or are they stored on your hard drive? My wallet files are watch only, but with the master fingerprints so that I can use them to sign from an air gapped device.