Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-15 📝 Original message: Thank you for the ...
📅 Original date posted:2020-01-15
📝 Original message:
Thank you for the detailed evaluation. Please see inline comments.
To make reading easier, I've replaced some uncontroversial text with
[...].
On Tue, Jan 14, 2020 at 7:15 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> [...]
> In any case, the goal is to have some hardware unit, using only a simple communications channel with the software, to act as signer for all Lightning-related things (channel funding, channel updates, reclaiming funds after channel close).
> As is typical for such Bitcoin-related hardware units, it might possess its own user interface by which it can require confirmation of certain actions.
> Also, to reduce risk of hacking, the hardware unit does not have a connection to the netwrok, only a communications channel that is restricted to a local direct connection (such as USB).
>
> I will now demonstrate that such a design cannot achieve what an onchain Bitcoin hardware wallet does, namely that the hardware need not tr\*st the software and need not keep any state beyond the private key (which remains constant).
> For Lightning, it seems any hardware would require tr\*st in the software *and* some state.
Agreed, any external signer must maintain state because it must not
sign revoked transactions, etc. .
>
> Channel Updates
> ===============
>
> [...]
> Thus, the hardware has to remember at least what the current state is, and store this knowledge in persistent, secure, modifiable memory that the software cannot touch.
Agreed.
> It need not store the *whole* state: for example, it could store just a commitment to the current state (and have the software store the entire state).
> In fact, it is best for the hardware to store the *signature* for the commitment transaction:
I would say that's not enough, if we assume that the attacker can
destroy the underlying data, and destroy all backups. If the attacker
can do that, the node is at the mercy of channel partners, since they
will be able to publish old state without the possibility of
retaliation. Thus there needs to be a secure form of storage where at
least one backup must be recoverable at all times within the penalty
time window.
I do agree that a low-resource hardware wallet may just store the
signature, or other commitment to the state. In that case, we could
store the full data using an append-only log to a hardened machine
that specializes in preventing destruction of data by an attacker.
>
> [...]
>
> Tr\*sted Eventual Synchrony of Two Commitments
> ==============================================
> [...]
> This may prevent some HTLCs from being safely forwardable, but that only means stalls in payment forwarding.
This is a good point we haven't considered in our original writeup.
Intuitively, you are right that this can only result in stalls.
>
>
>
> Non-publication of Revoked Transactions
> =======================================
>
> [...]
> To prevent publication of our *own* commitment transaction at least, the hardware can simply not sign *own* commitment transactions as they are created.
Agreed.
>
> [...]
> Thus, the hardware has to have a concept of a "closed" channel, where it marks that the current txid for the *own* commitment transaction is the last one, and it
Agreed.
>
> [...]
> Thus the hardware provides three APIs:
>
> * Mark-as-close.
> * Get-final-signature (unilateral or mutual close option).
> * Delete-closed.
It seems that the first API call can be folded into the second. Also,
delete must be only performed once enough time has passed so that the
closing tx is unlikely to be reorged out of existence. This requires
the hardware wallet to have a trusted source of knowledge about the
state of the blockchain or current time. We wrote about UTXO set
oracle and the use of roughtime oracles in our original writeup.
>
> [...]
> Tr\*sted Revocation of Old Remote State
> =======================================
>
> Unfortunately, the hardware has to tr\*st the software to check that the other node is not cheating.
> As the hardware itself is not capable of accessing the blockchain or mempool, it cannot do this checking directly.
> Thus, revocation of old remote state is not ensurable by the hardware.
I am more optimistic about this. Publishing of penalty transactions
can be delegated to a quorum of watchtowers, some possibly run by
other entities. The node software can prove to the hardware that the
watchtowers have been informed of new state by providing a receipt
signed by the watchtowers. Thus it's possible to reduce trust in the
node software.
>
>
> As revocation can only be done by the software anyway, the revocation secrets for the *remote* commitment transactions can be stored by the software only.
> The hardware need never learn the revocation secrets as it can do nothing with them anyway.
I would at least back up the secrets in the secure storage attached to
the hardware store, so that the node can be recreated if the node
software has been catastrophically compromised.
>
> Opening a Channel
> =================
>
> [...]
> If there is a difference, that implies that this node is what pays the fee, and the hardware should probably double-confirm with the user using its UI whether the paid fees are acceptab;e.
If the fee is under a preset threshold, it can be auto-approved.
>
>
> Tr\*sted Forwarding
> ===================
>
> Forwarding should be automated and not require a confirmation from the user on the hardware unit UI.
> Unfortunately, the hardware has to trust the software to actually perform forwarding correctly.
Let's look at this carefully, I feel it should be possible to prove
correctness of forwarding to the hardware.
>
> However, the hardware has to keep track that an incoming HTLC only has at most one outgoing HTLC,.
> It cannot identify using the hash, incidentally: it is theoretically possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> E -> C -> F, where C appears twice.
I think it's enough to require that each incoming HTLC can be
associated with a single outgoing HTLC. The hardware would have to
maintain state about which HTLCs have been "used up" in this way.
>
> Further, if a payment attempt fails, then the ultimate payer might still try to route through this node, giving a different postfix past this node, so this node may forward the same hash twice on two or more different payment attempts.
hmm... that doesn't sound safe, because then two different nodes would
be able to claim the funds from us, and we can only propagate back to
a single input, so we lose funds. If the Lightning protocol allows
this, then it sounds like a design issue. Seems like the failed HTLC
should be invalidated first. The invalidation can be proven to the
hardware (a new commitment tx is signed, removing the HTLC, or the
outgoing channel is closed).
>
> [...]
> Regardless, even if we somehow, the *enforcement* of HTLCs is still controlled by the software:
>
> * The hardware has no access to the blockchain, thus it cannot know if the incoming HTLC is in fact something in the deep past already.
> A corrupted software can induce the hardware to create an outgoing HTLC whose timelock is deeply in the past, then refuse to take the timelock branch of the outgoing HTLC while letting the timelock branch of the incoming HTLC be claimed by the other nodes.
See above about watchtowers, and trusted sources of time/blockchain state.
>
>
> Thus, forwarding is still trusted.
>
> [...]
> Reducing Storage Size
> =====================
>
> The hardware can, instead of storing multiple channel slots and payment slots in its own persistent memory, can instead just store a single *commitment* to the current state it knows to be valid.
Agreed, but see the need to have a reliable backup above.
>
>
>
> Regards,
> ZmnSCPxj
📝 Original message:
Thank you for the detailed evaluation. Please see inline comments.
To make reading easier, I've replaced some uncontroversial text with
[...].
On Tue, Jan 14, 2020 at 7:15 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> [...]
> In any case, the goal is to have some hardware unit, using only a simple communications channel with the software, to act as signer for all Lightning-related things (channel funding, channel updates, reclaiming funds after channel close).
> As is typical for such Bitcoin-related hardware units, it might possess its own user interface by which it can require confirmation of certain actions.
> Also, to reduce risk of hacking, the hardware unit does not have a connection to the netwrok, only a communications channel that is restricted to a local direct connection (such as USB).
>
> I will now demonstrate that such a design cannot achieve what an onchain Bitcoin hardware wallet does, namely that the hardware need not tr\*st the software and need not keep any state beyond the private key (which remains constant).
> For Lightning, it seems any hardware would require tr\*st in the software *and* some state.
Agreed, any external signer must maintain state because it must not
sign revoked transactions, etc. .
>
> Channel Updates
> ===============
>
> [...]
> Thus, the hardware has to remember at least what the current state is, and store this knowledge in persistent, secure, modifiable memory that the software cannot touch.
Agreed.
> It need not store the *whole* state: for example, it could store just a commitment to the current state (and have the software store the entire state).
> In fact, it is best for the hardware to store the *signature* for the commitment transaction:
I would say that's not enough, if we assume that the attacker can
destroy the underlying data, and destroy all backups. If the attacker
can do that, the node is at the mercy of channel partners, since they
will be able to publish old state without the possibility of
retaliation. Thus there needs to be a secure form of storage where at
least one backup must be recoverable at all times within the penalty
time window.
I do agree that a low-resource hardware wallet may just store the
signature, or other commitment to the state. In that case, we could
store the full data using an append-only log to a hardened machine
that specializes in preventing destruction of data by an attacker.
>
> [...]
>
> Tr\*sted Eventual Synchrony of Two Commitments
> ==============================================
> [...]
> This may prevent some HTLCs from being safely forwardable, but that only means stalls in payment forwarding.
This is a good point we haven't considered in our original writeup.
Intuitively, you are right that this can only result in stalls.
>
>
>
> Non-publication of Revoked Transactions
> =======================================
>
> [...]
> To prevent publication of our *own* commitment transaction at least, the hardware can simply not sign *own* commitment transactions as they are created.
Agreed.
>
> [...]
> Thus, the hardware has to have a concept of a "closed" channel, where it marks that the current txid for the *own* commitment transaction is the last one, and it
Agreed.
>
> [...]
> Thus the hardware provides three APIs:
>
> * Mark-as-close.
> * Get-final-signature (unilateral or mutual close option).
> * Delete-closed.
It seems that the first API call can be folded into the second. Also,
delete must be only performed once enough time has passed so that the
closing tx is unlikely to be reorged out of existence. This requires
the hardware wallet to have a trusted source of knowledge about the
state of the blockchain or current time. We wrote about UTXO set
oracle and the use of roughtime oracles in our original writeup.
>
> [...]
> Tr\*sted Revocation of Old Remote State
> =======================================
>
> Unfortunately, the hardware has to tr\*st the software to check that the other node is not cheating.
> As the hardware itself is not capable of accessing the blockchain or mempool, it cannot do this checking directly.
> Thus, revocation of old remote state is not ensurable by the hardware.
I am more optimistic about this. Publishing of penalty transactions
can be delegated to a quorum of watchtowers, some possibly run by
other entities. The node software can prove to the hardware that the
watchtowers have been informed of new state by providing a receipt
signed by the watchtowers. Thus it's possible to reduce trust in the
node software.
>
>
> As revocation can only be done by the software anyway, the revocation secrets for the *remote* commitment transactions can be stored by the software only.
> The hardware need never learn the revocation secrets as it can do nothing with them anyway.
I would at least back up the secrets in the secure storage attached to
the hardware store, so that the node can be recreated if the node
software has been catastrophically compromised.
>
> Opening a Channel
> =================
>
> [...]
> If there is a difference, that implies that this node is what pays the fee, and the hardware should probably double-confirm with the user using its UI whether the paid fees are acceptab;e.
If the fee is under a preset threshold, it can be auto-approved.
>
>
> Tr\*sted Forwarding
> ===================
>
> Forwarding should be automated and not require a confirmation from the user on the hardware unit UI.
> Unfortunately, the hardware has to trust the software to actually perform forwarding correctly.
Let's look at this carefully, I feel it should be possible to prove
correctness of forwarding to the hardware.
>
> However, the hardware has to keep track that an incoming HTLC only has at most one outgoing HTLC,.
> It cannot identify using the hash, incidentally: it is theoretically possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> E -> C -> F, where C appears twice.
I think it's enough to require that each incoming HTLC can be
associated with a single outgoing HTLC. The hardware would have to
maintain state about which HTLCs have been "used up" in this way.
>
> Further, if a payment attempt fails, then the ultimate payer might still try to route through this node, giving a different postfix past this node, so this node may forward the same hash twice on two or more different payment attempts.
hmm... that doesn't sound safe, because then two different nodes would
be able to claim the funds from us, and we can only propagate back to
a single input, so we lose funds. If the Lightning protocol allows
this, then it sounds like a design issue. Seems like the failed HTLC
should be invalidated first. The invalidation can be proven to the
hardware (a new commitment tx is signed, removing the HTLC, or the
outgoing channel is closed).
>
> [...]
> Regardless, even if we somehow, the *enforcement* of HTLCs is still controlled by the software:
>
> * The hardware has no access to the blockchain, thus it cannot know if the incoming HTLC is in fact something in the deep past already.
> A corrupted software can induce the hardware to create an outgoing HTLC whose timelock is deeply in the past, then refuse to take the timelock branch of the outgoing HTLC while letting the timelock branch of the incoming HTLC be claimed by the other nodes.
See above about watchtowers, and trusted sources of time/blockchain state.
>
>
> Thus, forwarding is still trusted.
>
> [...]
> Reducing Storage Size
> =====================
>
> The hardware can, instead of storing multiple channel slots and payment slots in its own persistent memory, can instead just store a single *commitment* to the current state it knows to be valid.
Agreed, but see the need to have a reliable backup above.
>
>
>
> Regards,
> ZmnSCPxj