From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B641BC013A for ; Sun, 17 Jan 2021 01:31:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 99FB985EBE for ; Sun, 17 Jan 2021 01:31:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rni8gbRuV9NM for ; Sun, 17 Jan 2021 01:31:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 2D15D85EB8 for ; Sun, 17 Jan 2021 01:31:20 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id a12so13037888wrv.8 for ; Sat, 16 Jan 2021 17:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NtpHPPKp83N6vhMrtaJ2ck3PpHs0E7GR1La9gtBd3GE=; b=CshtYOll+1BLV62AZE74DV9G7Z+jT6NCN8v4rHd+NhHnGMXCh32RcZLsKeJWfjQqdt yoo2Mjkxy21vvwO/YIFVXdN8jZ/HJMnP4Te4bfQiUjg1E8H3wR8ONlXBH6HVWc/R0B9U udJoz7ZeRdWWLWWk6r1W9tl8V1muOJ4lV+tr+IvQ64XOy3yVhoX9KTFwQQ+8ZnyKCi/m hDY5w7CilbBG0HKESyVzaitptwm73WYTsRXk2iQoEvbkAHtm+Bbbxcu9qzAaArp7CMV6 9zXroTkDlPksvkGJSMY8oJ6qEe8l5AtCIAUJjL4NR58iBZh9E+3MafryM/NsWEM/m9jk srhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NtpHPPKp83N6vhMrtaJ2ck3PpHs0E7GR1La9gtBd3GE=; b=UD4hAeztuaqZEy84Esghtx6RjSKcyCIkXRO3/BFos2urtIQ2TdFc0SMdeisDpDssN8 FoNrc3Z4eNg9juUK+CDUbrmot35UtiZ7P0EIxISmyCbmwEB20l60fNjukj6MkkdeHleu AdaunyAJQHCWcQ08CG3Zv+k3+afNq+qserKqWaRPgohOz1wj9uHn4KNQYFkCUKV6CAoH wEsoa6L9wXBfaOeOgpWV98EoncexHFNTwsXmDCWcXBNBBwWh7NQkvI0FWRSE+I1dZDB3 GuoVF+rvvT4JXqi4NW6eCm/a1r40US52TVewrIN8zXuQKSN81cCEG8rktycaCaJKcbHR D3VQ== X-Gm-Message-State: AOAM533teoyij2XcchV13Js4q/lLuAQhl+ksVF/gy6CWT1R/JY+ITlZN 65kpcCEuEa1zKWZuDegXaReBWZ+FiclkwlUOym18Lz+F4Xc= X-Google-Smtp-Source: ABdhPJzjLx0wlviadQwuHZLgyf1gMyoSiPGm8p/6fA1Y0Hkc5fdsp/zGhj5oqvQWQ2HbY0gKOjFuwsjYjijNVjrfTrM= X-Received: by 2002:a5d:4d8d:: with SMTP id b13mr19112772wru.415.1610847078792; Sat, 16 Jan 2021 17:31:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sat, 16 Jan 2021 20:31:07 -0500 Message-ID: To: Kevin Loaec , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000eb3fbe05b90e8fe0" X-Mailman-Approved-At: Sun, 17 Jan 2021 02:11:40 +0000 Subject: Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 01:31:26 -0000 --000000000000eb3fbe05b90e8fe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Le jeu. 14 janv. 2021 =C3=A0 13:46, Kevin Loaec via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hello everyone, > > I would like to start a discussion on improving Hardware Wallets. > > My approach to this right now is from a vault protocol we are developing > (Revault, [1]), and its Hardware Wallet > requirements. I started working on a Github Issue in our repo [2], other > people recommended us to do a more general > discussion on the mailing list instead as it could benefit many other > protocols and users. > This email discusses improvements that would benefit everyone, and some > that are more suitable for "layer 2" or pre- > signed transactions protocols. > The goal is to spark discussions and hopefully iterate to a more secure > and more usable hardware ecosystem for all > bitcoiners. > While I mainly foresee issues/improvements that may affect Revault, I > would be really happy to see people joining this > thread with any other ideas and remarks that would benefit some parts of > Bitcoin that I overlooked. > > > > Prior work on similar problematics: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - ZmnSCPx > j: [Lightning-dev] Speculations on hardware wallet support for Lightning > [3] > - mflaxman: Known Issues: Verifying a Receive Address [4] > - ksedgwic and devrandom01: Lightning-signer [5] > - benma: How nearly all personal hardware wallet multisig setups are > insecure [6] > > > The postulate we start from is that Hardware Wallets (HW) are useful to > mitigate the compromission of the day-to-day > device of a user. They mainly prevent private-key extraction today, and > aren't very suitable against an attack on the > transaction being signed, as explained further. > To make this discussion security-focused, let's assume the general purpos= e > device (laptop, for example) is compromised > with a malware implanted by an attacker, capable of modifying PSBTs, > displayed addresses, etc. > > Our study so far: > > > Output Script Parsing: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Problem: A typical HW today would display the "destination" of a > transaction in the form of a bitcoin address. A user > would generally compare this wit > h the address displayed on his laptop screen... which might have been > compromised > already. The correct usage would be for a user to verify this address on = a > third device (mobile phone, for example). > This is weak security and bad user experience. > Proposed improvement: The HW should display the Bitcoin Script itself whe= n > possible (including the unlock conditions). > The best way to do so would be to lift this Script to a more user-friendl= y > format such as a MiniScript Policy display, > but anything would be better than an "address". > 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". > > > Pubkey Interpretation: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Problem: currently HW cannot "identify" addresses or keys. > 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). 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))). > This should be done in the Secure Element if possible to avoid physical > compromission, but would be a strong improvement > versus a day-to-day laptop in any case. > > > Better Bitcoin Compatibility: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any > conditional outputs. This is a major issue for > anyone using Bitcoin "advanced" features. Related to this are the Sighash > flags: most HW do not support most Sighash > flags. Kind of annoying for a signing device. Then there is PSBT support > and the maximum transaction size limit for > these: we need more transparency from HW manufacturers on their li > mitations. > Solution: Make Bitcoin HW actually compatible with Bitcoin :D > > > Inputs (mainly for pre-signed Tx): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Problem: Poisoned inputs are a major risk for HW as they don't know the > UTXO set. While this can be exploited for fee > attacks, it is a bigger threat to pre-signed transactions protocols. 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 defens= e > mechanism. > Proposed improvement: for protocols that requires it, keeping track of > inputs already signed once would be extremely > helpful. Going further, most of these protocols require to follow a > specific signing order (typically the "clawback" > first, then the regular spend path) so adding a way to check that a > "clawback" has been signed first, with the same > input, would be very helpful. All of this on the dev > ice itself. > > > > > I understand some of these changes may be very difficult, especially give= n > the low memory and computational power of > secure elements. However I truly believe most of these points are a MUST > have for any decent security. If you don't > assume the computer on which the transaction is crafted is compromised, > then you don't need a hardware wallet. If you > assume it may be compromised, then the HW needs to be able to defend > against those. > > Revault does not plan on building hardware wallets, we hope existing and > upcoming manufacturers will implement a strong > security that we could use for the Revault protocol users. Vault users > will likely hold very large sums and would be > happy to pay a high premium for more secure HW. This will hopefully > encourage existing players to keep on improving > their devices and that will ultimately benefit us all. > > 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. > > Kind Regards, > Kevin Loaec > > [1]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.h= tml > [2]: https://github.com/re-vault/practical-revault/issues/59 > [3]: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00= 2425.html > [4]: https://btcguide.github.io/known-issues/verify-receive-address > [5]: https://gitlab.com/lightning-signer/docs > [6]: > https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multi= sig-setups-are-insecure/ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000eb3fbe05b90e8fe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Kevin,

Thanks for starting t= his thread, that's a really relevant discussion ecosystem-wise !
> * Proposed improvement: The HW should display the Bitcoin Script itse= lf when possible (including the unlock conditions).

What level of sc= ript literacy are you assuming on your users ? I can see enterprise/hobbyis= t 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. O= f 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 un= derstanding 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&= #39;t confirm, transaction doesn't even propagate, etc. You should also= make assumptions on the mental resources you're required from them. Ti= me-sensitive L2 protocols have a wide scope to check, e.g not verifying the= nSequence/nLocktime fields can provoke funds failures.

> This ap= plies to pre-signed transaction protocols especially well as the template o= f 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 expec= t templates of high-security protocols like vaults to be part of the truste= d 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 h= aving to bless custom scripts of every vaults implementations.

> = Proposed improvement: The HW could know pubkeys or xpubs it does not hold t= he 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 pub= keys knowledge itself is a trigger to display a label or ask for further in= formation. 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 me= ntioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42))).

I= would be careful about accidental or malicious alias collisions. But yes t= hat can be something, you can even conserve a merkle tree root in the Secur= e Element where the hashed element are
previously authenticated alias/pu= bkeys. And require from the non-trusted challenger to come with a merkle br= anch to validate address inclusion.

> Then there is PSBT support = and the maximum transaction size limit for
these: we need more transpare= ncy from HW manufacturers on their li
mitations.

I understand the= m, 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 av= erage user to play with. Maybe it
would be better to come up with a firs= t wave of script features on which you expect transparency ? For sure, OP_C= SV is a good candidate.

> Once any input of a (pre-signed)transac= tion is
spent, this transaction isn't valid anymore. Most pre-signed= transactions protocols are used today as a form of defense
mechanism, s= pending any input would mean incapacitating the entire defense mechanism.
I don't see the exact issue here. E.g in Lightning, even if you p= re-sign a justice transaction punishing every revokeable outputs on counter= party transaction, and one input is spent, will current HWs prevent you to-= resign an updated justice transaction ?

> I understand some of th= ese changes may be very difficult, especially given the low memory and comp= utational power of
secure elements.

Instead of relying on hand-si= zed devices, what about relying on HSMs for a first-wave of adoptions, thos= e ones have far enough resources to run a reasonable L2 stack on the truste= d-side ?

But overall agree, on the requirement to level-up HWs for = L2. IMO, a first step could be to list a=C2=A0 common set of features beyon= d deployed/soon-to-be-deployed L2s, that would make things easier for HW ve= ndors to have a unique list of grievances. Before they engage in further, d= edicated tweaks to adapt for each protocol security model. OP_CSV/OP_CTLV d= ecoding/"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 b= eing offended.

I don't know yet any *L2* hardware wallet expert = :)

Cheers,
Antoine

=
Le=C2=A0jeu. 14 janv. 2021 =C3=A0=C2= =A013:46, Kevin Loaec via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3= =A9crit=C2=A0:
H= ello everyone,

I would like to start a discussion on improving Hardware Wallets.

My approach to this right now is from a vault protocol we are developing (R= evault, [1]), and its Hardware Wallet
requirements. I started working on a Github Issue in our repo [2], other pe= ople recommended us to do a more general
discussion on the mailing list instead as it could benefit many other proto= cols and users.
This email discusses improvements that would benefit everyone, and some tha= t are more suitable for "layer 2" or pre-
signed transactions protocols.
The goal is to spark discussions and hopefully iterate to a more secure and= more usable hardware ecosystem for all
bitcoiners.
While I mainly foresee issues/improvements that may affect Revault, I would= be really happy to see people joining this
thread with any other ideas and remarks that would benefit some parts of Bi= tcoin that I overlooked.



Prior work on similar problematics:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- ZmnSCPx
j: [Lightning-dev] Speculations on hardware wallet support for Lightning [3= ]
- mflaxman: Known Issues: Verifying a Receive Address [4]
- ksedgwic and devrandom01: Lightning-signer [5]
- benma: How nearly all personal hardware wallet multisig setups are insecu= re [6]


The postulate we start from is that Hardware Wallets (HW) are useful to mit= igate the compromission of the day-to-day
device of a user. They mainly prevent private-key extraction today, and are= n't very suitable against an attack on the
transaction being signed, as explained further.
To make this discussion security-focused, let's assume the general purp= ose device (laptop, for example) is compromised
with a malware implanted by an attacker, capable of modifying PSBTs, displa= yed addresses, etc.

Our study so far:


Output Script Parsing:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Problem: A typical HW today would display the "destination" of a = transaction in the form of a bitcoin address. A user
would generally compare this wit
h the address displayed on his laptop screen... which might have been compr= omised
already. The correct usage would be for a user to verify this address on a = third device (mobile phone, for example).
This is weak security and bad user experience.
Proposed improvement: The HW should display the Bitcoin Script itself when = possible (including the unlock conditions).
The best way to do so would be to lift this Script to a more user-friendly = format such as a MiniScript Policy display,
but anything would be better than an "address".
This applies to pre-signed transaction protocols especially well as the tem= plate of these transactions could be known
and recognized by the HW. Typically for Revault, the HW could display: &quo= t;Unvault Transaction, all expected pubkeys
present in the script".


Pubkey Interpretation:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Problem: currently HW cannot "identify" addresses or keys.
Proposed improvement: The HW could know pubkeys or xpubs it does not hold t= he private keys
for, and display a label (or
understand it for logic reasons, such as "expected pubkeys" as th= e previous example). Going further, the xpubs could be
aliased the first time they are entered/verified (as part of, say, an initi= al setup ceremony) for instance with the
previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42= ))).
This should be done in the Secure Element if possible to avoid physical com= promission, but would be a strong improvement
versus a day-to-day laptop in any case.


Better Bitcoin Compatibility:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any co= nditional outputs. This is a major issue for
anyone using Bitcoin "advanced" features. Related to this are the= Sighash flags: most HW do not support most Sighash
flags. Kind of annoying for a signing device. Then there is PSBT support an= d the maximum transaction size limit for
these: we need more transparency from HW manufacturers on their li
mitations.
Solution: Make Bitcoin HW actually compatible with Bitcoin :D


Inputs (mainly for pre-signed Tx):
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Problem: Poisoned inputs are a major risk for HW as they don't know the= UTXO set. While this can be exploited for fee
attacks, it is a bigger threat to pre-signed transactions protocols. Once a= ny input of a (pre-signed)transaction is
spent, this transaction isn't valid anymore. Most pre-signed transactio= ns protocols are used today as a form of defense
mechanism, spending any input would mean incapacitating the entire defense = mechanism.
Proposed improvement: for protocols that requires it, keeping track of inpu= ts already signed once would be extremely
helpful. Going further, most of these protocols require to follow a specifi= c signing order (typically the "clawback"
first, then the regular spend path) so adding a way to check that a "c= lawback" has been signed first, with the same
input, would be very helpful. All of this on the dev
ice itself.




I understand some of these changes may be very difficult, especially given = the low memory and computational power of
secure elements. However I truly believe most of these points are a MUST ha= ve for any decent security. If you don't
assume the computer on which the transaction is crafted is compromised, the= n you don't need a hardware wallet. If you
assume it may be compromised, then the HW needs to be able to defend agains= t those.

Revault does not plan on building hardware wallets, we hope existing and up= coming manufacturers will implement a strong
security that we could use for the Revault protocol users. Vault users will= likely hold very large sums and would be
happy to pay a high premium for more secure HW. This will hopefully encoura= ge existing players to keep on improving
their devices and that will ultimately benefit us all.

Feel free to reply with your comments or adding suggestions, I am not a har= dware wallet expert and would take criticism
wit
hout being offended.

Kind Regards,
Kevin Loaec

[1]: https://lists.linux= foundation.org/pipermail/bitcoin-dev/2020-May/017835.html
[2]: https://github.com/re-vault/practical-re= vault/issues/59
[3]: https://lists= .linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html [4]: https://btcguide.github.io/known-= issues/verify-receive-address
[5]: https://gitlab.com/lightning-signer/docs
[6]: https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multi= sig-setups-are-insecure/

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000eb3fbe05b90e8fe0--