Tell me more
Discussion
One that has been on my mind lately is verifying addresses on a hardware wallet when receiving funds.
It's rather ugly (big string of characters), so we chunk the address up and highlight some chunks at random.
It's also unintuitive, best practice is not to simply check that the address you're giving out from your software wallet matches the address derived on your hardware wallet. Since it could be intercepted and replaced during transmission (this is where most attacks are, clipboard malware).
Rather, you want to check that the **sender** sees the same address as displayed on your hardware wallet. Making the workflow and describing this is rather tricky, it all depends on who you're receiving from - is it an in-person transaction (compare visually)? is it over DMs (ask can you see the address chunks)? Is it a withdrawal from an exchange (compare against confirmation email, if provided)?
Nunchuk has address Verification, as well as certain HWWs like Coldcard Q and Keystone Pro 3.
Anything special about them? Most workflows don't guide the user with respect to the what and why afaik
It's just an address check against a given Xpub. The signer and the wallet app are just cross referencing the same address list. Basically ensuring the keys on the signer are connected to the produced address.
COLDCARD Q
-Txn comes in, Copy it as QR
-Scan the QR code with your COLDCARD Q. The device will show you the address and ask you to press 1 to verify ownership.
-If the address is verified successfully, the COLDCARD will show "Verified Address" with details about the address. If the address cannot be found, the Q will show "Unknown Address".
Very similar workflow for keystone as well.
Software wallets are typically not the attack vector! See what i said above re verifying address against sender's view and clipboard malware
I guess I don't understand what scenario we are talking about. In most cases of payment, you either own the domain that is displaying the address QR for your counterparty or you are in person to display the QR. In your proposed scenario you are sending a payment invoice over an unencrypted messenger? That on its face is an attack vector so, maybe I am misinterpreting what you mean.
Yeah! Anywhere along the transmission from wallet to sender, can be clipboard malware (most common) where you copy an address and the malware pastes in a similar but different address, or browser malware which substitutes addresses within web requests (after you hit withdraw on an exchange), or malicious QR code scanner, or intercepted during unencrypted message transmission like you say.
Software wallet is indeed a domain you control, can verify signatures etc. The other stages are less in your control.
How many user testing iterations have y’all done?
Not so much, though we've received a lot of feedback during our demos. It's easy to notice when someone is confused, often means we need to redesign something!
We've had so much to work with based on our own experiences as bitcoin users, but we're almost getting to the point where we have exhausted+resolved our personal painpoints. Much more user testing coming soon!
Another tricky one is is geographic distribution of multisignature keys, there's little personal security gained if you keep a quorum of keys in one location!
I've designed a workflow to encourage geographic separation of each device alongside their respective backup, but it's still rough around the edges.. Some users may want to sit down and create all their backups at once, but then there's risk that they mix them up or get lazy and never distribute them into separate locations.
nostr:npub1q6mcr8tlr3l4gus3sfnw6772s7zae6hqncmw5wj27ejud5wcxf7q0nx7d5 have you thought about this particular challenge?
I’ve compartmentalized the problem for now until I get further along.
The basic idea I am working with is that the wallet component has its own key managed by the client user application. It never sees the owner’s key and vice-versa, the user never needs to see the wallet key. If there is a problem, the wallet can be replicated to a new instance and the old one burnt.