pull down to refresh
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.
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.