From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Kevin Loaec <kevin@revault•dev>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features
Date: Fri, 15 Jan 2021 00:28:21 +0000 [thread overview]
Message-ID: <IUjfIb-kgkDrL-Lq2aezCk5sjSoICBCUEZbchHqLDFStputPn0Y8xmPHdIwg6tEwZIMI-075CMO1jwy4FgIhhTgDclpdJXwRYlrESFDqfSc=@protonmail.com> (raw)
In-Reply-To: <da42f7e09cabcaa935bce4036340ef14f4bf454c.camel@revault.dev>
Good Morning Kevin,
> Inputs (mainly for pre-signed Tx):
> ==================================
> 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 defense 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.
This requires the hardware device to maintain some state in order to remember that the clawback has been signed before.
My post on HW devices for Lightning (which you already linked) contains a suggestion to use a Merklized persistent data structure to maintain state for the hardware device, with a majority of the state storage on the trust-minimized software.
The primary issue here is that we have a base assumption that the hardware wallet cannot be sophisticated enough to have Internet access; "do not enter seed words on an online device", as the typical advice goes.
Most clawback transactions are time-based, and *must* be broadcast at a particular blockheight.
Yet if the hardware wallet cannot be an online device, then it cannot know the current blockheight is now at a time when the clawback transaction *must* be broadcast.
Thus, the hardware must always tr\*st the software to actually perform the clawback in that case.
In protocols where clawbacks are at all necessary, often the counterparty can have an advantage / can steal if the clawback is not broadcast in a timely manner, thus the software that is corrupted by the counterparty can be corrupted to simply not broadcast the clawback.
If the software on an online device cannot be tr\*sted (which is the model that hardware wallets use) then the software cannot be tr\*sted to provide correct information on the current blockheight to the offline hardware device, and cannot be tr\*sted to use clawback transactions.
It seems to me that we cannot use the same model of "do not enter seed words on an online device" for any protocol with a time-based clawback component (and honestly there seems to be no clawback mechanism that is not time-based).
Ultimately, I consider the blockchain as a proof of time passing, and as the blockchain is an online structure, we can only get at that proof by going online and actively searching for the block tip.
Yet going online increases our attack surface.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-01-15 0:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 18:17 Kevin Loaec
2021-01-15 0:28 ` ZmnSCPxj [this message]
2021-01-17 2:40 ` Devrandom
2021-01-17 1:31 ` Antoine Riard
2021-01-17 10:02 ` darosior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='IUjfIb-kgkDrL-Lq2aezCk5sjSoICBCUEZbchHqLDFStputPn0Y8xmPHdIwg6tEwZIMI-075CMO1jwy4FgIhhTgDclpdJXwRYlrESFDqfSc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kevin@revault$(echo .)dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox