From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6931C013A for ; Fri, 15 Jan 2021 00:28:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id D3A8487368 for ; Fri, 15 Jan 2021 00:28:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkLUoEmfUElM for ; Fri, 15 Jan 2021 00:28:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by hemlock.osuosl.org (Postfix) with ESMTPS id 48F768722F for ; Fri, 15 Jan 2021 00:28:28 +0000 (UTC) Date: Fri, 15 Jan 2021 00:28:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1610670504; bh=NvdmGSRKtlygBQryi3Ym4bBFXWB63lRGHmcXf6enwxE=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=xTTmPoe6xLwYpuNPZiS00gdLQU0wfmI8OSCPFrRZjB0Jo7jdV5nsm62tG5kwPlp5o I/ATCcrSMTvpM9Ie+735sYEHzX2y9gass0p0caPGuGcKK1ImxE8D6Xt8ACN+6OTwaX eyCIehorOxuM2LayH4V8p7NVPIBiq/yApNWQge1c= To: Kevin Loaec , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 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: Fri, 15 Jan 2021 00:28:30 -0000 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