salvatoshi on Nostr: At TABConf 6, I gave a talk on the UX challenges of hardware signing devices. Video: ...
At TABConf 6, I gave a talk on the UX challenges of hardware signing devices.
Video: https://youtu.be/IYOswKz5QAo
Slides: https://docs.google.com/presentation/d/17Tmwmi93ICXnFb_MTEspoE4TfiLFx6NUKARW5MJsp_M/edit?usp=sharing
I talk about why it's hard (but not unsolvable!) to provide a good and secure UX for complex spending policies.
Then, I discuss about the biggest offender: addresses.
TL;DR:
Today's UX of signing devices is centered around low-level objects of the bitcoin protocol: addresses, and transactions.
My claim is that a good UX can only be built by redesigning it around two much more familiar concepts:
accounts and identity
Working on secure support for descriptors & #miniscript, my initial focus has been to provide a secure flow with a good enough UX to be usable in practice.
And if you tried #Liana, you know it is!
But registration is certainly not yet optimal.
When you register a new miniscript policy, you teach your device to recognize all present and future addresses of the account described by that policy.
Once registration is finished, you have a UX that is not more complicated than your typical single-sig transaction.
Thanks to this registration of BIP-388 wallet policies (https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki), any additional complexity coming from the fancy scripts is limited to a one-time event.
While not ideal, that's acceptable; it takes just a few minutes to go through the entire registration flow.
But that's hardly the end of the story.
Our brain is just bad at processing addresses, and this makes people lose money.
https://x.com/mononautical/status/1796939795127500996
The key observation is that while accounts solve the UX problems for the internal UTXOs in a transaction (that is, the inputs you're spending, and also the change outputs), we're still offloading to the user the responsibility of checking the address of the external outputs.
But the user doesn't care about the address where the money is going.
The user only cares about who owns the address. If the signing device can guarantee that you
Send 0.1 ₿ to Bob
than that's all the the users really cares to check. Bob's address is Bob's business.
Therefore, what we want in payment instructions is not just addresses, but rather authenticated addresses: information that is given to wallets and signers must be enough to guarantee the provenance of the address.
So, how can we authenticate addresses?
That's the hard part. Not because it's difficult, but because there's no one-size-fits-all solution, and the best way depends on the specific situation.
But there are several promising approaches.
In same cases, we could use the account information! After all, if we're sending to another of your accounts, or your partner's account, or maybe the account of some other business unit of your company, then the receiver might be happy to share the BIP-388 wallet policy with you.
Today, we're only using the account info to authenticate the inputs and the change address.
If that info is added to the PSBT for external outputs, we could show:
Send 0.1 ₿ to your wife's account
which would surely be a better UX!
Something that clicked for me recently is the following:
Silent Payments (BIP-352) are just another type of account! They can fit perfectly well in this account-based UX flow.
They are inherently tied to an identity, and they allow you to generate authenticated addresses.
Finally, if knowledge of the receiving account isn't possible, there's still something that we can do: have the owner sign the address.
If we have a guarantee that the key signing the address belongs to the expected receiver, then we can spare the user from checking the address.
You could exchange keys in person if that's feasible; or approaches like BIP-353 (https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) using DNS might be practical in many situations - for example, for public entities like companies and exchanges.
Identity would also help in further improving the UX of account registration: the xpub of your cosigners could also be authenticated in the same way, simplifying the registration flow:
I hope to inspire more people to think about this problem.
There is still a lot to do, for example:
- What is the best way to present the spending policy of a complex miniscript-based account to the user?
- How to encode the 'account' information in the PSBT?
- What support should hardware signers provide to support identity and authentication of addresses/xpubs?
There is nothing inherently difficult in tackling this. No fancy cryptography or moon math is required.
Just good standards to properly define and implement across vendors and wallets.
Video: https://youtu.be/IYOswKz5QAo
Slides: https://docs.google.com/presentation/d/17Tmwmi93ICXnFb_MTEspoE4TfiLFx6NUKARW5MJsp_M/edit?usp=sharing
I talk about why it's hard (but not unsolvable!) to provide a good and secure UX for complex spending policies.
Then, I discuss about the biggest offender: addresses.
TL;DR:
Today's UX of signing devices is centered around low-level objects of the bitcoin protocol: addresses, and transactions.
My claim is that a good UX can only be built by redesigning it around two much more familiar concepts:
accounts and identity
Working on secure support for descriptors & #miniscript, my initial focus has been to provide a secure flow with a good enough UX to be usable in practice.
And if you tried #Liana, you know it is!
But registration is certainly not yet optimal.
When you register a new miniscript policy, you teach your device to recognize all present and future addresses of the account described by that policy.
Once registration is finished, you have a UX that is not more complicated than your typical single-sig transaction.
Thanks to this registration of BIP-388 wallet policies (https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki), any additional complexity coming from the fancy scripts is limited to a one-time event.
While not ideal, that's acceptable; it takes just a few minutes to go through the entire registration flow.
But that's hardly the end of the story.
Our brain is just bad at processing addresses, and this makes people lose money.
https://x.com/mononautical/status/1796939795127500996
The key observation is that while accounts solve the UX problems for the internal UTXOs in a transaction (that is, the inputs you're spending, and also the change outputs), we're still offloading to the user the responsibility of checking the address of the external outputs.
But the user doesn't care about the address where the money is going.
The user only cares about who owns the address. If the signing device can guarantee that you
Send 0.1 ₿ to Bob
than that's all the the users really cares to check. Bob's address is Bob's business.
Therefore, what we want in payment instructions is not just addresses, but rather authenticated addresses: information that is given to wallets and signers must be enough to guarantee the provenance of the address.
So, how can we authenticate addresses?
That's the hard part. Not because it's difficult, but because there's no one-size-fits-all solution, and the best way depends on the specific situation.
But there are several promising approaches.
In same cases, we could use the account information! After all, if we're sending to another of your accounts, or your partner's account, or maybe the account of some other business unit of your company, then the receiver might be happy to share the BIP-388 wallet policy with you.
Today, we're only using the account info to authenticate the inputs and the change address.
If that info is added to the PSBT for external outputs, we could show:
Send 0.1 ₿ to your wife's account
which would surely be a better UX!
Something that clicked for me recently is the following:
Silent Payments (BIP-352) are just another type of account! They can fit perfectly well in this account-based UX flow.
They are inherently tied to an identity, and they allow you to generate authenticated addresses.
Finally, if knowledge of the receiving account isn't possible, there's still something that we can do: have the owner sign the address.
If we have a guarantee that the key signing the address belongs to the expected receiver, then we can spare the user from checking the address.
You could exchange keys in person if that's feasible; or approaches like BIP-353 (https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) using DNS might be practical in many situations - for example, for public entities like companies and exchanges.
Identity would also help in further improving the UX of account registration: the xpub of your cosigners could also be authenticated in the same way, simplifying the registration flow:
I hope to inspire more people to think about this problem.
There is still a lot to do, for example:
- What is the best way to present the spending policy of a complex miniscript-based account to the user?
- How to encode the 'account' information in the PSBT?
- What support should hardware signers provide to support identity and authentication of addresses/xpubs?
There is nothing inherently difficult in tackling this. No fancy cryptography or moon math is required.
Just good standards to properly define and implement across vendors and wallets.