Replying to 6e70253f...

Ultimately you can't eliminate trust, so at some point you do need to draw a line. For example, after you have generated your own seed words you trust the firmware to generate your xpub, which could just be someone's else's xpub.

So now we're talking multi-vendor hardware devices, using two different computers to manage the firmware updates and watch only wallets. Some people draw the line around here, others go further.
Avatar
jimbocoin 🃏 2y ago

> For example, after you have generated your own seed words you trust the firmware to generate your xpub, which could just be someone's else's xpub.

Good point! As you say, multi-vendor solves this. It’s unlikely that multiple independent vendors will be vulnerable at the same time by the same attacker. If multiple independent vendors give you the same XPUB, you’re probably good.

I would argue that rolling your own seeds on a single device is still better than trusting the device to generate the seed because the device may have latent bad randomness. But entering the same seed into multiple devices from different vendors is better still.

In a nutshell, we’re trying to guard against:

1. Bad randomness

2. Known seeds

3. Lying devices

4. Leaked seeds

Rolling your own seeds guards against 1 & 2, but to guard against 3 you need multivendor. To mitigate 4 you need multivendor multisig.

Reply to this note

Please Login to reply.

Discussion

6e
6e70253f... 2y ago

Another intermediate option is to do a test "roll your own seed" and verify its xpub using an online tool, then do your real one. This is not fool proof thou, as the attacker could have a random variable that selects on average, say, every fifth xpub as the dummy output.

Avatar
jimbocoin 🃏 2y ago

That would help, yes.

The next Trust problem is XPUB -> addresses. Fortunately this is less difficult to safely check as you can plug the same XPUB into multiple software wallets to confirm they produce the same address sequence.