Stan Kladko [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-14 📝 Original message: I see, thank you for the ...

📅 Original date posted:2017-12-14
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 <ZmnSCPxj at protonmail.com>
> lightning-dev at lists.linuxfoundation.org
> <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