Good morning Robert,
I assume, this functionality is transported also via the same
onion-routing-packet style that current payment routing uses?
If so, then it seems this feature can be used by a payer and payee to
coordinate to locate some route that would, if paid normally, charge fees, but
if using the "free rebalancing" could be made free. The payer simply locates
some route, adds a synthetic initial balance that is much higher than the
payment to be forwarded, and then request for a "free rebalancing" from the
payer to the payee. If at the payee node, the resulting "max" is greater than
the actual payment being sent, then the payer and payee have found a fee-free
route between them.
After all, since the functionality is transported by onion-routing-packet, then
intermediate hop routes cannot know that the ultimate source and ultimate
destination are different nodes.
Note that intermediate nodes cannot detect this at all. A fee-free rebalance
request that follows the fee-free rebalance query may be lower than the max it
forwarded, since, a later intermediate node on the route might have lowered the
maximum already.
--
For myself, I think rebalancing is not a particular good solution to anything
(similar to splice).
Imagine a simple 3-member cyclic-superhub network composed of A -> B -> C
(looping back to -> A). Node A may pay node C via B, and so on. Now if C is a
popular merchant for both B and A, then both the B-C and C-A channels will
saturate in favor of C. In such a case, no rebalancing is possible.
A better solution is for C to purchase more incoming balance by asking either
of B or A to transfer onchain funds in exchange for a preimage (i.e. swap
offchain funds for onchain funds). This is effectively "batching" the earnings
that C gains in LN: C might earn a lot of small amounts, each one too small
individually to justify onchain transfers, but which batched together can
justify the onchain transfer. Further, this batching is noncustodial and C can
close the channel at any time (incurring an onchain fee), unlike current
payment processors (PayPal, credit cards) where payment batching is custodial
and may be frozen by the custodian; on LN, at worst the money will be locked
for a few days or weeks, but will definitely be returned to you as long as you
did not actually cheat.
Further this swapping can be done on a separate layer/software that interacts
with ordinary existing LN software without requiring additional changes at the
LN protocol level, which is always a good thing: I believe we should prefer to
make LN a layer that supports further layers, not put every possible feature
into LN.
This off-to-on and on-to-off swapping solves the same problems that both
rebalancing and splcing do (channel balancing, incoming channels, channel
reloading) without requiring changes at the LN layer, merely adding an
application on top of LN.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 12, 2018 7:31 AM, Robert Olsson <[email protected]> wrote:
> Dear All,
>
> I'd like to suggest a new function in the network, "Free Rebalancing
> Proposals"
> It is a fee-less, omni-beneficial rebalancing scheme
>
> Background:
>
> I currently balance my nodes in the following way, extremely simplified:
>
> 1) Identify channels that have too low remote_balance (A) and too low
> local_balance (B) for being of any use (in that direction)
> 2) Find potential routes and amounts between all channels A and all channels
> B that would optimize at least one of them
> 3) Send a payment along those possible routes for different amounts, sorted
> after fee, until one succeeds
>
> It works quite good and is quite straight forward until the third step. So I
> would like to propose a better solution which works like this:
>
> Send a proposal-for-balancing-message over channel A, and the max amount you
> would propose to balance in that direction.
>
> Each node analyses the in and out channels and adjusts the max to it's own
> desire to balance. Max can only be adjusted down. Let's say the function is
> `int freeBalancerMax(channel in,channel out)`. It could be as simple as
> checking how near "in" is to 100ksat local_balance and "out" is to 100ksat
> remote_balance. The node passes that message with new max value on to the
> next node, much like a normal payment.
>
> When this packet comes back to the origin it will know how much the
> intermediate nodes are willing to let you balance, or if someone is reluctant
> to balance (and the final max value would be 0)
>
> If everyone is happy (i.e. max>0), the origin node sends a payment along this
> node, *without* dropping off any fees along the way, since all nodes agreed
> and benefit from the rebalancing act.
>
> Since all intermediate nodes benefit they are happy to do this without fees.
> Since they adjust max values to their desire it will stop multiple attempts
> from different nodes from starting to oscillate the balances in the channels,
> but will instead reach some kind of equilibrium as long as the node
> suggesting proposal uses it's freeBalancerMax when proposing and accepting
> proposals.
>
> The intermediate nodes might not need to keep track of any agreements to
> balancing proposals, it can simply call the freeBalancerMax function, and if
> the payment is lower, it passes on the payment even if it didn't get any
> fees, otherwise it fails as usual. If someone tries to send a non agreed
> payment without fees, but it coincides with the nodes own desire to
> rebalance, there is no harm done. Only problem with that is that senders
> might flood a path with creative attempts trying to find a path with a
> fee-free hop. I think things like that will be stopped by a general throttle
> functionality which probably will be needed anyhow.
>
> Best regards
> Robert Olsson
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
