📅 Original date posted:2021-01-17
📝 Original message:Dear ZmnSCPxj,
On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210116/25ea76d6/attachment-0001.html>;
Devrandom [ARCHIVE] /
npub1j0…w9k8n
2023-06-07 18:28:13
in reply to nevent1q…hzum
Author Public Key
npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8nPublished at
2023-06-07 18:28:13Event JSON
{
"id": "9a36c0402a9882bb98cac34415fe090349104ef44bb9b682346581a9e24256be",
"pubkey": "93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85",
"created_at": 1686162493,
"kind": 1,
"tags": [
[
"e",
"39ba8486eb5c0a5939bf417f9f771fb3deb8129902423e68777f5afe11d3238b",
"",
"root"
],
[
"e",
"6edcb87b0b00f255e5d513ea580fb7cb6220c8c7c0a9c6931d7fae56435db4f7",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-01-17\n📝 Original message:Dear ZmnSCPxj,\n\nOn Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The primary issue here is that we have a base assumption that the hardware\n\u003e wallet cannot be sophisticated enough to have Internet access; \"do not\n\u003e enter seed words on an online device\", as the typical advice goes.\n\u003e Most clawback transactions are time-based, and *must* be broadcast at a\n\u003e particular blockheight.\n\u003e Yet if the hardware wallet cannot be an online device, then it cannot know\n\u003e the current blockheight is now at a time when the clawback transaction\n\u003e *must* be broadcast.\n\u003e\n\u003e Thus, the hardware must always tr\\*st the software to actually perform the\n\u003e clawback in that case.\n\u003e\n\nI believe it is possible to achieve much of the desired \"liveness\"\nrequirements without compromising too much on the air-gap. The solution\nrequires the following:\n\n- a set of UTXO oracles which attest to the UTXO set\n- optionally, a set of clock oracles which attest to the current time (e.g.\nusing the roughtime protocol)\n- an air-gap connection between the node software and the signer, e.g.\nusing a narrow optical or serial protocol\n- a set of operators that can react to lack of liveness\n\nThe Signer performs the following steps periodically:\n\n- if the funding UTXO has not been spent (per oracle attestation), proceed\nnormally with any channel commitment signing\n- if the funding UTXO has been spent, ensure that the node provided the\nspending tx, and check if there is any reaction needed (e.g. a justice tx\nis needed)\n- if a reaction is needed, ensure that there is a further spend within a\ncertain deadline (shorter than the CSV/CLTV deadline)\n- if there is no deadline violation, sign a heartbeat message with the\ncurrent time (either from a local clock or from oracle clock)\n\nThe node software then relays the signed heartbeat message to the\noperators, e.g. through Tor. If a heartbeat is not seen by the operators,\nthey manually intervene (e.g. by standing up a clean node).\n\nOf course, we will never have Lightning paper wallets, by definition, since\nyou can't participate in the network without being online. But the above\nsetup seems to be at least as secure as USB hardware wallets attached to\nonline machines. You could even have intermittently connected signers for\nslow-moving channels, or signers behind Tor, etc. .\n\n--\ndevrandom\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210116/25ea76d6/attachment-0001.html\u003e",
"sig": "426754778f74bf477fbeb6d99e5ae878dbbbdf9a28985f363271cebd2887a5455c00acf662a0dcdce1ec548c516ac2f4a53bc533d759f0278ce878ca8fcc3f0f"
}