From laolu32 at gmail.com Fri Nov 6 02:53:09 2020 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Thu, 5 Nov 2020 18:53:09 -0800 Subject: [Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace In-Reply-To: References: Message-ID: Hi Z, Thanks for such kind words! > Is there a documentation for the client/server intercommunications > protocol? Long form documentation on the client/server protocol hasn't yet been written. However, just like Loop, the Pool client uses a fully-featured gRPC protocol to communicate with the server. The set of protobufs describing the current client <-> server protocol can be found here [1]. > How stable is this protocol? I'd say it isn't yet to be considered "stable". We've branded the current release as an "alpha" release, as we want to leave open the possibility of breaking changes in the API itself (in addition to the usual disclaimers), though it's also possible to use proper upgrade mechanisms to never really _have_ to break the current protocol as is. > A random, possibly-dumb idea is that a leased channel should charge 0 fees initially. > 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. Agreed that the purchaser of a lease should be able to also receive a fee rate guarantee along with the channel lifetime enforcement. As you point out, in order to be able to express something like this, the protocol may need to be extended to allow nodes to advertise certain pair-wise channel updates, that are only valid if _both_ sides sign off on each other's advertisements, similar to the initial announcement signatures message. On lookers in the network would possibly be able to recognize these new modified channel update requirements via interpreting the bits in the channel announcement itself, which requires both sides cooperating to produce. It's also possible to dictate in the order of the channel lease itself that the channel be unadvertised, though I know how you feel about unadvertised channels :). In the context of Lighting Pool itself, the employed node rating system can be used to protect lease buyers from nodes that ramp up their fees after selling a lease, using a punitive mechanism. From the PoV of the incentives though, they should find the "smoothed" out revenue attractive enough to set reasonable fees within sold channel leases. One other thing that the purchaser of a lease needs to consider is effective utilization of the leased capital. As an example, they should ensure they're able to fully utilize the purchased bandwidth by using "htlc acceptor" type hooks to disallow forward through the channel (as they could be used to rebalance away the funds) to clamp down on "lease leak". I plan to significantly extend the current "security analysis" section to cover these aspects as well as some other considerations w.r.t the interaction of Lifted UTXOs timeouts and batch confirmation/proposal in the context of Shadowchains. There'll also eventually be a more fleshed out implementation section once we ship some features like adding additional duration buckets. The git repo of the LaTeX itself (which is embedded in the rendered PDF) can be found here [2]. > 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. This is correct, and as you point out moving to an n-of-n structure between all participants runs into a number of scalability/coordination/availability issues. The existence of the orchestrator also serves to reduce the availability requirements of the participants, as the only need to be online to accept/validate a shadowchain block that contains any of its lifted UTXOs. With an addition of a merkle-tree/MMR/SMT over all chain state that's committed to in each block (say P2CH-style within the orchestrator's output), an offline participant would still be able to "fully validate" all operations that happened while they were away. This structure could also be used to allow _new_ participants to audit the past history of the chain as well, and can also be used to _authenticate_ lease rate data in the context of CLM/Pool (so an authenticated+verifiable price feed of sorts). In the context of the Pool shadowchain, the existence of the orchestrator allows the participants to make other tradeoffs given it's slightly elevated signing position. Consider that it may be "safe" for participants to instantly (zero conf chans) start using any channels created via a lease as double spending the channel output itself requires coordination of _all_ the participants as well as the orchestrator as all accounts are time lock encumbered. Examining the dynamic more closely: as the auctioneer's account in the context of Pool/CLM isn't encumbered, then they'd be the only one able to spend their output unilaterally. However, they have an incentive to not do so as they'd forfeit any paid execution fees in the chain. If we want to strengthen the incentives to make "safe zero conf channel lease usage" work, then an on-chain bond can be created that's threaded through with each execution auction batch. The auctioneer would then be required to sign its account output with a "single show signature" allowing some/all the participants of the Pool to collect a security deposit as the auctioneer violated the zero conf agreement. [1]: https://github.com/lightninglabs/pool/blob/master/poolrpc/auctioneer.proto [2]: https://github.com/lightninglabs/pool-paper -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: