pull down to refresh
I think I will probably need to spend a couple solid days working through this comment. I have a rough idea of what you are saying, but I definitely couldn't implement a scheme like this with confidence right now.
Nevertheless, in the above scheme, I wasn't thinking of basing everything off a single root key.
In the case of a multisig, wouldn't using child keys to make the multisig add complexity to the whole setup?
If I have 5 root keys (not sure if that's what they should be called, but let's say they are all of equal privilege in the setup, and signatures from any 3 can spend, it is a pretty simple setup to treat each of them like a physical key.
Keep them in separate places. Import them to separate signing devices. The only thing that gets carried around is a psbt. I may be misunderstanding what you are describing though.
I definitely couldn't implement a scheme like this with confidence right now.
If you have a 3/5 descriptor where you specify 1 xprv and 4 xpubs (i.e. a core descriptor like sh(multi(3,xprv.../84'/0'/0'/*,xpub1,xpub2,xpub3,xpub4)), then you don't need the seed to withdraw. you only need the derived xprv.../84'/0'/0', and with that key you can sign subkeys 0/0, 0/1, 1/0, 1/1 as you go through your multisig addresses each time you make a withdrawal, exactly like you do with the xpubs to generate that address to deposit into.
You can then later derive (from seeds) a target for xprv.../84'/0'/1'/* for another segregated multisig.
What I really don't understand is that you're juggling 5 root keys. It's almost like BIP-32 becomes an afterthought, the hardened derivation becomes a nice-to-have and every time you interact with any signer, you expose everything (but segregated into 5 devices.) Sounds like a nightmare.
Do you have a video explaining this? I'm a bit lost here, haha.
Derive a hardenedxprv1'. Encrypt it with a good passphrase. Now you never expose your seed, only a password that, if you fuck up, can be reset through a restore from seed and sweep intoxprv2'. Minimum touching seed phrase. All this BIP-39 hacking is cringe af because you're literally interacting with a root key. BIP-32 (that you're using to derive the keys and addresses with) was made so that you don't need the root key all the time. So that you can have funds in account (a) and (b) and if (b) gets compromised you still have everything (a). Walking around with your root key is completely negating that.
Possibly something else is being discussed here but just to be clear, I'm referring to three independently generated seeds, not multiple accounts generated from one seed. And the seed plate backups themselves would live elsewhere as a cold "emergency" backup, while remaining imported into the two hardware wallets' secure enclaves and the Tails Electrum's persistent LUKs storage. As I say though, this may be a separate discussion – if so, pardon the intrusion!
I didn't quote what you wrote, so I wasn't referring to what you wrote, sorry if I made that impression.
What I was calling out was a growing narrative that continuously using the seed (i.e. it not being a cold emergency backup like you describe) to re-derive something that could have been encrypted with a password, is good, while in fact it is exposing something that should only be exposed in emergencies (like you say too.)
I have seen this whole "stateless device, just insert seed" narrative for years now, and we also see a lot of "directly roll seed". With that, more and more safety measures get pushed aside without speaking to what those are, which bothers me. Not criticism of people, but more of a trend that calls for simplicity without understanding what is lost by ignoring guardrails.
I didn't quote what you wrote, so I wasn't referring to what you wrote, sorry if I made that impression.
What I was calling out was a growing narrative that continuously using the seed (i.e. it not being a cold emergency backup like you describe) to re-derive something that could have been encrypted with a password, is good, while in fact it is exposing something that should only be exposed in emergencies (like you say too.)
I have seen this whole "stateless device, just insert seed" narrative for years now, and we also see a lot of "directly roll seed". With that, more and more safety measures get pushed aside without speaking to what those are, which bothers me. Not criticism of people, but more of a trend that calls for simplicity without understanding what is lost by ignoring guardrails.
Perfect, that makes sense! And no worries at all – I'm brand new to Stacker News today so some conventions may be sailing past me; apologies for that. I completely agree, and it's also why I haven't jumped aboard the Seed Signer train thus far. Good to call these things out! For Tails, the persistent LUKS storage seems a very clever feature for this use case.
To just highlight something from earlier discussions: the idea that a seed is like a password or a physical key, especially if it is your raw entropy, is simply poor process.
Derive a hardened
xprv1'. Encrypt it with a good passphrase. Now you never expose your seed, only a password that, if you fuck up, can be reset through a restore from seed and sweep intoxprv2'. Minimum touching seed phrase. All this BIP-39 hacking is cringe af because you're literally interacting with a root key. BIP-32 (that you're using to derive the keys and addresses with) was made so that you don't need the root key all the time. So that you can have funds in account (a) and (b) and if (b) gets compromised you still have everything (a). Walking around with your root key is completely negating that.