From c1.devrandom at niftybox.net Tue May 10 08:02:35 2022 From: c1.devrandom at niftybox.net (Devrandom) Date: Tue, 10 May 2022 01:02:35 -0700 Subject: [Lightning-dev] Blind Signing Considered Harmful In-Reply-To: References: Message-ID: Good morning ZmnSCPxj, On Mon, May 9, 2022 at 5:40 PM ZmnSCPxj 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: