Good morning Matt,
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message
> Local Time: January 15, 2018 9:00 AM
> UTC Time: January 15, 2018 1:00 AM
> From: lf-li...@mattcorallo.com
> To: ZmnSCPxj <zmnsc...@protonmail.com>
> lightning-dev\\\\@lists.linuxfoundation.org
> <lightning-dev@lists.linuxfoundation.org>
>
> Sounds to me like the lack of a protocol-required minimum timeout is the
> issue. Because the cost of tracking an unopened channel is relatively
> trivial, I see limited reason to bother notifying the peer that a channel has
> timed out. However, due to potentially radically different concepts for what
> is and isn't an acceptable wait time, it's likely useful to have something
> like "a receiving node MUST keep a channel ready to be used for at least a
> week prior to funding transaction confirmation. Thus, a node creating a
> funding transaction SHOULD double-spend and make unconfirmable a funding
> transaction which has not confirmed prior to a week."
Though the cost may be trivial for single channels, the cost can be made
arbitrarily high by a malicious node that just keeps sending `open_channel` ->
`funding_created` with random numbers for transaction ID. It seems sensible
for a node implementation to allow limiting the number of pending channel opens
for each peer to avoid this (e.g. c-lightning currently limits
one-channel-one-peer, even at opening). The intent of `funding_cancelled` is:
an honest party can free up the limited resource "number of pending channel
opens" by using this message, without having to wait for the timeout, whatever
the timeout is defined to be.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
