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 8DF8BC013A for ; Sun, 17 Jan 2021 02:47:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 7579F86108 for ; Sun, 17 Jan 2021 02:47:10 +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 Xc4WZiT02GUA for ; Sun, 17 Jan 2021 02:47:08 +0000 (UTC) X-Greylist: delayed 00:06:09 by SQLgrey-1.7.6 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by fraxinus.osuosl.org (Postfix) with ESMTPS id CE4B9860AD for ; Sun, 17 Jan 2021 02:47:07 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id a10so2253059ejg.10 for ; Sat, 16 Jan 2021 18:47:07 -0800 (PST) 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:cc; bh=x8rbOfTi3iu04pyxE7RTx9rLXesHsg8Kvl4EKRXGEug=; b=LyOg1479OSUDBW9lgpfzW3dm9chnufGB24b51qPGRT2vPUoDKAXZbIzEKLt8/IyyST x7DaAtaenRBlPt3zkBT/JFXMOsRpUcfKRpX9jcT679Gvr3ch3wKW0KJ7eu4E+p2Aj+Lz WIqvJKiQVabsrNzJF5rYXaqQFad04XwYJtuq/1Y3f1/ONt7D4XM5pjo2mYeK4Wcn+MYl CS03kC0gXrhy27g7+eoVx3wTKYcFHA7/u9ch6znH9At4roOvvVoXgzV9FlzXq9z6Ltem Ikl8rcE7WvSCFP/qldNNcPR54v0B+dH06ipoZpbHI6kqJzJ001s/HggXScZq+1nqo1Qr SOSw== X-Gm-Message-State: AOAM531XICzc1Fv3Evvf36STlXueb4K/ATOZg9YsjUOTz7LxEsRw4b62 hi0Gd3U73Iu0Z5fd+6hS1tEku1nfhZJf09ItFZyw/a8GT/TFUTSH580= X-Google-Smtp-Source: ABdhPJwY9fE1dQ4AAhfrcv/mH5/ZOSwkEUdHqi+uM5E3C/GfQ4GdKFVY3jQBJxOzDsEAbJgh7sRqaFUjlVS1Iqyna8k= X-Received: by 2002:a17:906:cf81:: with SMTP id um1mr13771386ejb.122.1610851256160; Sat, 16 Jan 2021 18:40:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Devrandom Date: Sat, 16 Jan 2021 18:40:44 -0800 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e8e9e605b90f8888" X-Mailman-Approved-At: Sun, 17 Jan 2021 02:50:30 +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 02:47:10 -0000 --000000000000e8e9e605b90f8888 Content-Type: text/plain; charset="UTF-8" Dear ZmnSCPxj, On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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. > I believe it is possible to achieve much of the desired "liveness" requirements without compromising too much on the air-gap. The solution requires the following: - a set of UTXO oracles which attest to the UTXO set - optionally, a set of clock oracles which attest to the current time (e.g. using the roughtime protocol) - an air-gap connection between the node software and the signer, e.g. using a narrow optical or serial protocol - a set of operators that can react to lack of liveness The Signer performs the following steps periodically: - if the funding UTXO has not been spent (per oracle attestation), proceed normally with any channel commitment signing - if the funding UTXO has been spent, ensure that the node provided the spending tx, and check if there is any reaction needed (e.g. a justice tx is needed) - if a reaction is needed, ensure that there is a further spend within a certain deadline (shorter than the CSV/CLTV deadline) - if there is no deadline violation, sign a heartbeat message with the current time (either from a local clock or from oracle clock) The node software then relays the signed heartbeat message to the operators, e.g. through Tor. If a heartbeat is not seen by the operators, they manually intervene (e.g. by standing up a clean node). Of course, we will never have Lightning paper wallets, by definition, since you can't participate in the network without being online. But the above setup seems to be at least as secure as USB hardware wallets attached to online machines. You could even have intermittently connected signers for slow-moving channels, or signers behind Tor, etc. . -- devrandom --000000000000e8e9e605b90f8888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear ZmnSCPxj,

On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPx= j via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The primary issue here is that we = have a base assumption that the hardware wallet cannot be sophisticated eno= ugh to have Internet access; "do not enter seed words on an online dev= ice", 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.

I believe it is = possible to achieve much of the desired "liveness" requirements w= ithout compromising too much on the air-gap.=C2=A0 The solution requires th= e following:

- a set of UTXO oracles which at= test to the UTXO set
- optionally, a set of clock oracles which attest= to the current time (e.g. using the roughtime protocol)
- an= air-gap connection between the node software and the signer, e.g. using a = narrow optical or serial protocol
- a set of operators that can r= eact to lack of liveness

The Signer performs t= he following steps periodically:

- if the funding = UTXO has not been spent (per oracle attestation), proceed normally with any= channel commitment signing
- if the funding UTXO has been sp= ent, ensure that the node provided the spending tx, and check if there is a= ny reaction needed (e.g. a justice tx is needed)
- if a react= ion is needed, ensure that there is a further spend within a certain deadli= ne (shorter than the CSV/CLTV deadline)
- if there is no deadline= violation, sign a heartbeat message with the current time (either from a l= ocal clock or from oracle clock)

The node software= then relays the signed heartbeat message to the operators, e.g. through To= r.=C2=A0 If a heartbeat is not seen by the operators, they manually interve= ne (e.g. by standing up a clean node).

Of course, = we will never have Lightning paper wallets, by definition, since you can= 9;t participate in the network without being online.=C2=A0 But the above se= tup seems to be at least as secure as USB hardware wallets attached to onli= ne machines.=C2=A0 You could even have intermittently connected signers for= slow-moving channels, or signers behind Tor, etc. .

--
devrandom

--000000000000e8e9e605b90f8888--