I can't imagine the constants add up that fast... Allow 25 channels per peer and limit your peers reasonably and the cost should be low enough. Really not sure why something like a 25 channel limit should limit any usage or reasonably burden a node, what am I missing?
On January 15, 2018 2:14:57 AM UTC, ZmnSCPxj <[email protected]> wrote: >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: [email protected] >> To: ZmnSCPxj <[email protected]> >> lightning-dev\\\\@lists.linuxfoundation.org ><[email protected]> >> >> 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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
