Good Morning ZmnSCPxj!
I was thinking using the normal onion-routing, probably modified in some
way so it can read and modify max. Must admit I haven't studied that part
at that level at all.
For simple three-member constructs it could be enough with a simple
non-onion message that A asks B if it would like to rebalance AB,BC and A
asks C if it would like to balance BC,CA.
But first it seems I have to at least try to convince you that rebalancing
does help solve some problems.
I think rebalancing is good for many reasons.
Consider a node A that has the following channel balances. It initiated A-B
with 100sat and used that up instantly. C initiated an inbound channel of
200sat. A made a new channel A-D with 300sat
It ended up looking like the following:
A-B 0-100
A-C 0-200
A-D 300-0
For simplicity in this case the total balance is 300-300. Also lets say
"balanced" means "able to send and receive 25 sat". Achieving total balance
on all channels is not realistic. It's up to each node to decide their own
definition.
A has only one channel to send out via. If D goes down it has even fewer.
So my idea is: A finds if there exists any D-C channel (or multi-hop), and
politely asks whomever it may concern if sending 100 sat A->D->C->A would
benefit them as well. if it does you send over 100 sat and will end up with
A-B 0-100
A-C 100-100
A-D 200-100
If the agreed max along the path is lower, it will have to do, it helped a
little bit, but lets say 100sat was ok with everyone
Repeat for A->D->B->A and 50sat and you will have
A-B 50-50
A-C 100-100
A-D 150-150
Now A instantly have 3 times as many possible routes out, and 50% more
possible routes in, nobody had to go to the chain to close/open/splice, and
nobodys channel went unbalanced, and nobody paid anyone.
The possibilites for others in the network to actually route via A
increases to all 6 paths from 2, before only B->A->D and C->A->D would
succeed. So there is also a 3-fold increase.
Consider a bigger node with say 40 channels where 10 has too low local
balance and 30 has too low remote balance. It would have 300 working paths
out of 1560, so about 80% failure rate.
So, for redundancy and maximum possible routes, I think rebalancing is good.
The main difference with this protocol compared to how we balance lightning
channels today is
* that everyone benefits from it (or else would deny to be a part of it) so
there are not any fees
* today channel balances sometimes start oscillating if two nodes try to
balance a channel somewhere in the network according to their own will,
without caring/knowing about the intermediates wishes or eachothers. now we
care.
* less trial and error since you know the perfect amount to send
---
In the case you describe, it is a feature, not a bug.
If you find a path A->B->C->D
C would like to balance BC against CD so it offers a rebalance and accepts
fee-free transactions for things coming in BC and goes out CD. But maybe DB
channel doesn't exist or have too little capacity.
It's wishes to rebalance the channel remains. Then suddenly your payment
goes thru and achieves the same goal, I don't see a problem.
if C did *not* want to balance in that direction, it would have rejected
passing the payment for free
if two payments pass thru the same channels, the second one will be
rejected as normal with "feeinsufficient"
If we do want to avoid this (maybe because too many flood the network
probing to find a free hop), you can send the future payment hash, or part
of it, in the proposal message, and whitelist that hash for 1337 seconds.
Even if whitelisted, when/if the payment packet arrives, the node shall
check in channel and amount to see if it is still beneficial, otherwise
just reject it. The agreed max is a soft promise.
Regarding receive-only or send-only nodes and on/off swapping, I think
those are entirely separate problems. My solution only aims at spreading
the existing grease around the layer two for smoother operation.
Best Regards
Robert Olsson
On Mon, Aug 13, 2018 at 1:16 PM, ZmnSCPxj wrote:
> 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
