Date: Fri, 15 Jan 2021 00:28:21 +0000
To: Kevin Loaec <kevin@revault.dev>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <IUjfIb-kgkDrL-Lq2aezCk5sjSoICBCUEZbchHqLDFStputPn0Y8xmPHdIwg6tEwZIMI-075CMO1jwy4FgIhhTgDclpdJXwRYlrESFDqfSc=@protonmail.com>
In-Reply-To: <da42f7e09cabcaa935bce4036340ef14f4bf454c.camel@revault.dev>
References: <da42f7e09cabcaa935bce4036340ef14f4bf454c.camel@revault.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features
Precedence: list

Good Morning Kevin,

>     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 t=
he 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 transact=
ions protocols are used today as a form of defense
>     mechanism, spending any input would mean incapacitating the entire de=
fense mechanism.
>     Proposed improvement: for protocols that requires it, keeping track o=
f inputs already signed once would be extremely
>     helpful. Going further, most of these protocols require to follow a s=
pecific 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 rememb=
er that the clawback has been signed before.
My post on HW devices for Lightning (which you already linked) contains a s=
uggestion to use a Merklized persistent data structure to maintain state fo=
r the hardware device, with a majority of the state storage on the trust-mi=
nimized 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 ente=
r seed words on an online device", as the typical advice goes.
Most clawback transactions are time-based, and *must* be broadcast at a par=
ticular 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 *mus=
t* 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 c=
an have an advantage / can steal if the clawback is not broadcast in a time=
ly manner, thus the software that is corrupted by the counterparty can be c=
orrupted 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 devi=
ce, 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 word=
s on an online device" for any protocol with a time-based clawback componen=
t (and honestly there seems to be no clawback mechanism that is not time-ba=
sed).

Ultimately, I consider the blockchain as a proof of time passing, and as th=
e 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