📅 Original date posted:2022-05-09
📝 Original message:
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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:06:00
in reply to nevent1q…vgda
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:06:00Event JSON
{
"id": "98c85627967da87a0e6fa15d362a2d033626d17616bc3292aba2edda1a340053",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315960,
"kind": 1,
"tags": [
[
"e",
"fd83037e8858fe6f85919295f43f2d74d0a06761fc47673d956b45c2da9be3de",
"",
"root"
],
[
"e",
"617e47cc42f38e9507af360ca98b0511797568fb4bad58e5cf91636488b84995",
"",
"reply"
],
[
"p",
"93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85"
]
],
"content": "📅 Original date posted:2022-05-09\n📝 Original message:\nGood morning devrandom,\n\nIt 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.\n\nOtherwise, 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.\n\nLooking 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?\nIs this intended to be a remote device from the `lightning-signer` device?\nIf so, what happens if the connection between the \"UTXO Set Oracle\" remote device and the `lightning-signer` is interrupted?\n\nIn particular:\n\n* Incoming forward arrives.\n* Compromised node accepts the incoming HTLC and offers outgoing HTLC.\n * Presumably the `lightning-signer` signs off on this, as long as the outgoing HTLC is of lower value etc etc.\n* Compromised node stops communicating with the `lightning-signer`.\n* Outgoing HTLC times out, but compromised node and the outgoing peer do nothing.\n* Incoming HTLC times out, and the incoming peer unilaterally closes the channel, claiming the timelock branch of the HTLC onchain.\n* Outgoing peer unilaterally closes the channel, claiming the hashlock branch of the outgoing HTLC onchain.\n\nUnless 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.\nThis requires that the `lightning-signer` be attached to a Bitcoin node that is capable of:\n\n* Actively finding and connecting to multiple Bitcoin peers.\n* 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?).\n* Actively broadcasting unilateral closes and HTLC timelock claims for outgoing HTLCs.\n\nIs that how `lightning-signer` is designed?\n\nThis seems to be listed in: https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits\n\n\u003e 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\n\nIs there a mitigation, planned or implemented, against this exploit?\n\n\nRegards,\nZmnSCPxj",
"sig": "9ce33efc485072efd83aff5c5a76d2f0c842d57471f2264a5b171938b12a7a8bcb6e2d893f781929d3f68cd13b0682ebf1b20b2de8f29df87b9de6244d08f807"
}