Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning t-bast, > > An issue with the bidirectional upfront/hold fees is related to trustless > > offchain-to-onchain swaps, like Boltz and Lightning Loop. > > As the claiming of the offchain side is dependent on claiming of the > > onchain side of the trustless swap mechanism, which is *definitely* slow, > > the swap service will in general be forced to pay up the hold fees. > > Yes, that is a good observation. > But shouldn't the swap service take that into account in the fee it collects > to > perform the swap? That way it is in fact the user who pays for that fee. The user can wait for the swap service to put an onchain HTLC and then time it out. Thus, the offchain/onchain swap service will pay for both the onchain HTLC and the hold fee. This is fixed in e.g. Boltz by having a separate mining-fee invoice as well that must be paid before the offchain/onchain swap service will create the onchain HTLC. This is why I thought it would be better to include the hold fee in the mining-fee invoice as well. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Lightning Pool: A Non-Custodial Channel Lease Marketplace
Hi y'all, We've recently released a new system which may be of interest to this list, Lightning Pool [1]. Alongside a working client [2], we've also released a white paper which goes deeper into the architecture of the system. Pool builds on some earlier ideas that were tossed around the ML concerning creating a market for dual-funding channels for the network (though the concept itself pre-dates those posts). Rather than target dual-funded channels, we focus on the current uni-directional channels, and allow users to buy+sell what we call a "channel lease" that packages up inbound (and also potentially outbound via side-car channels!) liquidity paying out a premium for a fixed duration. Live testnet+mainnet markets were also released today, giving routing nodes a new stable revenue source, and allowing those that need inbound to bootstrap their new Lightning Service a new automated way to do so. This is just our first alpha release which contains some limits/simplifications in the system itself. We plan to continue to iterate on the system to implement new things like streaming interest payments, and the version of side-car channels (buy a channel for a 3rd party) described in the paper amongst many other things. [1]: https://lightning.engineering/posts/2020-11-02-pool-deep-dive/ [2]: https://github.com/lightninglabs/pool [3]: https://lightning.engineering/lightning-pool-whitepaper.pdf ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost and Z, So in your proposal, an htlc that is received by a routing node has the > following properties: > * htlc amount > * forward up-front payment (anti-spam) > * backward up-front payment (anti-hold) > * grace period > The routing node forwards this to the next hop with > * lower htlc amount (to earn routing fees when the htlc settles) > * lower forward up-front payment (to make sure that an attacker at the > other end loses money when failing quickly) > * higher backward up-front payment (to make sure that an attacker at the > other end loses money when holding) > * shorter grace period (so that there is time to fail back and not lose > the backward up-front payment) That's exactly it, this is a good summary. An issue with the bidirectional upfront/hold fees is related to trustless > offchain-to-onchain swaps, like Boltz and Lightning Loop. > As the claiming of the offchain side is dependent on claiming of the > onchain side of the trustless swap mechanism, which is *definitely* slow, > the swap service will in general be forced to pay up the hold fees. Yes, that is a good observation. But shouldn't the swap service take that into account in the fee it collects to perform the swap? That way it is in fact the user who pays for that fee. Cheers, Bastien Le mer. 28 oct. 2020 à 02:13, ZmnSCPxj a écrit : > Good morning Bastien, Joost, and all, > > An issue with the bidirectional upfront/hold fees is related to trustless > offchain-to-onchain swaps, like Boltz and Lightning Loop. > > As the claiming of the offchain side is dependent on claiming of the > onchain side of the trustless swap mechanism, which is *definitely* slow, > the swap service will in general be forced to pay up the hold fees. > > It seems to me that the hold-fees mechanism cannot be ported over in the > onchain side, so even if you set a "reasonable" grace period at the swap > service of say 1 hour (and assuming forwarding nodes are OK with that > humongous grace period!), the onchain side of the swap can delay the > release of onchain. > > To mitigate against this, the swap service would need to issue a separate > invoice to pay for the hold fee for the "real" swap payment. > The Boltz protocol supports a separate mining-fee invoice (disabled on the > Boltz production servers) that is issued after the invoice is "locked in" > at the swap service, but I think that in view of the use of hold fee, a > combined mining-fee+hold-fee invoice would have to be issued at the same > time as the "real" swap invoice. > > Regards, > ZmnSCPxj > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
