Multi-device multi-sig is definitely the direction we should head as it helps a lot. You turn the risk into where their supply chains overlap. It's important to keep a few things in mind:

* All devices must be from different manufacturers. If you do 2 of 3 where two are form the same manufacturer you've lost the supply chain resistance entirely
* If two of the manufacturers use a component in common your supply chain resistance is decreased
* If two of the manufacturers use a secure element in common your supply resistance is gone entirely
* The chances of a similar *wafer producer* being used between any of the components is quite high
* If the same wafer producer is used for the secure elements your supply resistance is gone entirely
* Even if the secure elements are printed using different wafer producers, they may use the same wafer machines. It is not simple but a wafer making machine itself could be updated to modify the secure elements it prints to inject malicious circuits.
* Most importantly, you can never be certain these things aren't happening. On-chain 2FA however is easily verified by looking at the blockchain.

By using on-chain 2FA you're able to "stake" on unrelated supply chains in a way that can only increases security. Throw a key on the iPhone supply chain for instance, or Android. You could even do both, adding as many as you like. Each that you add increases your security. The attacker must infiltrate all of these supply chains to succeed and using existing large supply chains makes the attacker's task much more difficult.

So really these approaches should be combined. On-chain 2FA plus multi-device multi-sig is an awesome combination of security factors.

Multi-device multi-sig protects you against malicious hardware wallet software while on-chain 2FA protects you against malicious hardware wallet hardware.

Creating your own seed phrases and importing them into your hardware wallets is much more secure than letting the devices generate them.

This assurance only works however if you never use the wallet to sign anything and only sign one transaction that withdrawl all the funds. After that the key you created should be considered tainted and never used again.

This is because of the chosen nonce attack.

On-chain 2FA does help mitigate some of the concerns of a chosen nonce attack.

Ah! An excellent idea. Thanks for reading it man!

Thanks for the feedback. It would need to be stored off the hardware device completely and never be allowed to touch the hardware device at any point*. Perhaps that could have been made clearer.

This solution is just targeting at solving the supply chain attack problem. It doesn't address other issues. Mitigating other attack vectors is very interesting! It just wasn't part of the scope of this paper.

[edit, added this note]
* It can actually go into the device as long as the device is never used and then only used once withdrawing all funds. This is because of the "chosen nonce" attack, which allows a malicious wallet to hide data (ie an obscured private key) inside a signature nonce. I haven't vetted this article but I've skimmed it and it looks like a good intro into the subject: https://medium.com/cryptoadvance/hardware-wallets-can-be-hacked-but-this-is-fine-a6156bbd199
The simple solution is just to never send the key to the device at all which just solves the problem.

I put together a paper explaining my thoughts on solving the supply chain attack problem.

Would appreciate any thoughts or feedback people have.

http://www.koinkeep.com/articles/whitepaper

Thanks!

The SPV wallet thinks of all the possible receiving addresses it can think of (up to some arbitrary limit, usually all used plus 100) and puts them into what's called a "bloom filter", which coarsely represents the addresses (plus potentially some others).

It then sends this "bloom filter" to a 'random full node' (as you say) and starts requesting trimmed "merkle trees" from the full node.

The node sends these trimmed "merkle trees" (which represent the parts of the block that match the "bloom filter") along with the corresponding transactions for whichever blocks the SPV requests. Typically the SPV will repeat this request for every block since the wallet was created (because it's essentially impossible to have transactions before the wallet's private key was created).

The SPV wallet then can use the "merkle tree" to prove that all the transactions sent along with it were definitely included in the block.

Importantly, it does *not* prove a transaction was *not* included in the block.

This is why it wouldn't work for the lightning network. The lightning network needs to test the inverse -- was a transaction *not* included in a block.

Compact block filters allows you to test both if a transaction *was* included in a block and confirm if it *was not* included in a block. CBF also puts less burden on full nodes as well making great strides in privacy.

But compact block filters require significantly more bandwidth than bloom filters. It's a trade off. It's not nearly as much bandwidth as running a full node but it is still significantly more bandwidth than bloom filters.

While never matching CBF's privacy, it's possible make bloom filters very private. But it requires wallet developers to use them very carefully and do a lot of node disconnects and reconnects (which is vulnerable to sybil attacks). Time has shown wallet developers have done little to none of that work and tend to use bloom filters with the default settings. Which translates to basically no privacy. Some (very few) wallets do do it correctly however. So there's this question of if turning off bloom filters to prevent the bulk of insecure wallets from operating is worth hurting the minority of wallets that use them correctly.

</wall of text> Clearly I have a lot on my mind on this subject.