ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-23 📝 Original message: Good morning Bastien, > > ...
📅 Original date posted:2020-10-23
📝 Original message:
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
📝 Original message:
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