Hm, so what vectors is this supposed to mitigate? Leaking through the
generated public keys? Anything else?
The main thing it’s protecting against is the stealing of your funds by malicious hardware & software. There are some side benefits as well though.
- What are you trying to achieve? You seem to describe how you get
from the setup to the goal in four steps but I don't understand what
the setup is or what the goal is. (What's a storage solution?)
“Storage solution” is however you’re storing bitcoins today. Could be 12 words on some paper plus a computer running electrum. Could be a Ledger + computer. Point is this technique works regardless of how you’re storing your bitcoin.
- "all SW being compromised" do you mean "SW and HW compromised"? Note
that SW and HW are parties in Pieter's writeup, not just abbreviations
for software and hardware.
Yeah — if you split the SW party into two, “generator” and “validator” some interesting and useful security properties emerge.
- Where are the two stages? You mention four steps.
“Generator” and “validator”. The generator creates and passes on receiving addresses and withdrawal transactions (while remaining offline). The validator double checks everything the generator did..
It works best if the validator is written entirely independently of the generator.
- Where do you run the external software? On a second SW? Is this the
second stage?
Yes
- Do you use unhardened derivation?
It’s an open ended solution — it would work with a (presumably non-trivial/random) unhardened derivation just fine.
- What's a k commitment?
It is one of the proposed solutions presented (collected?) by Peter in this thread. As I understand it k is used to generate R in the signature. By committing to some k value the hardware wallet can’t “sneak out” your private key(s) in the R value.
Best,
Dustin