From stan.kladko at galacticexchange.io Thu Dec 14 15:09:05 2017 From: stan.kladko at galacticexchange.io (Stan Kladko) Date: Thu, 14 Dec 2017 17:09:05 +0200 Subject: [Lightning-dev] Peer Selection In-Reply-To: References: Message-ID: I see, thank you for the explanation. Now I understand, so if my node is down and I received payments, I may lose some of my received payments. But if I route and someone routed large amounts of money through me, and then my node is down, then may lose these payments too. Basically, if I am routing, then if my node crashes, I may be liable for some of the routed funds, in addition losing some of the funds I received . So from the safety perspective there are three stages of risk a) send only b) send and receive c) send and receive and route On Thu, Dec 14, 2017 at 5:11 AM, ZmnSCPxj wrote: > Good morning Stan, > > Money is safe when network is down only if you only pay out of your node. > Once you receive, it is possible for your counterparty to transmit an > invalid old state where it owns more money than you do. Then you need to > monitor the blockchain for invalid closings of channel state, meaning you > cannot be offline for more than a few days (this timeout is settable in your > node). > > Basically, consider the below situation: > > You make a channel to me and load it with 3mBTC. You force the channel to > be unidirectional, because you might be offline for months. > > Stan: 3mBTC, ZmnSCPxj: 0mBTC Initial state > Stan: 2mBTC, ZmnSCPxj: 1mBTC after you pay me 1 mBTC > Stan: 1mBTC, ZmnSCPxj: 2mBTC after you pay me 1 mBTC > > Now suppose you decide to accept money via this channel. So the channel > history now becomes: > > Stan: 2mBTC, ZmnSCPxj: 1mBTC after I pay you 1 mBTC > Stan: 3mBTC, ZmnSCPxj: 0mBTC after I pay you 1 mBTC > > At this point, I can take back my 2mBTC by replaying the old "Stan: 1mBTC, > ZmnSCPxj: 2mBTC" state. Normally, this is a bad move on my part, since old > state is revoked and you can present evidence of fraud on the blockchain > layer to take the entire channel value as yours, as damages. However, you > only have a few days where you can present this evidence. If those few days > pass, then the payment is finalized and I get back the 2 mBTC I paid to you. > > The upshot is that if you receive money for any reason (whether for routing, > or because you are the final payee) you can only be offline for at most a > few days. Otherwise, you force yourself into unidirectional mode only (you > can only pay, never receive): unidirectional mode also is bad for you since > you cannot offset the fees you pay for spending using fees you receive for > routing. > > If you are going to receive money anyway, you might as well enable routing > also, because that lets you earn some fees (to offset the fees you would pay > to spend your money). The added risk is low: most routes will either > successfully reach the destination, or fail outright, within a few seconds, > freeing the funds back to you again. > > The protocol has two settings "max_htlc_value_in_flight_msat" and > "max_accepted_htlcs" to limit your exposure to routing risk. These limit > how much of your channel funds can be spent on routing > (max_htlc_value_in_flight_msat) and the number of routes at a time that > should be used on that channel (max_accepted_htlcs). If those limits would > be violated by a route attempting to go to you, the route simply fails and > the payer will have to find another route. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > -------- Original Message -------- > Subject: Re: [Lightning-dev] Peer Selection > Local Time: December 14, 2017 12:10 AM > UTC Time: December 13, 2017 4:10 PM > From: stan.kladko at galacticexchange.io > To: ZmnSCPxj > lightning-dev at lists.linuxfoundation.org > > > Thank you - this is lots of information !) > You would also have to make your outgoing channels private (not sent by node > gossip) so that others will not route through you. > > If I would have only a single outgoing channel I would not have to > make it private ? Correct? There is no way to route through a node > that has one channel. > > Another interesting question is what happens if I have lots of > channels, but in my software block all routing through my node? > > Is there a way for me to block all routing through my node by > modifying node software but still enjoy all benefits of receiving and > sending deposits? > > As you said, blocking all routing has lots of benefit since money is > safe if the network is down :-) > > Sorry for playing devils advocate - I am just trying to understand it ) > > > > On Wed, Dec 13, 2017 at 3:13 PM, ZmnSCPxj ZmnSCPxj at protonmail.com wrote: > Good morning, > If you have a reason to open a channel to an arbitrary node, then other > nodes have a reason to open a channel to an arbitrary node, which might be > you. Even if the > network grows large, that > also means there are more participants who > might decide, via whatever heuristic, to channel to your node. > If I am connected to some nodes, but no one connected to me, then all > of my deposit is used by me only, and is not used by other nodes. > If I am routing nodes through my node, then it can potentially > negatively affect availability of my deposit for my own transactions. > So it seems to me that the best strategy is to connect but accept no > incoming connections. > How much real is this problem? > You would also have to make your outgoing channels private (not sent by node > gossip) so that others will not route through you. You will not be able to > receive money on-Lightning (since your channels are private, people who are > trying to send money to you on-Lightning will not be able to find a route to > you). You will not earn any money from routing fees (since you are not > willing to have others use your channels for routing). > It has the advantage that you can actually lose Internet connectivity > indefinitely with no possibility of loss of funds, simply because in this > mode of operation, channels are effectively unidirectional only from you to > the rest of the network. > However, I think in the long run, you would prefer to receive funds by > Lightning also, and so cannot use this kind of operation. Consider that in > the future, you may get paid your salary or dividends in bitcoin over > Lightning: your business/employer receives money from its customer over > Lightning, it sends part of that money to sub-contractors and suppliers, and > some to you (employee or shareholder). You then spend the money you receive > as salary/dividends for food and services and other vices you might have, > which are provided by other businesses which have their own shareholders, > employees, sub-contractors, and suppliers. > In such a world, you would have to make your channels public and accept > incoming channels, and at minimum accept incoming money (even if you reject > routing attempts). Since routing can earn you some amount of money as fees, > you probably want to accept at least a few routing attempts at a time to > earn some fees (and offset the fees on your own transactions). This also > leads to a more mesh-like network; the "unidirectional mode" where you keep > all your channels private and only outgoing effectively makes you a > second-class member of the network (and has higher onchain fees: if you have > depleted a channel, there is an incentive to keep it open only if you are > willing to accept routing attempts through you (every open channel is an > opportunity to route, and a channel depleted on your end is full on the > opposite end and you can still at least accept transactions toward you), > otherwise, you are better off closing channels (and incurring fees) so you > can recover the channel reserve). > Regards, > ZmnSCPxj