Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-10 📝 Original message: Good morning ZmnSCPxj, On ...

📅 Original date posted:2022-05-10
📝 Original message:
Good morning ZmnSCPxj,

On Mon, May 9, 2022 at 5:40 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning devrandom,
>
> It seems to me that a true validating Lightning signer would need to be a
> Bitcoin node with active mitigation against eclipse attacks, the ability to
> monitor the blockheight, and the ability to broadcast transactions.
>

The UTXO Oracle(s) have some additional properties that improve on a plain
Bitcoin node:

- they provide compact attestations that can be checked in an
isolated/hardened environment, so that the signer doesn't need to be
exposed to a network stack and can live on a consumer device or HSM
- a UTXO Oracle can send out attestations on a broadcast medium (e.g. live
behind Tor, satellite, etc.), so it's harder to block or eclipse
- the periodic attestation would cover the current block hash, and a
commitment for the UTXO set hash (e.g. hash of the compact filter history)

Broadcast is a separate concern. For broadcast, the intent is to have a
disaster recovery procedure:

- the signer sends out a heartbeat if it has a quorum of non-stale oracle
attestations and there are no upcoming safety deadlines (e.g. HTLC timeout
or need to breach-remedy)
- the heartbeats form a "deadman's switch" - if the node operator doesn't
get them, they spring into action
- the operator falls back to sneakernet for broadcasting a
closing/breach-remedy transaction if needed


>
> Otherwise, a compromised node can lie and tell the signer that the block
> height is much lower than it really is, letting the node peers clawback
> incoming HTLCs and claim outgoing HTLCs, leading to a net loss of funds in
> the forwarding case.
>

Right, routing nodes really need to be aware of the on-chain status of
incoming channels.


>
> Looking at the link, it seems to me that you have a "UTXO Set Oracle",
> does this inform your `lightning-signer` about block height and facilitate
> transaction broadcast?
> Is this intended to be a remote device from the `lightning-signer` device?
>

It could be a quorum of systems, remote from the signer device, some or all
of which may be under third-party operational control. The attestation for
a certain block is deterministic, so they should all agree.


> If so, what happens if the connection between the "UTXO Set Oracle" remote
> device and the `lightning-signer` is interrupted?
>

If there is no quorum, heartbeats would cease, which would alert the
operator to start disaster recovery.


>
> In particular:
> [...]
>

Agreed, that's the main attack scenario on a router that doesn't properly
chain the on-chain status of an input channel.

This seems to be listed in:
> https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits
>
> > an HTLC is failed and removed on the input before it is removed on the
> output. The output is then claimed by the counterparty, losing that amount
>
> Is there a mitigation, planned or implemented, against this exploit?
>

Yes, heartbeats would cease and the operator would manually intervene as
above.

That said, there is another potential mode: if you limit the value of
HTLCs in flight (e.g. 5% of channel value), are willing to lose that
amount, you don't do routing, and you have watchtowers, then you can live
without the UTXO Oracle component. This may be acceptable in a consumer
application.

Finally, we could essentially embed UTXO Oracles into the network if:

- we commit to compact-filters or utreexo roots in the consensus
- we are OK with SPV-style security, where we detect an eclipse by noticing
a reduction in block rate

But it's hard to say when the first item might be plausibly deployed.

--
devrandom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220510/b1cb218a/attachment-0001.html>;