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.
> 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.
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.
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.
