Hello Kevin,
Thanks for starting this thread, that's a really relevant discussion ecosystem-wise !
> * Proposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).
What level of script literacy are you assuming on your users ? I can see enterprise/hobbyist folks to know enough of Script to understand the intended behavior but I don't think that's a reasonable assumption for your average user. Of course, Miniscript Policy makes things easier, but IMHO, I still hope to see some mature, higher-level language (e.g Ivy) to ease script semantic understanding and thus widen the crowd of users.
Further, I would do a bit on UX research on the correctness model expected by your users. I.e if they fail to verify accordingly, are they losing funds, transaction doesn't confirm, transaction doesn't even propagate, etc. You should also make assumptions on the mental resources you're required from them. Time-sensitive L2 protocols have a wide scope to check, e.g not verifying the nSequence/nLocktime fields can provoke funds failures.
> This applies to pre-signed transaction protocols especially well as the template of these transactions could be known
and recognized by the HW. Typically for Revault, the HW could display: "Unvault Transaction, all expected pubkeys
present in the script".
In the future, I would expect templates of high-security protocols like vaults to be part of the trusted computing base of any decent HW. I think good standards there would avoid HW vendors to come with some kind of certified-templates scheme and thus having to bless custom scripts of every vaults implementations.
> Proposed improvement: The HW could know pubkeys or xpubs it does not hold the private keys
for, and display a label (or
understand it for logic reasons, such as "expected pubkeys" as the previous example).
I don't think you even need user input on this, the absence of pubkeys knowledge itself is a trigger to display a label or ask for further information. Where absence of pubkeys knowledge can be interpreted as devoid from key whitelisting or privkey ownership.
> Going further, the xpubs could be
aliased the first time they are entered/verified (as part of, say, an initial setup ceremony) for instance with the
previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42))).
I would be careful about accidental or malicious alias collisions. But yes that can be something, you can even conserve a merkle tree root in the Secure Element where the hashed element are
previously authenticated alias/pubkeys. And require from the non-trusted challenger to come with a merkle branch to validate address inclusion.
> Then there is PSBT support and the maximum transaction size limit for
these: we need more transparency from HW manufacturers on their li
mitations.
I understand them, Script is full of subtleties, taproot is likely to have more of them and if you take sighash malleability that's not something you want your average user to play with. Maybe it
would be better to come up with a first wave of script features on which you expect transparency ? For sure, OP_CSV is a good candidate.
> Once any input of a (pre-signed)transaction is
spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense
mechanism, spending any input would mean incapacitating the entire defense mechanism.
I don't see the exact issue here. E.g in Lightning, even if you pre-sign a justice transaction punishing every revokeable outputs on counterparty transaction, and one input is spent, will current HWs prevent you to-resign an updated justice transaction ?
> I understand some of these changes may be very difficult, especially given the low memory and computational power of
secure elements.
Instead of relying on hand-sized devices, what about relying on HSMs for a first-wave of adoptions, those ones have far enough resources to run a reasonable L2 stack on the trusted-side ?
But overall agree, on the requirement to level-up HWs for L2. IMO, a first step could be to list a common set of features beyond deployed/soon-to-be-deployed L2s, that would make things easier for HW vendors to have a unique list of grievances. Before they engage in further, dedicated tweaks to adapt for each protocol security model. OP_CSV/OP_CTLV decoding/"burned" standard scripts support would be a good starter.
> Feel free to reply with your comments or adding suggestions, I am not a hardware wallet expert and would take criticism
wit
hout being offended.
I don't know yet any *L2* hardware wallet expert :)
Cheers,
Antoine