Good morning laolu,
Thank you for your hard work!
Is there a documentation for the client/server intercommunications protocol?
How stable is this protocol?
A thought occurs to me:
* The payment of the lease effectively shifts risk from established forwarding
nodes to those purchasing incoming liquidity (i.e. new forwarding nodes, and
merchants).
* The merchant/new forwarding node speculatively pays for the incoming
channel lease, in the hope that it will recoup the loss in the future.
There exists the risk that it cannot actually utilize the incoming capacity
it purchased.
* I believe this improves risk-sharing and improves the system health overall.
A random, possibly-dumb idea is that a leased channel should charge 0 fees
initially.
Or, to be more specific:
* The advertisement for the channel lease should include a channel feerate.
* At channel setup the *published* channel feerate should be 0.
* Both participants keep track of how much "should" have been paid in fee
using the agreed-upon lease feerate.
* Once the "should" fee matches the original lease cost, the lessor is now
free to set the channel feerate to nonzero.
Enforcing that is a problem, however, since channel updates are unilateral, and
of course the lessee cannot afford to close the channel it leased in case the
lessor sets a nonzero feerate ahead of time.
This effectively makes the lease rate (cost per unit time per
satoshi-in-channel) reflect the expected low-risk rate of return, which may be
useful for market discovery.
Secondarily to the Shadowchain discussion, it should be noted that if all
onchain UTXOs were signed with n-of-n, there would not be a need for a fixed
orchestrator; all n participants would cooperatively act as an orchestrator.
On the other hand, that requires cooperation (a single non-cooperating party is
enough to disrupt the entire construction and require expensive onchain
resolution), as well as a broadcast medium, and the simplest implementation of
a broadcast medium over IP is to elect a participant to receive all messages
and broadcast all the messages to the other participants, which is basically
what the orchestrator is **also** doing.
Thus the tradeoff may be acceptable.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
