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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
