The LSP last-mile problem is basically the problem of dynamically changing liquidity allocations to edge clients. Predicting the future, and correctly predicting which of the clients will actually utilize (ie pay for) liquidity is difficult, and if you make a mistake and overallocate liquidity to one client while underallocating to another, extra onchain fees must be paid to transfer the liquidity. This is true even if you transfer the decisionmaking and fees directly to the client; a client will prefer an LSP that does this...
prediction correctly on their behalf.
Splicing helps in that it is a cut-through of a channel close with a channel open of a different liquidity allocation, but what is even better than an efficient onchain tx? NO onchain tx!
Better if we could build trustless...
...mechanisms to allow an LSP to reallocate liquidity without onchain activity, or at least to aggregate multiple liquidity changes in one onchain action. Predicting the future is HARD, and there will always be a need to dynamically correct mistaken liquidity predictions,...
.the point is to make it more efficient.
Another nice-to-have is to allow liquidity reallocations even if a client is offline, while reducing onchain footprint. Proposals to do this, like Ark and BitVM bridges, tend to require additional capital locked up, but...
again: the point is to utilize the capital EFFICIENTLY, so a solution that requires MORE capital is no better than just overprovisioning capital at each client anyway, and the latter is done more simply with existing well-tested LN node implementations.
So we need some novel protocol that combines:
- unilateral exit to ensure LSPs are kept honest. QUIS CUSTODIET IPSOS CUSTODES?
- allows liquidity reallocation: 2.1. without requiring every client to have high uptime (v hard) 2.2. with little or no onchain activity
- With little or no extra capital allocated to the protocol (v hard with low uptime clients)
Do I have a solution? No. Sorry. But basically this is what we need to scale LN further.
Like if you can drop the low-uptime-client requirements, just do channel factories. We can do Decker-Wattenhofer for the factory layer with Poon-Dryja for the channels, Decker-Wattenhofer works even if Bitcoin ossifies but it needs either large numbers of anchor outputs...
...times large number of nested constructs for extra-large unilateral exits, or fixed onchain fees that are simultaneously too expensive AND too cheap for maximum tears. But if you want low-uptime-clients, that cannot be used, either.