Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-06 📝 Original message: Hi Z, Thanks for such ...
📅 Original date posted:2020-11-06
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201105/d927920d/attachment.html>;
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201105/d927920d/attachment.html>;