Good morning Robert,
> 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
But what is the state before and the state after of channel D-C? Have you
considered?
I postulate that in any case where rebalancing is possible, then a payment
route exists that is sufficient for payment to the network, and in the end, the
purpose of LN is payment, not some ideal of channel balance. This idea is a
consequence of studying what I call "cyclic superhubs" where cycles of channels
start with each channel consistently unbalanced in one direction and yet every
node on that cycle is capable of paying to every other node on that cycle
without need of explicit rebalancing. Hence my reluctance to consider the
addition of rebalancing at all.
I think dynamic fee changing (lowering and increasing fees for channel
directions you wish to rebalance away/towards you) is sufficient, and requires
no update to the base LN protocol (but requires updating of actual
implementations, since they all use fixed fees).
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
