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.
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. 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? If so, what happens if the connection between the "UTXO Set Oracle" remote device and the `lightning-signer` is interrupted? In particular: * Incoming forward arrives. * Compromised node accepts the incoming HTLC and offers outgoing HTLC. * Presumably the `lightning-signer` signs off on this, as long as the outgoing HTLC is of lower value etc etc. * Compromised node stops communicating with the `lightning-signer`. * Outgoing HTLC times out, but compromised node and the outgoing peer do nothing. * Incoming HTLC times out, and the incoming peer unilaterally closes the channel, claiming the timelock branch of the HTLC onchain. * Outgoing peer unilaterally closes the channel, claiming the hashlock branch of the outgoing HTLC onchain. Unless the `lightning-signer` unilaterally closes the channel when the outgoing HTLC times out and actively signs and broadcasts the timelock branch for the outgoing HTLC, then this leads to funds loss. This requires that the `lightning-signer` be attached to a Bitcoin node that is capable of: * Actively finding and connecting to multiple Bitcoin peers. * Actively checking the block header chain (acceptable at only SPV security since you really only care about blockheight, and have a UTOX Set Oracle which upgrades the rest of your security from SPV to full?). * Actively broadcasting unilateral closes and HTLC timelock claims for outgoing HTLCs. Is that how `lightning-signer` is designed? 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? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
