ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-05 📝 Original message: Good morning laolu, Thank ...
📅 Original date posted:2020-11-05
📝 Original message:
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
📝 Original message:
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