From ZmnSCPxj at protonmail.com Fri Oct 23 15:26:57 2020 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 23 Oct 2020 15:26:57 +0000 Subject: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself In-Reply-To: References: <0hQYsditdQaLVQpwyuLn5mOMsM6mxOY3TwM3teUDurYr7wFx0016M6wxJUlIM-Y3KP6g1YwtyhbXw34BFsbz3jNDfe1JsUf15UHBQ0sM4xw=@protonmail.com> Message-ID: 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