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

[ZmnSCPxj via Lightning-dev]

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 fail the connection).

I will need to check exactly how each implementation reacts to an `error` 
message while awaiting lockin, but it looks like `funding_cancelled` is 
unnecessary for RBF and multi-funding/coinjoined funding transactions.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 the attacked 
node.  If it did not limit each peer, then each attacking peer can consume 
significantly more resources (CPU, bandwidth, storage) that other, legitimate 
peers would want to use.  By limiting each peer to some maximum number of 
channel open attempts, it allows the server to serve more peers, and possibly 
shrug off a 10k or 100k attack (depending on the actual CPU/bandwidth/storage 
resources it has) that it otherwise would be unable to service if each peer 
could consume an arbitrary amount of resources on the server.

In any case this has diverged from "propose `funding_cancelled` message".  
Obviously only cooperative, non-attacking peers will use `funding_canclled`, 
but only cooperative non-attacking peers will start an `open_channel` sequence 
and broadcast a valid funding tx to the blockchain network anyway.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
On January 21, 2018 8:57 PM, <7ri...@gmail.com> wrote:

>
>
>> 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 the following situation: Someone has gotten a "bum deal" on their 
> pizza (or thinks they have), and they want to take down their pizza provider. 
> They note the lightning node the pizza provider uses happens to be some 
> particular address, so they hire out a 10k node botnet (rather small in the 
> real world), and ask each bot to open as many transactions as possible, as 
> fast as possible, without completing any of them, with the ip address of the 
> node in question. The server eventually says "I'm not accepting any more 
> connections, because I have too many outstanding connections right now," 
> which effectively takes it off line for new transactions, blocking anyone who 
> uses that node from any sort of transaction. How long can this last? So long 
> as the botnet continues asking for new connections.
>
> There are ways around this on the network side -- specifically using anycast, 
> like DNS does, to spread the attack around -- but I'm not certain anycast 
> would work in this case because of the state issues involved in lightning.
>
> When I was at Verisign, we figured a 100g link was enough to block any sort 
> of DDoS against the DNS root servers. The attack against Krebs shows just how 
> silly this line of thinking is today.
>
> There is no perfect defense, but it might be useful to think about these 
> things, and how to solve them, now, rather than once they happen, 
> particularly when the trust of the overall network is in play. This might 
> mean several things, such as --
>
> - The closer you can come to stateless on the server side during session 
> setup, before you know the request is going to be followed through/is 
> legitimate, the less chance this sort of thing will happen
> - The more you have the ability to shift a transaction from one server to 
> another without losing some essential state, the more a network of devices 
> can be designed to handle such problems
>
> There may be other solutions, as well; just throwing some ideas out there.
>
>  /r___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[7riw77]

> 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 the following situation: Someone has gotten a "bum deal" on their 
pizza (or thinks they have), and they want to take down their pizza provider. 
They note the lightning node the pizza provider uses happens to be some 
particular address, so they hire out a 10k node botnet (rather small in the 
real world), and ask each bot to open as many transactions as possible, as fast 
as possible, without completing any of them, with the ip address of the node in 
question. The server eventually says "I'm not accepting any more connections, 
because I have too many outstanding connections right now," which effectively 
takes it off line for new transactions, blocking anyone who uses that node from 
any sort of transaction. How long can this last? So long as the botnet 
continues asking for new connections. 

There are ways around this on the network side -- specifically using anycast, 
like DNS does, to spread the attack around -- but I'm not certain anycast would 
work in this case because of the state issues involved in lightning. 

When I was at Verisign, we figured a 100g link was enough to block any sort of 
DDoS against the DNS root servers. The attack against Krebs shows just how 
silly this line of thinking is today. 

There is no perfect defense, but it might be useful to think about these 
things, and how to solve them, now, rather than once they happen, particularly 
when the trust of the overall network is in play. This might mean several 
things, such as --

1. The closer you can come to stateless on the server side during session 
setup, before you know the request is going to be followed through/is 
legitimate, the less chance this sort of thing will happen
2. The more you have the ability to shift a transaction from one server to 
another without losing some essential state, the more a network of devices can 
be designed to handle such problems

There may be other solutions, as well; just throwing some ideas out there.

 /r 


___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 *distributed* denial 
of service.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
On January 18, 2018 7:03 PM, <7ri...@gmail.com> wrote:

>
>
>> You impose this 25 channels per peer. I start opening a channel to
>> you. Because I did not check mempool or because my fee-estimation algo is
>> bad, I pay too low a fee. I become impatient and bump it up, which you
>> perceive as another open (so it is now 2/25 channels).
>
> It seems, to me, that this example could be pretty easily extended to 1000, 
> or 2000, or -- pretty much anything. In fact, this brings up an important'ish 
> point, possibly. If every channel I "try to open," and then fail to, counts 
> as resources of any kind on the receiver, we've just added a perfect attack 
> surface for a denial of service. However this is arranged, it needs to be 
> arranged in a way that does not have (or at least has a minimal number of) 
> fixed pool of resources/magic numbers of any kind that can be exhausted, 
> after which things "no longer work." To do otherwise is to practically invite 
> someone taking the entire network down with a well-planned/executed process 
> that exhausts this resource across a large number of critical nodes (and 
> there will be critical nodes -- it's just a part of graph theory that this 
> will happen).
>
>  /r___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Matt Corallo]

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 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?
>
>You impose this 25 channels per peer.  I start opening a channel to
>you.  Because I did not check mempool or because my fee-estimation algo
>is bad, I pay too low a fee.  I become impatient and bump it up, which
>you perceive as another open (so it is now 2/25 channels). 
>Unfortunately I only bumped my fee by a tiny amount, because reasons. 
>I bump the fees upwards for example five more times, each of which you
>perceive as another channel open, so from your side it looks like I am
>consuming 7/25 channels.  Finally the funding transaction confirms, but
>the 6 previous transactions are perceived by you as unconfirmed channel
>opens, so you will still keep the 6 channels accounted in your
>25-channel-limit.
>
>Suppose in a few days (i.e. much less than a week) I decide to have
>three more channels to you.  If I go through all that (starting with
>low fee, bumping up fee, etc) then I may very well run out of the
>available 25 channels to you, even though I only really have 1 channel
>already opened and am trying to make an additional 3 channels only.
>
>Granted this is somewhat contrived, but it shows what I wish to avoid
>with `funding_cancelled`.
>
>Regards,
>ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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 missing?

You impose this 25 channels per peer.  I start opening a channel to you.  
Because I did not check mempool or because my fee-estimation algo is bad, I pay 
too low a fee.  I become impatient and bump it up, which you perceive as 
another open (so it is now 2/25 channels).  Unfortunately I only bumped my fee 
by a tiny amount, because reasons.  I bump the fees upwards for example five 
more times, each of which you perceive as another channel open, so from your 
side it looks like I am consuming 7/25 channels.  Finally the funding 
transaction confirms, but the 6 previous transactions are perceived by you as 
unconfirmed channel opens, so you will still keep the 6 channels accounted in 
your 25-channel-limit.

Suppose in a few days (i.e. much less than a week) I decide to have three more 
channels to you.  If I go through all that (starting with low fee, bumping up 
fee, etc) then I may very well run out of the available 25 channels to you, 
even though I only really have 1 channel already opened and am trying to make 
an additional 3 channels only.

Granted this is somewhat contrived, but it shows what I wish to avoid with 
`funding_cancelled`.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[ZmnSCPxj via Lightning-dev]

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

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

[Pierre]

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 trustlessly would be for the funder to attach the actual
deprecated funding tx (not necessarily signed, but still could be big)
to the `funding_cancelled` message, then the fundee would be able to
verify that its inputs have indeed been spent by the overriding tx.

Cheers,

Pierre
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Matt Corallo]

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 and 
misimplementation.

On January 8, 2018 3:26:23 AM UTC, ZmnSCPxj via Lightning-dev 
 wrote:
>Good morning Lightning world,
>
>https://github.com/lightningnetwork/lightning-rfc/pull/349
>
>I propose in the above pull request a new `funding_cancelled` message
>intended to inform the fundee node that the funder node is definitely
>sure that the channel funding transaction can never confirm.
>
>This thread is intended to open a discussion for this proposed message,
>to be added to v1.1 spec.
>
>The reason for including this message is the below:
>
>1.  Implementing this message should not be onerous, if the node
>software already implements code to forget the channel after a timeout.
>We simply trigger this code if the channel funding transaction times
>out or if this message is received.
>2.  It allows replace-by-fee funding transactions. To replace an RBF
>funding transaction, the funder simply re-initiates the opening
>protocol from `open_channel` -> `acccept_channel` -> `funding_created`
>-> `funding_signed`, then broadcasts the replacement funding
>transaction.  Then both funder and fundee wait for either the old or
>the new funding transaction to confirm (miners might reject
>replacements, or the new funding transactions might simply not have
>propagated to the miner at the time of mining a new block), and once
>one of the transactions is confirmed deeply enough, the funder cancels
>the other funding transaction via `funding_cancelled`.
>3.  It allows multi-channel funding transactions.  To fund multiple
>channels from a single transaction, the funder initiates the opening
>protocol to each node separately.  However, the funder must not
>boradcast the funding transaction until all fundees reply
>`funding_signed`.  If some fundees complete the protocol up to
>`funding_signed` but some fundees time out or fail/cannot contact, then
>the funder cannot safely broadcast the funding transaction at all. The
>funder node can then send `funding_cancelled` to each fundee that
>completed up to `funding_signed` to free resources of those nodes.
>
>In principle the message is unnecessary if funding timeout is
>implemented by the fundee node. However, this message lets the funder
>node free up resources on the fundee node.
>
>Admittedly, implementing RBF funding transactions and multi-channel
>funding transactions is more involved than implementing
>`funding_cancelled`,
>
>Regards,
>ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev