From lf-lists at mattcorallo.com Mon Jan 15 02:33:39 2018 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Mon, 15 Jan 2018 02:33:39 +0000 Subject: [Lightning-dev] [1.1] Proposed `funding_cancelled` message In-Reply-To: <74vW2keQrDb8mzHL9s3crq-0VxYMoYoMpQyFiJ-lPyM6sOmLrYHIsL--_MhR1Bg0ZIzI8qUrG2TCIgt9lTbjRKv2QqSyns-V1IW4mJnhjl4=@protonmail.com> References: <4lzjtI9sV6nbEzdEDLQSHYaFp-dSB9Vcxt6s1j5abYcvhIEsJblo0Oasl9yE88DhSn57kmn6eLId7WJHd32Cdu8RRT6h4aofT4tF7YJI7Zs=@protonmail.com> <5D5BBC3B-88EC-4001-AA86-D632471FBDA4@mattcorallo.com> <74vW2keQrDb8mzHL9s3crq-0VxYMoYoMpQyFiJ-lPyM6sOmLrYHIsL--_MhR1Bg0ZIzI8qUrG2TCIgt9lTbjRKv2QqSyns-V1IW4mJnhjl4=@protonmail.com> Message-ID: <06348FED-9F98-47F0-9477-B8F81931365A@mattcorallo.com> 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 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: lf-lists at mattcorallo.com >> To: ZmnSCPxj >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: