[Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Oct 23 15:26:57 UTC 2020


Good morning Bastien,

> > C can trivially grief D here, making it look like D is delaying, by delaying its own `commitment_signed` containing the *removal* of the HTLC.
>
> You're right to dive into these, there may be something here.
> But I think your example doesn't work, let me know if I'm mistaken.
> D is the one who decides whether he'll be refunded or not, because D is the first to send the
> `commit_sig` that removes the HTLC. I think we would extend `commit_sig` with a tlv field that
> indicates "I refunded myself for HTLC N" to help C compute the same commit tx and verify sigs.

D sending `commitment_signed` simply means C has the option to use either the previous commitment or the new one.
C can still drop the previous commitment, which has the hold fee still owned by C.

C only loses that option by sending `revoke_and_ack`, so C can still unfairly delay this, and at this point D is holding the previous commitment (which, as mentioned, has the hold fee still owned by C).
So C can still delay by not revoking its previous commitment (`revoke_and_ack`) and not signing the D-side next commitment (`commitment_signed`).

On the *other* hand if C can only *take* the hold fee at this point by dropping onchain, then the onchain fees and the loss of a viable channel (meaning the funds of C in that channel need to be put back into a new channel, again onchain fees) might very well dominate.
Is this enough of a deterrent?

On the other *other* hand, rules which involve "SHOULD/MUST fail the channel" have classically caused headaches in interop, xref. the mass channel closes between C-Lightning and lnd nodes some years ago due to sudden onchain fee movements.

-------------

On a mildly related note I have this old crap I wrote earlier this year, it might be possible to glean something from it:

* https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002608.html


Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list