Potential Exploits

A Validating Signer protects from loss even in the case of a complete node compromise. It uses a comprehensive list of policy controls to achieve this. This is a list of potential exploits if the controls are not implemented. A Blind Signer is susceptible to these exploits.

Routing a Payment

• the input channel has been closed or the funding is not confirmed. The value is therefore sent on the output but not received on the input and therefore is a loss. All channel funds can be siphoned away.
• 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
• an HTLC succeeds on the output, but the preimage is not made available to us. We can't claim the funds from the input
• an input HTLC expires before the output does, and the output is claimed by the counterparty
• the input and output payment hashes do not match, and the output is claimed by the counterparty

Revocation

• we sign a revoked transaction, which allows the counterparty to take all funds
• we revoke a signed transaction, which allows the counterparty to take all funds
• the counterparty does not revoke a previous state where it has all the funds, and later publishes it when the state should have had the funds going to us
• we fail to publish a breach-remedy in time and no alert is raised

Sending a Payment

• we send a payment to the wrong destination
• we overpay an invoice
• we pay the invoice more than once

Other

• a too-short to_self_delay is selected for the counterparty - the counterparty can publish an old state and get away with it - losing channel funds
• the funding transaction output goes to an attacker address
• funding transaction change goes to an attacker address
• the fee is too high, burning funds
• the value to us as the funder for the initial commitment is too low, letting the counterparty take the channel funds
• the destination addresses for outputs going to us are incorrect
• an output is dust, preventing us from closing the channel due to bitcoin rules
• HTLC locktime is too far in the future, locking our funds for a long time
• a closing transaction sends our funds to the attacker
• a closing transaction sends us less funds than due in the current state
• a too-long to_self_delay is selected for us - our funds may be locked for a long time