Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Good morning all, Looking at BOLT#1, there is an `error` message which is supposed to "fail the channel". At a first glance, it seems to be what is basically a superpowered version of `funding_cancelled`, since it only fails the channel (and in particular does not indicate to fail the peer or

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

I do not see the relevance of the example. The limit I propose that nodes will impose is a limit imposed on *each* *peer*, not a limit imposed on all peers in total. Indeed, imposing the limit on each peer reduces the actual CPU, bandwidth, and storage resources that each peer can consume on

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

> Yes, but it still limits how much damage each peer can do to the node. > And I think you overstate the ease of distributed denial of service attacks, > and the relative resource consumption differences on an attacker simulating > multiple nodes versus one simulating a single node. So assume

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

As mentioned in the text, this is imposed by you on each peer that connects to you. The point is to prevent a single peer from consuming all your memory and CPU and prevent you from servicing legitimate peers- i.e. it prevents denial of service using a single peer and forces attackers to use a

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Ok, so limit things to 100 channels... Still don't see why the constants get into unreasonable load here... On January 15, 2018 2:53:07 AM UTC, ZmnSCPxj wrote: >Good morning Matt, > >> I can't imagine the constants add up that fast... Allow 25 channels >per peer and

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Good morning Matt, > 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

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

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 &

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Hello, > intended to inform the fundee node that the funder node is definitely sure > that the channel funding transaction can never confirm If the deprecated tx initially sent funds to the fundee via push_msat, then the fundee may not want to trust the funder on this. One way to do it

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

I have to say I'm rather not a fan of this idea. Adding messages which do not result in different node behavior other then waiting for the timeout with little overhead on the node to simply keep watching for the funding transaction is a recipe for ending up with a needlessly complex protocol