[Lightning-dev] Rebalancing argument

Tue Jul 3 19:33:22 UTC 2018

Dmytro wrote:
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system?

That's a good question, it may be the case that by modifying the fee
structure to punish flows that unbalance channels further, then this can
simplify the problem as the heuristics can target solely the fee rate. The
earliest suggestion of this I can recall was from Tadge way back in like
2015 or so. The goal here is for a node to ideally maintain relatively
balanced channels, but then charge a payment an amount that scales super
linearly when flows consume most of their available balance.

The current fee schedule is essentially:

  base_fee + amt*rate

clighting and lnd (borrowed from c-lightning) currently use a "risk factor"
to factor in the impact of the time lock on the "weight" of an edge when
path finding. With this, the fee schedule looks like:

  (base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,0000)

In the future, we may want to allow nodes to also signal how they wish the
fee to scale with the absolute CLTV of the HTLC extend to this. This would
allow them to more naturally factor in their conception of the time value of
their BTC.

Finally, if we factor in an "balance disruption" factor, the fee schedule
may look something like this:

  (base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,0000) +
  gamma*f(capacity, amt)

Here f is a function whose output is proportional to the distance the
payment flow (assuming full capacity at that instance) puts the channel away
from being fully balanced, and gamma is a coefficient that allows nodes to
express the degree of penalty for unbalancing a channel. f itself is either
agreed upon by the network completely, or resembles a certain polynomial,
allowing nodes to select coefficients as they wish.

We may want to consider moving to something like this for BOLT 1.x+ as it
allows nodes to quantify their apprehension to time locks and also
channel balance equilibrium affinity.

Alternatively, if we move to something like HORNET, then during the set up
phase, nodes can ask for an initial "quote" for a set of payment ranges,
then just use that quote for all payments sent. This allows nodes to keep
their fee schedules private (for w/e reason) and also change them at a whim
if they wish.

-- Laolu

On Sun, Jul 1, 2018 at 8:39 AM Dmytro Piatkivskyi <
dmytro.piatkivskyi at ntnu.no> wrote:

> Hi Rene,
>
> Thanks for your answer!
>
> 1. The Lightning network operates under different assumptions, that is
> true. However, the difference is minor in terms of the issue posed. The
> premise for the quoted statement is that taking fees changes the nodes’
> balances, therefore selected paths affect the liquidity. In the Lightning
> network fees are very small, so the change in liquidity may be negligible.
> Moreover, intermediate nodes gain in fees, which only increases the
> liquidity.
>
> 2.A. It is too early to speculate where the privacy requirements will
> settle down. Flare suggests a mechanism of sharing the infrastructure view
> between nodes, possibly sharing weights. As the network grows routing will
> become more difficult, however we don’t know yet to which extent. It may
> organise itself in ‘domains’, so when we send a payment we know to which
> domain we are sending to, knowing the path to it beforehand. The point is
> we don’t know yet, so we can’t speculate.
>
> 2.B. That is surely an interesting aspect. HTLC locks
> temporarily downgrade the network liquidity. Now the question is how it
> changes the order of transactions and how that order change affects the
> transaction feasibility. Does it render some transactions infeasible or
> just defers them? It definitely needs a closer look.
>
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system? In any sense. Path lengths,
> for example. To answer that I am going to run a simulation, but also would
> appreciate your opinions.
>
> Best,
> Dmytro
>
> From: René Pickhardt <r.pickhardt at googlemail.com>
> Date: Sunday, 1 July 2018 at 13:59
> To: Dmytro Piatkivskyi <dmytro.piatkivskyi at ntnu.no>
> Cc: lightning-dev <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Rebalancing argument
>
> Hey Dmytro,
>
> thank your for your solid input to the discussion. I think we need to
> consider that the setting in the lightning network is not exactly
> comparable to the one described in the 2010 paper.
>
> 1st: the paper states in section 5.2: "It appears that a mathematical
> analysis of a transaction routing model where intermediate nodes charged a
> routing fee would require an entirely new approach since it would
> invalidate the cycle-reachability relation that forms the basis of our
> results."
> Since we have routing fees in the lightning network to my understanding
> the theorem and lemma you quoted in your medium post won't hold.
>
> 2nd: Even if we neglect the routing fees and assume the theorem still
> holds true we have two conditions that make the problem way more dynamic:
>  A) In the lightning network we do not know the weights of the directed
> edges. (only the sum of two opposing edges) So while theoretically the flow
> in the network will only depend on the liquidity of the nodes I guess in
> practice well balanced channels will increase the probability to actually
> find a working route.
> B) I believe the HTLCs create a situation where funds are being locked up
> while routing takes place and thus have an impact to the entire flow of the
> network. While Alice searches for a route for her payment a proper route
> could be blocked do to the fact that Bob is using it currently. Since the
> funds of Bob have not arrived Alice might also not be able to find a
> different route.
>
> However those scientific results are a strong call for Atomic Multipath
> Payments. I personally think they are also a strong call for splicing since
> this allows to easilly increase the flow of the network by updating a
> channel (athough you might argue that following the paper this could be
> achieved by just creating a new channel)
>
> best Rene
>
> On Sun, Jul 1, 2018 at 12:21 PM Dmytro Piatkivskyi <
> dmytro.piatkivskyi at ntnu.no> wrote:
>
>> Hi everyone,
>>
>> I have been working academically on the Lightning network for a while
>> now. I didn’t not participate in the list to form my own vision of what it
>> should be. So please, bear with me if I’ll be saying nonsense sometimes.
>>
>> There has been a lot of discussion on sending cycle transactions to
>> oneself to ‘re-balance’ the network. On LN mailing list
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html> [1] or
>> numerous places elsewhere. There has been even a paper suggesting a smart
>> mechanism to do the re-balancing (see Revive or Liquidity network [2]). My
>> question is what do we actually get from it? [3] states that the
>> distribution of funds in channels does not really affect the network
>> liquidity. I can see cheaper fees or shorter paths if the network is kept
>> balanced. But don’t you think that a smart fee strategy will do the job?
>>
>> To save your time, [4] explains the gist from [3].
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
>> [2]
>> https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
>> [3] https://arxiv.org/abs/1007.0515
>> [4]
>> https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> www.rene-pickhardt.de
> <http://www.beijing-china-blog.com/>
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618 <+49%20176%2057623618>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180703/d412a8b5/attachment.html>