Re: [Lightning-dev] Escrow Over Lightning?
Good morning Nadav, and list, > > More generally, all Boolean logic can be converted to one of two standard > forms. > > - sum-of-products i.e. `||` over `&&` > - product-of-sums i.e. `&&` over `||` > > For example an XOR can be converted to the sum-of-products form: > > A ^ B = (!A && B) || (A && !B) > > If we have any complicated Boolean logic, we can consider to always use > some kind of product-of-sums form. > So for the example case, escrow service is the logic: > > SELLER && (BUYER || ESCROW) > > The above is a standard product-of-sums form. > > Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, > and the payment can be a reversal instead. > > SELLER && !(!BUYER && !ESCROW) > > The `!(a && b && ...)` can be converted to a reversal of the payment. > The individual `!BUYER` is just the buyer choosing not to claim the > seller->buyer direction, and the individual `!ESCROW` is just the escrow > choosing not to reveal its temporary scalar for this payment. > > > And any products (i.e. `&&`) are trivially implemented in PTLCs as trivial > scalar and point addition. > > So it may actually be possible to express any Boolean logic, by the use of > reversal payments and "option not to release scalar", both of which implement > the NOT gate needed for the above. > Boolean logic is a fairly powerful, non-Turing-complete, and consistent > programming language, and if we can actually implement any kind of Boolean > logic with a set of payments in various directions and Barrier Escrows we can > enable some fairly complex use-cases.. > > For example, a simple DLC binary oracle can provide two points in such a way > that it can only reveal one scalar of those two points (e.g. it has a > persistent public key `P`, and two temporary points `H` and `T` such that `H > = T + P`, and it can only safely reveal either `h` or `t`.). > Based on the outcome of a coin flip (or other input from the mythical "real > world"), it reveals either one or the other scalar. > Then we can use either point as part of any `!Oracle` or `Oracle` Boolean > logic we need. Okay, so here is a worked example. Suppose we have two oracles, 1 and 2. At some point, they will flip coins in the future. Based on their (independent) coin flip, oracle 1 will reveal either H1 or T1, and oracle 2 will reveal either H2 or T2. Suppose some bettor wants to make some bet: * Either both coins are heads (H1 && H2), or both coins are tails (T1 && T2). So we have a Bettor, and a Bookie that facilitates this bet. So the base logic is that the bettor wins (i.e. there is a payment Bookie->Bettor) if: (H1 && H2) || (T1 && T2) And the inverse of that logic (Better->Bookie) if the above is false. We also know that `T1 = !H1` and `T2 = !H2` (i.e. the DLC oracles will only publish one scalar or the other), so: (H1 && H2) || (!H1 && !H2) Let us transform to product-of-sums (this can be done by computers by using a Karnaugh Map): (H1 || !H2) && (!H1 || H2) Let us check by Boolean table: H1 H2(H1 && H2) || (!H2 && !H2) (H1 || !H2) && (!H1 || H2) 00 11 01 00 10 00 11 11 So the above product-of-sums is correct. We apply the De Morgan transform: !(!H1 && H2) && !(H1 && !H2) Then we return the `T`s: !(T1 && H2) && !(H1 && T2) Since the logic is inverted, what actually happens is that the Bettor makes two payments: * Bettor->Bookie : (Bookie && T1 && H2) * Bettor->Bookie : (Bookie && H1 && T2) The Bookie would also need to pay out if the Bettor wins, so the Bookie makes two payments as well: * Bookie->Bettor : (Bettor && T1 && T2) * Bookie->Bettor : (Bettor && H1 && H2) We can derive the above by inverting the initial `(H1 && H2) || (!H1 && !H2)` logic, then going through the same conversion to product-of-sums and De Morganizing it as for the Bettor case. With the above, we now have a setup where either both oracles are heads, or both oracles are tails, and if so the Bettor wins, otherwise the Bookie wins. This all probably needs to be set up with some kind of Barrier Escrow, but Nadav already has that covered. Here is a cute magical trick. What happens if for example oracle 1 has a failure where the CPU liquid cooler on its server fails, and oracle 1 is unable to find a replacement CPU cooler because the CPU socket has been obsoleted and nobody makes CPU coolers for that CPU socket anymore and the server cannot be brought up again? In that case, it will be unable to publish either `H1` or `T1`. And note that all the payments above involve `H1` or `T1`. In that case, nobody pays out to anyone, as none of the payments are ever claimable. Thus the case where "oracle disappears" is handled "gracefully" by simply not having any monetary transfers at
Re: [Lightning-dev] Escrow Over Lightning?
Good morning Nadav, and list, > > More generally, all Boolean logic can be converted to one of two standard > forms. > > - sum-of-products i.e. `||` over `&&` > - product-of-sums i.e. `&&` over `||` > > For example an XOR can be converted to the sum-of-products form: > > A ^ B = (!A && B) || (A && !B) > > If we have any complicated Boolean logic, we can consider to always use > some kind of product-of-sums form. > So for the example case, escrow service is the logic: > > SELLER && (BUYER || ESCROW) > > The above is a standard product-of-sums form. > > Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, > and the payment can be a reversal instead. > > SELLER && !(!BUYER && !ESCROW) > > The `!(a && b && ...)` can be converted to a reversal of the payment. > The individual `!BUYER` is just the buyer choosing not to claim the > seller->buyer direction, and the individual `!ESCROW` is just the escrow > choosing not to reveal its temporary scalar for this payment. > > > And any products (i.e. `&&`) are trivially implemented in PTLCs as trivial > scalar and point addition. > > So it may actually be possible to express any Boolean logic, by the use of > reversal payments and "option not to release scalar", both of which implement > the NOT gate needed for the above. > Boolean logic is a fairly powerful, non-Turing-complete, and consistent > programming language, and if we can actually implement any kind of Boolean > logic with a set of payments in various directions and Barrier Escrows we can > enable some fairly complex use-cases.. > > For example, a simple DLC binary oracle can provide two points in such a way > that it can only reveal one scalar of those two points (e.g. it has a > persistent public key `P`, and two temporary points `H` and `T` such that `H > = T + P`, and it can only safely reveal either `h` or `t`.). > Based on the outcome of a coin flip (or other input from the mythical "real > world"), it reveals either one or the other scalar. > Then we can use either point as part of any `!Oracle` or `Oracle` Boolean > logic we need. Okay, so here is a worked example. Suppose we have two oracles, 1 and 2. At some point, they will flip coins in the future. Based on their (independent) coin flip, oracle 1 will reveal either H1 or T1, and oracle 2 will reveal either H2 or T2. Suppose some bettor wants to make some bet: * Either both coins are heads (H1 && H2), or both coins are tails (T1 && T2). So we have a Bettor, and a Bookie that facilitates this bet. So the base logic is that the bettor wins (i.e. there is a payment Bookie->Bettor) if: (H1 && H2) || (T1 && T2) And the inverse of that logic (Better->Bookie) if the above is false. We also know that `T1 = !H1` and `T2 = !H2` (i.e. the DLC oracles will only publish one scalar or the other), so: (H1 && H2) || (!H1 && !H2) Let us transform to product-of-sums (this can be done by computers by using a Karnaugh Map): (H1 || !H2) && (!H1 || H2) Let us check by Boolean table: H1 H2(H1 && H2) || (!H2 && !H2) (H1 || !H2) && (!H1 || H2) 00 11 01 00 10 00 11 11 So the above product-of-sums is correct. We apply the De Morgan transform: !(!H1 && H2) && !(H1 && !H2) Then we return the `T`s: !(T1 && H2) && !(H1 && T2) Since the logic is inverted, what actually happens is that the Bettor makes two payments: * Bettor->Bookie : (Bookie && T1 && H2) * Bettor->Bookie : (Bookie && H1 && T2) The Bookie would also need to pay out if the Bettor wins, so the Bookie makes two payments as well: * Bookie->Bettor : (Bettor && T1 && T2) * Bookie->Bettor : (Bettor && H1 && H2) We can derive the above by inverting the initial `(H1 && H2) || (!H1 && !H2)` logic, then going through the same conversion to product-of-sums and De Morganizing it as for the Bettor case. With the above, we now have a setup where either both oracles are heads, or both oracles are tails, and if so the Bettor wins, otherwise the Bookie wins. This all probably needs to be set up with some kind of Barrier Escrow, but Nadav already has that covered. Here is a cute magical trick. What happens if for example oracle 1 has a failure where the CPU liquid cooler on its server fails, and oracle 1 is unable to find a replacement CPU cooler because the CPU socket has been obsoleted and nobody makes CPU coolers for that CPU socket anymore and the server cannot be brought up again? In that case, it will be unable to publish either `H1` or `T1`. And note that all the payments above involve `H1` or `T1`. In that case, nobody pays out to anyone, as none of the payments are ever claimable. Thus the case where "oracle disappears" is handled "gracefully" by simply not having any monetary transfers at
Re: [Lightning-dev] Escrow Over Lightning?
Good morning Nadav, > Hey ZmnSCPxj, > > Your earlier post about how to accomplish ORing points without verifiable > encryption was super interesting. > > I think this contains a clever general NOT operation where you double the > payment and use the point as a condition for the "cancellation payment." This > is actually very similar to something that is used in my PTLC DLC scheme > where many payments are failed in most cases :) But nice to add it to the > toolkit, especially as a way to not use ORs for the price of > over-collateralization which is acceptable in many use cases. Indeed, specifically this point of De Morgan Theorem transformation should probably be emphasized. More generally, all Boolean logic can be converted to one of two standard forms. * sum-of-products i.e. `||` over `&&` * product-of-sums i.e. `&&` over `||` For example an XOR can be converted to the sum-of-products form: A ^ B = (!A && B) || (A && !B) If we have any complicated Boolean logic, we can consider to always use some kind of product-of-sums form. So for the example case, escrow service is the logic: SELLER && (BUYER || ESCROW) The above is a standard product-of-sums form. Any sums (i.e. `||`) can be converted by De Morgan Theorem to product, and the payment can be a reversal instead. SELLER && !(!BUYER && !ESCROW) The `!(a && b && ...)` can be converted to a reversal of the payment. The individual `!BUYER` is just the buyer choosing not to claim the seller->buyer direction, and the individual `!ESCROW` is just the escrow choosing not to reveal its temporary scalar for this payment. And any products (i.e. `&&`) are trivially implemented in PTLCs as trivial scalar and point addition. So it may actually be possible to express *any* Boolean logic, by the use of reversal payments and "option not to release scalar", both of which implement the NOT gate needed for the above. Boolean logic is a fairly powerful, non-Turing-complete, and consistent programming language, and if we can actually implement any kind of Boolean logic with a set of payments in various directions and Barrier Escrows we can enable some fairly complex use-cases.. For example, a simple DLC binary oracle can provide two points in such a way that it can only reveal one scalar of those two points (e.g. it has a persistent public key `P`, and two temporary points `H` and `T` such that `H = T + P`, and it can only safely reveal either `h` or `t`.). Based on the outcome of a coin flip (or other input from the mythical "real world"), it reveals either one or the other scalar. Then we can use either point as part of any `!Oracle` or `Oracle` Boolean logic we need. > > One comment to make though, is that this mechanism requires the atomic setup > of multiple payments otherwise Seller -> Buyer will be set up after which > Buyer may keep the free option and not set up the payment in return. Luckily > with barrier escrows we can do atomic multi-payment setup to accomplish this! For this particular use-case, I think it is safe to just use the order "Seller->Buyer, then Buyer->Seller" rather than add a barrier escrow. Remember, the entire setup presumes that both Buyer and Seller can tr\*st the Escrow to resolve disputes, and the Seller->Buyer payment requires BUYER && ESCROW. If the buyer never makes the Buyer->Seller payment presumably the Escrow will take that into consideration during dispute resolution and not release the ESCROW scalar to the Buyer. And if the Buyer->Seller payment (which requires only SELLER scalar) is claimed "early" by the Seller before handing off the item, the Escrow is tr\*sted to consider this also (it is substantially the same as the Seller providing substandard goods) and release the ESCROW scalar. Of course in the most general case above where we could potentially do any arbitrary logic it probably makes most sense to use a Barrier escrow as well to ensure atomicity of the setup. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Hey ZmnSCPxj, Your earlier post about how to accomplish ORing points without verifiable encryption was super interesting. I think this contains a clever general NOT operation where you double the payment and use the point as a condition for the "cancellation payment." This is actually very similar to something that is used in my PTLC DLC scheme where many payments are failed in most cases :) But nice to add it to the toolkit, especially as a way to not use ORs for the price of over-collateralization which is acceptable in many use cases. One comment to make though, is that this mechanism requires the atomic setup of multiple payments otherwise Seller -> Buyer will be set up after which Buyer may keep the free option and not set up the payment in return. Luckily with barrier escrows we can do atomic multi-payment setup to accomplish this! Best, Nadav On Fri, Feb 12, 2021 at 11:26 PM ZmnSCPxj wrote: > Good morning Andres, > > > > > Is there any disadvantage about using dual-hash HTLCs? > > > > Is it supported by the current LN spec? > > > > > > It is no supported by current LN spec, and PTLCs are overall superior > (they are equivalent to having any number of hashes, not just 2 that > dual-hash HTLCs can do). > > > So if we need to change the LN spec anyway, PTLCs are still the better > choice, since they enable a lot more, and we probably want to support that > in the future anyway, so we might as well do HTLC->PTLC rather than > HTLC->2HTLC->PTLC. > > > > But anyway any L2 wallet that interacts with this, will need to be aware > of the escrow, so developing an 2HTLC extension for it to work with the > current version of bitcoin (instead of waiting for Taproot) should be > doable, right? > > Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be > a network-wide upgrade. > Then once the network-wide upgrade is deployed, individual endpoints just > have to understand this protocol. > > Because of the need of widespread upgrade, we would prefer to just upgrade > once, from HTLCs to PTLCs, rather than have multiple network-wide upgrades. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Good morning Andres, > > > Is there any disadvantage about using dual-hash HTLCs? > > > Is it supported by the current LN spec? > > > > It is no supported by current LN spec, and PTLCs are overall superior (they > > are equivalent to having any number of hashes, not just 2 that dual-hash > > HTLCs can do). > > So if we need to change the LN spec anyway, PTLCs are still the better > > choice, since they enable a lot more, and we probably want to support that > > in the future anyway, so we might as well do HTLC->PTLC rather than > > HTLC->2HTLC->PTLC. > > But anyway any L2 wallet that interacts with this, will need to be aware of > the escrow, so developing an 2HTLC extension for it to work with the current > version of bitcoin (instead of waiting for Taproot) should be doable, right? Every forwarding node needs to support 2HTLC or PTLC, meaning it has to be a network-wide upgrade. Then once the network-wide upgrade is deployed, individual endpoints just have to understand this protocol. Because of the need of widespread upgrade, we would prefer to just upgrade once, from HTLCs to PTLCs, rather than have multiple network-wide upgrades. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Escrow Over Lightning?
Hey ZmnSCPxj, On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj wrote: > Good morning Andres, > > > Hey ZmnSCPxj, > > > > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj wrote: > > > > > Good morning Andres, > > > > > > > This looks cool but would hinder UX too much for certain scenarios: > e.g. if the escrow in place is part of a bitcoin exchange, then you require > the bitcoin buyer to have bitcoin already, which makes it harder to on-ramp > new users (which could maybe only have fiat). Am I right? > > > > > > Correct. > > > Though note that existing systems like Bisq, to my knowledge, have the > same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to > offer as stake that can be revoked in case they attempt to defraud the > counterparty. > > > Without it, the counterparty takes on increased risk (which translate > to larger exchange spread). > > > > Yeah I understand Bisq's model. > > However not all P2P exchanges work like this; e.g. localcryptos, > hodlhodl, localbitcoins, localcryptos... > > > > At least localbitcoins is custodial, and this scheme is non-custodial > (though the escrow must still be trusted to actually judge correctly in > case of dispute, so non-custodiality might be a very thin assurance). > > True, I shouldn't have included LB in that list of examples; the other two are non-custodial though. > > > > > > > In any case, once you have that initial stake, you can then keep > increasing your ability to provide stake so as to relieve your > counterparties of risk and have them offer better exchange rates, so it is > "only" an issue for initial onboarding. > > > Presumably, in the later stable state, parents will provide children > the initial stake needed for them to start transacting over such a system, > just as they already provide their children with other "initial stakes" > (education, food, shelter, etc.) anyway. > > > > > > > > > > > So are you saying that this is not doable without PTLCs (with simple > HTLCs) unless it's done like suggested? > > > > > > Yes, it is yet another reason we want PTLCs quickly. > > > > > > An alternative would be to have dual-hash HTLCs, which would be > helpful in other escrow-related cases including escrow-facilitated > cross-currency swaps. > > > > Is there any disadvantage about using dual-hash HTLCs? > > Is it supported by the current LN spec? > > It is no supported by current LN spec, and PTLCs are overall superior > (they are equivalent to having any number of hashes, not just 2 that > dual-hash HTLCs can do). > So if we need to change the LN spec anyway, PTLCs are still the better > choice, since they enable a lot more, and we probably want to support that > in the future anyway, so we might as well do HTLC->PTLC rather than > HTLC->2HTLC->PTLC. > But anyway any L2 wallet that interacts with this, will need to be aware of the escrow, so developing an 2HTLC extension for it to work with the current version of bitcoin (instead of waiting for Taproot) should be doable, right? > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Good morning Joost, > > Not quite up-to-speed back into this, but, I believe an issue with using > > feerates rather than fixed fees is "what happens if a channel is forced > > onchain"? > > > > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is > > forced onchain, and the blockchain is bloated and the transaction remains > > floating in mempools until very close to the timeout of C-D. > > C is now liable for a large time the payment is held, and because the C-D > > channel was dropped onchain, presumably any parameters of the HTLC > > (including penalties D owes to C) have gotten fixed at the time the channel > > was dropped onchain. > > > The simplicity of the fixed fee is that it bounds the amount of risk that C > > has in case its outgoing channel is dropped onchain. > > The risk is bound in both cases. If you want you can cap the variable fee at > a level that isn't considered risky, but it will then not fully cover the > actual cost of the locked-up htlc. Also any anti-DoS fee could very well turn > out to be insignificant to the cost of closing and reopening a channel with > the state of the mempool these days. I think the problem of accidental channel closure is getting ignored by devs. If we think any anti-DoS fee will be "insignificant" compared to the cost of closing and reopening a channel, maybe dev attention should be on fixing accidental channel closure costs than any anti-DoS fee mechanism. Any deterrence of the channel jamming problem is economic so if the anti-DoS fee is tiny, then its deterrence will be tiny as well. It seems to me that adding this anti-DoS fee *on top of* an accidental channel closure is just adding insult to injury, when we should probably be considering how to ameliorate the injury. Otherwise forwarding nodes will themselves be deterred from operating at all. > > Is assuming increasing `hodl_fee_rate` along a payment path at odds with > > the ordering of timelocks ? > > I don't think it is. In terms of privacy, this is more dangerous. The decrementing timelock already leaks an upper bound on the distance to payee. An incrementing holdfee leaks an upper bound on the distance to payer. This translates to a single payment-part being more easily associated with the payer and payee. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi Antoine, That said, routing nodes might still include the risk of hitting the chain > in the computation of their `hodl_fee_rate` and the corresponding cost of > having onchain timelocked funds. > Yes, that could be another reason to define `hodl_fee_rate` as a base fee rate plus a component that is proportional to the amount. As mentioned in my initial email, the base fee can be used to cover the cost of occupying an htlc slot (which can be a significant factor for a large wumbo channel). The risk of hitting the chain that you mention can be factored into this base part as well. The hold fee rate would then be defined in the form (2 sat + 1%) per minute. > Given that HTLC deltas are decreasing along the path, it's more likely > that `hodl_fee_rate` will be decreasing along the path. Even in case of > lawfully solved hodl HTLC, routing nodes might be at loss for having paid a > higher hold_fee on their upstream link than received on the downstream one. > > Is assuming increasing `hodl_fee_rate` along a payment path at odds with > the ordering of timelocks ? > I don't think it is. There is indeed a time lock delta in case htlcs need to be settled on-chain. But in the happy offchain scenario, the added (wall clock) delay of a hop is tiny. So yes, they get paid from downstream a few seconds less in hold fees than what they need to pay upstream, but I think this is insignificant compared to the total compensation that they are getting (which is based on the grace period that is advertised). To be clear, for the calculation of the hold fee, it is the wall clock time that is used and not the block height. > > But this would also mean that anyone can send out an htlc and collect > hold fees unconditionally. Therefore routing nodes advertise on the network > their `hold_grace_period`. When routing nodes accept an htl> to forward, > they're willing to pay hold fees for it. But only if they added a delay > greater than `hold_grace_period` for relaying the payment and its response. > If they relayed in a timely fashion, they exp> ect the sender of the htlc > to cover those costs themselves. If the sender is also a routing node, the > sender should expect the node before them to cover it. Of course, routing > nodes can't be trusted. So in> practice we can just as well assume that > they'll always try to claim from the prior node the maximum amount in > compensation. > > Assuming `hodl_fee_rate` are near-similar along the payment path, you have > a concern when the HTLC settlement happens at period N on the outgoing link > and at period N+1 on the incoming link due to clock differences. In this > case, a routing node will pay a higher `hodl_fee_rate` than received. > > I think this is okay, that's an edge case, only leaking a few sats. > Is this the same concern as above or slightly different? Or do you mean clock differences between the endpoints of a channel? For that, I'd think that there needs to be some tolerance to smooth out disagreements. But yes, in general as long as a node is getting a positive amount, it is probably okay to tolerate a few rounding errors here and there. > A more concerning one is when the HTLC settlement happens at period N on > the outgoing link and your incoming counterparty goes offline. According to > the HTLC relay contract, the `hodl_fee_rate` will be inflated until the > counterparty goes back online and thus the routing node is at loss. And > going offline is a really lawful behavior for mobile clients, even further > if you consider mailbox-style of HTLC delivery (e.g Lightning Rod). You > can't simply label such counterparty as malicious. > > And I don't think counterparties can trust themselves about their onliness > to suspend the `hodl_fee_rate` inflation. Both sides have an interest to > equivocate, the HTLC sender to gain a higher fee, the HTLC relayer to save > the fee while having received one on the incoming link ? > Yes, that is a good point. But I do think that it is reasonable that a node that can go offline doesn't charge a hodl fee. Those nodes aren't generally forwarding htlcs anyway, so it would just be for their own outgoing payments. Without charging a hodl fee for outgoing payments, they risk that their channel peer delays the htlc for free. So they should choose their peers carefully. It seems that at the moment mobile nodes are often connected to a known LSP already, so this may not be a real problem. The policies for a channel can be asymmetric with the mobile node not charging hold fees for its outgoing htlcs to the LSP, while the LSP does charge hold fees for htlcs that its forwards to the mobile node. For the mailbox scenario, I think it is fair that someone is going to pay for all those locked htlcs along the route. If the LSP decides to hold the htlc until the destination comes online, they need to find a way to get the mailbox bill paid. All of this indeed also implies that nodes that do charge hold fees, need to make sure to stay
Re: [Lightning-dev] Hold fee rates as DoS protection (channel spamming and jamming)
Hi Joost, Thanks for working on this and keeping raising awareness about channel jamming. > In this post I'd like to present a variation of bidirectional upfront payments that uses a time-proportional hold fee rate to address the limitation above. I also tried to come up with a system that aims > relate the fees paid more directly to the actual costs incurred and thereby reduce the number of parameters. Not considering hold invoices and other long-term held packets was one of my main concerns in the previous bidirectional upfront payments. This new "hodl_fee_rate" is better by binding the hold fee to the effectively consumed timelocked period of the liquidity and not its potential maximum. That said, routing nodes might still include the risk of hitting the chain in the computation of their `hodl_fee_rate` and the corresponding cost of having onchain timelocked funds. Given that HTLC deltas are decreasing along the path, it's more likely that `hodl_fee_rate` will be decreasing along the path. Even in case of lawfully solved hodl HTLC, routing nodes might be at loss for having paid a higher hold_fee on their upstream link than received on the downstream one. Is assuming increasing `hodl_fee_rate` along a payment path at odds with the ordering of timelocks ? > But this would also mean that anyone can send out an htlc and collect hold fees unconditionally. Therefore routing nodes advertise on the network their `hold_grace_period`. When routing nodes accept an htl> to forward, they're willing to pay hold fees for it. But only if they added a delay greater than `hold_grace_period` for relaying the payment and its response. If they relayed in a timely fashion, they exp> ect the sender of the htlc to cover those costs themselves. If the sender is also a routing node, the sender should expect the node before them to cover it. Of course, routing nodes can't be trusted. So in> practice we can just as well assume that they'll always try to claim from the prior node the maximum amount in compensation. Assuming `hodl_fee_rate` are near-similar along the payment path, you have a concern when the HTLC settlement happens at period N on the outgoing link and at period N+1 on the incoming link due to clock differences. In this case, a routing node will pay a higher `hodl_fee_rate` than received. I think this is okay, that's an edge case, only leaking a few sats. A more concerning one is when the HTLC settlement happens at period N on the outgoing link and your incoming counterparty goes offline. According to the HTLC relay contract, the `hodl_fee_rate` will be inflated until the counterparty goes back online and thus the routing node is at loss. And going offline is a really lawful behavior for mobile clients, even further if you consider mailbox-style of HTLC delivery (e.g Lightning Rod). You can't simply label such counterparty as malicious. And I don't think counterparties can trust themselves about their onliness to suspend the `hodl_fee_rate` inflation. Both sides have an interest to equivocate, the HTLC sender to gain a higher fee, the HTLC relayer to save the fee while having received one on the incoming link ? > Even though the proposal above is not fundamentally different from what was known already, I do think that it adds the flexibility that we need to not take a step back in terms of functionality (fair prici> ng for hodl invoices and its applications). Plus that it simplifies the parameter set. Minding the concerns raised above, I think this proposal is an improvement and would merit a specification draft, at least to ease further reasoning on its economic and security soundness. As a side-note, we're working further on Stake Certificates, which I believe is better for long-term network economics by not adding a new fee burden on payments. We should be careful to not economically outlaw micropayments. If we think channel jamming is concerning enough in the short-term, we can deploy a bidirectional upfront payment-style of proposal now and consider a better solution when it's technically mature. Antoine Le jeu. 11 févr. 2021 à 10:25, Joost Jager a écrit : > Hi ZmnSCPxj, > > Not quite up-to-speed back into this, but, I believe an issue with using >> feerates rather than fixed fees is "what happens if a channel is forced >> onchain"? >> >> Suppose after C offers the HTLC to D, the C-D channel, for any reason, is >> forced onchain, and the blockchain is bloated and the transaction remains >> floating in mempools until very close to the timeout of C-D. >> C is now liable for a large time the payment is held, and because the C-D >> channel was dropped onchain, presumably any parameters of the HTLC >> (including penalties D owes to C) have gotten fixed at the time the channel >> was dropped onchain. >> > > The simplicity of the fixed fee is that it bounds the amount of risk that >> C has in case its outgoing channel is dropped onchain. >> > > The risk is bound in both cases. If you want you can cap
