Good morning laolu, Sorry for the late reply.
> > 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". On the one hand, one possible use-case for this would be for a new forwarding node to come online. As forwarding nodes must first *receive* a forwarding request before they can actually forward, incoming capacity is necessary as well in such a deployment. But restricting forwards as you propose would make this exercise pointless, at least for forwarding nodes; to a forwarding node, getting forwards *is* the intended model and restricting those would just reduce its potential earnings. Now, in rebalancing away the incoming capacity, the channel lessor not only pays to the lessee the forwarding fee, but as well, also creates incoming capacity on *another* channel of the lessee. If the lessee is a forwarding node, then it has still achieved what it wants, that is, it retains incoming capacity still. Even if the lessee is primarily a receiving merchant, if the lessor is able to successfully rebalance at all, then, again, *some* incoming capacity will appear on a different channel of the lessee. So this is only really problematic if we are giving some kind of feerate assurance, since the incoming capacity never really disappears (unless the lessor actively overpays the forwarding fee to the lessee, and such an outright gift is likely more valuable than purchasing more incoming capacity), it just moves elsewhere. It *could* move to a channel where reaching the lessee costs more for most nodes on the network, so I believe this is potentially an actual loss. In a sense, a rebalance is an aggregation of multiple smaller payments. Suppose I am a forwarding node that is lucky enough to be channeled to a popular merchant. The channel to the merchant gets a lot of little payments and eventually saturates. If I have funds elsewhere, I can aggregate those multiple smaller payments into a single large payment from one of my other channels, and transfer to the popular channel to the popular node, so that more smaller payments can come into my channel with the popular merchant. So I think rebalancing is good for the network in general, and should be supported well. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
