[Lightning-dev] Improving Payment Latency by Fast Forwards
Introduction Currently, the protocol for forwarding requires 1.5 round trips before the next node can safely forward the payment. This creates much greater latency for payments, and even with the current network at a nascent stage, payments can take entire seconds to complete. As the network grows and some nodes start becoming unable to store the entire routemap, remote route lookups are needed. Remote route lookups are likely to increase the route length, thus payment latency will increase even more. So, we should consider ways of improving payment latency, before the increasing LN size causes further increases in payment latency. Like all optimizations, it is likely that we will need to run as fast as we can, just to stay in one place, like the Red Queen. Slow Forwarding --- The current protocol for a single forward looks like: Alice Bob Carol ||| | ---update_add_htlc---> || | --commitment_signed--> || ||| | <-commitment_signed--- || | <--revoke_and_ack- || ||| | ---revoke_and_ack> || || ---update_add_htlc---> | Bob cannot safely forward `update_add_htlc` immediately since there is no commitment transaction that contains the HTLC yet. Further, even when a new pair of commitment transactions is signed by Alice, two commitment transactions can still safely be put onchain, one of which does not contain the HTLC. Only when Alice and Bob have revoked their previous commitment transaction can Bob safely forward to Carol. The above concept is called "irrevocably committed" by the BOLT spec. To reach this "irrevocably committed" state, requires the above 1.5 round trips. If Alice and Bob are physically distant from each other, communication latency can be very large. Further, both Alice and Bob want to reduce bandwidth usage. This sometimes means that Alice and Bob will wait a short while before signing commitments and revoking previous ones, in order to keep the number of new signatures being passed around small. C-lightning, for example, defers signing a new commitment by 10ms after sending an update in case another forward on the same channel is requested. This causes additional latency on top of the communication latency. Poon-Dryja Outputs -- Let me now digress, to investigate the outputs of a Poon-Dryja commitment transaction. There are at least two commitment transactions that are valid at any one time, one for each node in the channel. Each one is symmetrical, but different. Thus, there is the concepts below: 1. "local" commitment transaction, is the valid commitment transaction I am holding. 2. "remote" commitment transaction, is the valid commitment transaction my counterparty is holding. Each commitment transaction has at least two outputs (although one may be elided if too small or 0). Thus, each commitment transaction has these two outputs: 1. "to-local" output. On the local commitment transaction, this is my "main" output. On the remote commitment transaction, this is my counterparty "main" output. 2. "to-remote" output. On the local commitment transaction, this is my counterparty "main" output. On the remote commitment transaction, this is my "main" output. In the original Poon-Dryja formulation, the "to-remote" output pays directly to a P2WPKH. However, the "to-local" output is encumbered by a CSV, and is revocable. In the BOLT 1.0 spec, the SCRIPT is: OP_IF # Penalty transaction OP_ELSE `to_self_delay` OP_CSV OP_DROP OP_ENDIF OP_CHECKSIG Of note, is that the `revocationpubkey` is actually a combination of the local node revocation key, and a remote node key. It is like a 2-of-2 that cannot be signed cooperatively by both parties, but which the local node can give entirely to the remote node so that the remote node can sign by itself (revocation). It could have been implemented as a 2-of-2 multisignature, but the above formulation takes less block space. In the recent Lightning Developer Summit in 2018, it was decided that the "to-remote" output will also be encumbered by a CSV. I will propose in this writeup, that a modification of the above script be used in both "to-local" and "to-remote". Fast Forwards = Ideally, we would like to be able to say that an HTLC is "irrevocably committed" using only a single message from Alice to Bob. That way, communication latencies when forwarding payments can be reduced, which should improve payment speed over the network in general. I observe that one may consider any
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning list, I have decided to dabble in necromancy, thus, I revive this long-dead thread from two years ago. Ph34R mE and my leet thread necromancy skillz. A short while ago, LL and Steve Lee were discussing about ways to reduce the privkey onlineness requirement for Lightning. And LL mentioned that this proposal could allow privkeys to be kept offline for a receiver. * The receiver has to be online, still. * Its privkeys can be kept offline. * The receiver can still receive even if its privkeys are offline (for example the privkeys are in a hardware signing module that is typically kept offline and is only put online at rare intervals). * The sender has to be online and the sender privkeys have to be online. * Forwarders and their privkeys have to be online. Unfortunately, I think the proposal, as currently made, cannot support the above feature, as stated. When an HTLC transaction is provided by the sender under a Fast Forward scheme, it provides a transaction that spends from "its" output in both versions of the latest Poon-Dryja commitment transaction. However, this output, as provided in the Fast Forward scheme, requires *two* signatures. Here are the scripts mentioned in the previous post: OP_IF # Penalty transaction/Fast forward OP_CHECKSIGVERIFY OP_ELSE `to_self_delay` OP_CSV OP_DROP OP_ENDIF OP_CHECKSIG And: OP_IF # Penalty transaction/Fast forward OP_CHECKSIGVERIFY OP_ELSE `to_self_delay` OP_CSV OP_DROP OP_ENDIF OP_CHECKSIG Now, the first branch is what is used in the Fast Forward scheme. And we can see that in the first branch, two signatures are needed: one for local, and one for remote. Thus, any HTLC-bearing transactions are signed by both the sender and receiver. Fast Forwards works its low-latency magic by simply having the sender send the signature spending from the current channel state, outright, to the receiver, and until the channel is updated, the HTLC is "safe": * The current channel state (represented by some commitment tx) cannot be replaced with an alternative, without the replacer risking funds loss (Poon-Dryja punishment mechanism). * The spending tx that instantiates the HTLC is safe because the receiver will not willingly sign an alternate version. ***HOWEVER***, the HTLC is safe on the assumption that *the receiver can provide its signature* if the channel is dropped onchain. And channels can be dropped onchain *at any time*. If the receiver is unable to provide its signature before the `to_self_delay` finishes, then the sender can revoke ***all*** HTLCs it sent! Thus, at least as initially stated, Fast Forwards cannot be used for this "receiver online, privkeys offline, can receive" feature. ***HOWEVER HOWEVER***, we should note that the caveats are something we can actually work with: * The privkeys can only be offline for up to `to_self_delay` blocks. * We ***need*** privkeys to be periodically online more often than `to_self_delay` anyway, ***in case of theft attempts***. So this is not an ***additional*** requirement at least. * Watchtowers cannot guard against attempts to steal Fast Forwarded HTLCs --- they need to receive the signatures for the HTLC transactions as well, otherwise they can do nothing about it. * However, whenever the receiver sends to a watchtower it *does* need to send signatures anyway, so it still needs to get privkeys online for signing. * Since we need the privkeys to be made online a little more often than every `to_self_delay` blocks anyway, this is *not* an additional requirement! ***THUS***, we *can* provide a tweaked version of the above desired feature: * The receiver has to be online, still. * Its privkeys can be kept offline, ***BUT***, it has to be regularly brought online a little more often than `to_self_delay`. * The receiver can still receive even if its privkeys are offline (for example the privkeys are in a hardware signing module that is typically kept offline and is only put online at rare intervals). * The sender has to be online and the sender privkeys have to be online. * Forwarders and their privkeys have to be online. The additional requirement --- that the receiver privkeys have to be regularly brought online --- is not actually an onerous one *since we need it for channel safety*. So this feature is indeed supported by Fast Forwards (with fairly minimal caveats!) and kudos to LL for thinking of it! Against this, we should remind the drawbacks of Fast Forwards: * Onchain space is much higher (in the unilateral close case only --- channel opens and mutual closes remain small) due to chaining of transactions instead of strict replacement. * Fast Forwarded HTLCs need to have their signatures stored on replicated storage, and is O(n) (current Poon-Dryja requires O(1) storage for revocation keys but O(n) storage for HTLC
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning list, Note that there is a possible jamming attack here. More specifically, when "failing" an incoming HTLC, the receiver of the HTLC sends its signature for a transaction spending the HTLC and spending it back to the sender revocable contract. The funds cannot be reused until the channel state is updated to cut-through all the transactions (the HTLC transaction and the failure transaction). (Well it *could* but that greatly amps the complexity of the whole thing --- no, just no.) Thus I could jam a particular receiver by sending, via forwarding nodes, to that receiver, payments with a random hash, which with high probability have preimages that are unknown by the receiver. The receiver can only fail those HTLCs, but "to fail an HTLC" under Fast Forwards makes the funds unusable, until the previous channel state can be revoked and replaced with a new one. But updating the channel state requires privkeys to be online in order to create the signatures for the new channel state. This creates a practical limit on how long you can keep privkeys offline; if you keep it offline too long, an attacker can jam all your incoming capacity for long periods of time. This is not currently a problem without "receiver online, privkey offline", since without "privkey offline" case, the receiver can update the channel state immediately. However, if the receiver is willing to lose privacy, the protocol can be mildly modified so that the receiver tells the forwarding node to *first* ask the receiver about every HTLC hash before actually instantiating and sending the HTLC. Only if the receiver agrees will the forwarder actually send the HTLC. The forwarder is incentivized to go along with this, as otherwise, the receiver cannot actually fail any HTLCs --- it needs to provide a signature, and signatures require privkeys, and the receiver has those offline. Thus, the forwarder would prefer to ask the receiver *before* it instantiates the HTLC, as otherwise the HTLC cannot be cancelled until the receiver gets its privkeys online, which can take a long time --- and if the HTLC times out in the meantime, that can only be enforced by dropping onchain, and Fast Forwards are *very* expensive in the unilateral close case. Obviously this tells the forwarding node that the channel is used for receiving and that any payments over it terminate at the next hop, thus a privacy degradation. On the other hand, unpublished channels remain popular despite my best efforts, and this is the exact problem unpublished channels have, so not a degradation in privacy in practice, since users of unpublished channels already have degraded privacy (axiom of terminus), This also increases latency once again, as there is now 1.5 roundtrips (forwarder asks receiver if this forwarded HTLC is kosher, receiver responds, forwarder sends signature to HTLC transaction). However, the increased latency only occurs at the endpoint; forwarders (which need to have privkeys online 100% of the time anyway, and can thus cut-through any number of failed HTLCs at any time) can skip the "is this HTLC kosher" message and just send the HTLC signatures immediately. Thus, this may be an acceptable tradeoff. Thus, one might consider this scheme to be usable for *either* Fast Forwards, *or* "receiver online, privkeys offline", but not usefully both (after all, a forwarder is both a receiver and a sender, and a sender needs its keys in order to send, so it cannot use the "privkeys offline" feature anyway). It may be difficult to understand this, so maybe I will make a convenient presentation of some sort. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hey Z, Thanks for your analysis. I agree with your conclusion. I think the most practical approach is the "ask first" 3 round protocol. Another option is to have `remote_penaltyclaimpubkey` owned by the node instead of the hardware device. This allows funds to accrue in the fast forward state which can be swept into the commit tx at the merchants discretion. If a fast forward state needs to be asserted on-chain it can then be done automatically without the hardware device. Of course, the funds in the FF state are more vulnerable than the main channel balance during that time because their keys are not in a secure device but this seems ok. The obvious analogy is to having cash in the till (less secure) that you send to your bank (more secure™) at the end of the day or week. > We ***need*** privkeys to be periodically online more often than `to_self_delay` anyway, ***in case of theft attempts***. > So this is not an ***additional*** requirement at least. This is a really important point. I guess you have to actually do this periodically, only when there is an actual attempt at theft. Quite annoying to UX to require this. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning LL, > Hey Z, > > Thanks for your analysis. I agree with your conclusion. I think the most > practical approach is the "ask first" 3 round protocol. > > Another option is to have `remote_penaltyclaimpubkey` owned by the node > instead of the hardware device. > This allows funds to accrue in the fast forward state which can be swept into > the commit tx at the merchants discretion. > If a fast forward state needs to be asserted on-chain it can then be done > automatically without the hardware device. > Of course, the funds in the FF state are more vulnerable than the main > channel balance during that time because their keys are not in a secure > device but this seems ok. > The obvious analogy is to having cash in the till (less secure) that you send > to your bank (more secure™) at the end of the day or week. This seems a useful technique. > > > We ***need*** privkeys to be periodically online more often than > > `to_self_delay` anyway, ***in case of theft attempts***. > > So this is not an ***additional*** requirement at least. > > This is a really important point. I guess you have to actually do this > periodically, only when there is an actual attempt at theft. Quite annoying > to UX to require this. If you mean "***not*** only when there is an actual attempt at theft", yes. My thought that this would be useful for a "big"-ish merchant that primarily accepts payments, to mitigate its key exposure. It would program a small low-power device such that it almost always has its network interface disabled, but periodically (at random times) it will enable its network interface and connect out to the node, presenting a proof that it holds the privkey. It would have a firewall so that it cannot receive incoming connection requests and can only make outgoing connection requests (and as noted above, most of the time the network interface would be disabled outright). Then the node could wait for this hardware to contact it, and proceed to "roll up" any fast-forwarded HTLCs. This could also be an opportunity for the node to send out funds, for example to pay the salaries of employees or dividends to shareholders of the merchant. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning list, > It may be difficult to understand this, so maybe I will make a convenient > presentation of some sort. As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp The presentation is intended to be seen by semi-technical and technical people, particular those that have not read (or managed to fully read and understand) the original writeup in 2019. Simply "run" the presentation (F5 in LibreOffice), as the presentation uses callouts extensively for explication. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, I just went through the presentation which made your thinking very clear. Thanks. I will not be able to match this effort so please bear with me as I try and explain my own thinking. I don't see why fast forwards (FF) need "symmetrically encumbered outputs"? To me the protocol should be asymmetric. This is what I think happens when offering a FF HTLC: 1. The offerer creates and signs a new commitment tx as normal with the HTLC except it has the same revocation key as the last one. 2. The offerer patches their balance output by sending a tx spending from it to a new tx which has the HTLC output and their balance output (unencumbered). The HTLC is now irrevocably committed from the perspective of the receiver. Now the receiver presents the pre-image and the offerer then: 1. The offerer creates and signs a new commitment tx as normal consolidating the funds into the receiver's balance output except once again it has the same revocation key as the last one. 2. The offerer patches their commitment tx balance output again by sending a tx spending from it to a new tx which splits into the receiver's balance (the value of the claimed HTLC) and the offerer's remaining balance. You can repeat the above process without having the receiver's revocation keys online or their commitment tx keys for many HTLCs while the offerer still has balance towards the receiver. The on-chain cost is about the same as before for an uncooperative close. Once the receiver brings their keys on line they can consolidate the FF state into a new commitment txs on both sides and with a proper revocation operate the channel normally. What has been the receiver up until now can finally send funds. Am I missing something? Cheers, LL On Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > > It may be difficult to understand this, so maybe I will make a > convenient presentation of some sort. > > As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp > > The presentation is intended to be seen by semi-technical and technical > people, particular those that have not read (or managed to fully read and > understand) the original writeup in 2019. > Simply "run" the presentation (F5 in LibreOffice), as the presentation > uses callouts extensively for explication. > > Regards, > ZmnSCPxj > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning LL, > Hi Z, > > I just went through the presentation which made your thinking very clear. > Thanks. > I will not be able to match this effort so please bear with me as I try and > explain my own thinking. > I don't see why fast forwards (FF) need "symmetrically encumbered outputs"? > To me the protocol should be asymmetric. > > This is what I think happens when offering a FF HTLC: > 1. The offerer creates and signs a new commitment tx as normal with the HTLC > except it has the same revocation key as the last one. > 2. The offerer patches their balance output by sending a tx spending from it > to a new tx which has the HTLC output and their balance output (unencumbered). > > The HTLC is now irrevocably committed from the perspective of the receiver. > Now the receiver presents the pre-image and the offerer then: > > 1. The offerer creates and signs a new commitment tx as normal consolidating > the funds into the receiver's balance output except once again it has the > same revocation key as the last one. > 2. The offerer patches their commitment tx balance output again by sending a > tx spending from it to a new tx which splits into the receiver's balance (the > value of the claimed HTLC) and the offerer's remaining balance. > > You can repeat the above process without having the receiver's revocation > keys online or their commitment tx keys for many HTLCs while the offerer > still has balance towards the receiver. > The on-chain cost is about the same as before for an uncooperative close. > > Once the receiver brings their keys on line they can consolidate the FF state > into a new commitment txs on both sides and with a proper revocation operate > the channel normally. What has been the receiver up until now can finally > send funds. > > Am I missing something? Basically, you are taking advantage of the fact that we **actually** let the commitments on both sides be desynchronized with each other. I tend to elide this fact when explaining, and also avoid it when planning protocols. However I believe the idea is correct. Anyway, as I understood it: So suppose we start with this pair of commitment txes: +--+ | Commitment tx 1 of A| ++-+ || (A[0] && B) | ||||(A && CSV) | |SigB+-+ || B | || | ++-+ +--+ | Commitment tx 1 of B| ++-+ |SigA| A | || | |+-+ || (A && B[0]) | ||||(B && CSV) | ++-+ Now Alice wants to offer an HTLC to Bob. What Alice does is: * **Retain** the Alice commitment tx and create an HTLC tx spending from it. * **Advance** the Bob commitment tx (and letting it desync from the Alice commitment tx), adding the same HTLC. So after Alice sends its new signatures, our offchain txes are: +--++--+ | Commitment tx 1 of A|| HTLC Tx | ++-+++-+ || (A[0] && B) |--->| SigA[0] | (A[0] && B) | ||||(A && CSV) |||||(A && CSV) | |SigB+-+|+-+ || B |||A->B | || |||HTLC | ++-+++-+ +--+ | Commitment tx *2* of B | ++-+ |SigA| A | || | |+-+ || (A && B[1]) | ||||(B && CSV) | |+-+ ||A->B | ||HTLC | ++-+ Notes: * Again, for Alice to offer the HTLC to Bob, only Alice has to make new signatures (`SigA[0]` and `SigA` for commitment tx *2* of Bob). * If Alice goes offline and Bob decides to drop onchain, Bob only needs to sign the new commitment tx. We can argue that dropping channels *should* be rare enough that requiring privkeys for this operation is not a burden. * If Alice decides to drop the channel onchain, Bob only needs to bring in the privkey for the HTLC tx, which we can (at a lower, detailed level) be different from the "main" B privkey. So yes, I think it seems workable without symmetric encumbrance. Regards. ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning again LL, So I started thinking as well, about Decker-Russell-Osuntokun and the Fast Forwards technique, as well as your "desync" idea. And it seems to me that we can also adapt a variant of this idea with Decker-Russell-Osuntokun, with the advantage of **not** requiring the additional encumbrance at the outputs. The technique is that we allow Bob the receiver to have possession of *later* states while Alice the sender only possesses an old state. Alice sends the signatures for a new state (update + settlement) whenever it offers an HTLC to Bob, and whenever Bob fulfills the HTLC. However, Alice *does not* wait for Bob to return signatures for a new state. So Alice remains stuck with the old state. * Suppose Alice wants to close the channel unilaterally. * Alice broadcasts the old update tx. * Bob has an incentive to bring its latest state onchain (bringing its privkey online and signing the latest update). * All the payments are in the Alice->Bob direction. * Even though Alice broadcasted an old state, it does not lose money since Decker-Russell-Osuntokun is non-punitive. * Bob can bring its privkey online to close the channel unilaterally with the latest state. So it looks to me that Decker-Russell-Osuntokun similarly does **not** require the additional encumbrance at the "main" outputs. We simply allow the sender to remain at an older state. So let us give a concrete example. * Alice and Bob start at state 1: Alice = 50, Bob = 50. * Alice offers a HTLC of value 10. * Alice: state 1: Alice = 50, Bob = 50 * Bob: state 2: Alice = 40, Bob = 50, A->B HTLC = 10 * Bob fulfills, so Alice sends a new state.which transfers the A->B HTLC value to Bob. * Alice: state 1: Alice = 50, Bob = 50 * Bob: state 3: Alice = 40, Bob = 60 * Bob brings its privkey online because it wants to send out via Alice (a forwarder). It offers an HTLC B->A of value 20. * Alice: state 4: Alice = 40, Bob = 40, B->A HTLC = 20 * Bob: state 3: Alice = 40, Bob = 60 Because publishing old state is "safe" under Decker-Russell-Osuntokun, it is fine for one participant to have *only* an older state! And we can arrange the incentives so that the one with the latest state is the one who is most incentivized to publish the latest state. (We should probably change the subject of this thread BTW) Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes. At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, I agree with your analysis. This is how I pictured eltoo fast forwards working as well. Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them. With the non-custodial LN phone apps there is this annoying UX where you have to keep the app open to receive a payment (because the pre-image is on my phone). I wouldn't mind letting the provider handle receiving payments on my behalf. Of course this means they would be able to steal the money in the FF state but this is a big reduction in risk from a full custodial solution. In other words, you should be able to get the seamless experience of a fully custodial wallet while only giving them custody of small amounts of coins for a short time. On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj wrote: > > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do > *not* build up a long chain of HTLC txes. > At the worst case, we have an old update tx that is superseded by a later > update tx instead, thus the overhead is expected to be at most 1 extra > update tx no matter how many HTLCs are offered while Bob has its privkey > offline. > I don't think you need to build up a long chain of HTLC txs for the Poon-Dryja fast forward in the "desync" approach. Each one just replaces the other. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning LL, > Hi Z, > > I agree with your analysis. This is how I pictured eltoo fast forwards > working as well. > > Another interesting thing about this idea is that it could allow a new type > of custodial LN provider where the custodian is only in charge of receiving > payments to the channel but cannot spend them. > With the non-custodial LN phone apps there is this annoying UX where you have > to keep the app open to receive a payment (because the pre-image is on my > phone). > I wouldn't mind letting the provider handle receiving payments on my behalf. > Of course this means they would be able to steal the money in the FF state > but this is a big reduction in risk from a full custodial solution. > In other words, you should be able to get the seamless experience of a fully > custodial wallet while only giving them custody of small amounts of coins for > a short time. Yes, that is indeed a good advantage and thank you for this. > On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj wrote: > > > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do > > *not* build up a long chain of HTLC txes. > > At the worst case, we have an old update tx that is superseded by a later > > update tx instead, thus the overhead is expected to be at most 1 extra > > update tx no matter how many HTLCs are offered while Bob has its privkey > > offline. > > I don't think you need to build up a long chain of HTLC txs for the > Poon-Dryja fast forward in the "desync" approach. Each one just replaces the > other. Thinking about it more, this seems correct. Referring back to the diagrams: +--++--+ | Commitment tx 1 of A|| HTLC Tx | ++-+++-+ || (A[0] && B) |--->| SigA[0] | (A[0] && B) | ||||(A && CSV) |||||(A && CSV) | |SigB+-+|+-+ || B |||A->B | || |||HTLC | ++-+++-+ +--+ | Commitment tx *2* of B | ++-+ |SigA| A | || | |+-+ || (A && B[0]) | ||||(B && CSV) | |+-+ ||A->B | ||HTLC | ++-+ On the *next* HTLC, Alice just gives s commitment tx *3* `SigA`, and a replacement HTLC Tx `SigA[0]` to the cashier of Bob. +--++--+ | Commitment tx 1 of A|| HTLC Tx *2*| ++-+++-+ || (A[0] && B) |--->| SigA[0] | (A[0] && B) | ||||(A && CSV) |||||(A && CSV) | |SigB+-+|+-+ || B |||A->B | || |||HTLC | ++-+|+-+ ||A->B | ||HTLC | ++-+ +--+ | Commitment tx *3* of B | ++-+ |SigA| A | || | |+-+ || (A && B[0]) | ||||(B && CSV) | |+-+ ||A->B | ||HTLC | |+-+ ||A->B | ||HTLC | ++-+ This is safe, because: * If Alice publishes Commitment tx 1 of Alice, Bob has every incentive to publish the HTLC Tx *2*, not the older HTLC Tx. * Alice cannot force publishing the *previous* HTLC Tx, because Alice has no `B` key and cannot force-publish it. * If Bob wants to close unilaterally, it has every incentive to publish the latest Commitment tx ### of B, because that has the most HTLCs going to Bob. Against the above we should note that the "HTLCs" we are talking about in Poon-Dryja are not simple contracts but are instead revocable HTLCs, which means additional dependent transactions. So I think the above *is* doable, but *does* require additional complexity and care, in that every A->B HTLC has to have some signatures exchanged as well (which, as they are HTLCs "in flight", we can have the keys on the cashier). - I also have another subtlety to bring up with the above. In particular, for a set of *simplex* Alice-to-Bob paymen
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, Thanks again for getting to the bottom of this. I think we are on the same page except for one clarification: On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote: > Thus, in our model, we have the property that Bob can always recover all > signatures sent by Alice, even if Carol is corrupted by Alice --- we model > the signature-deletion attack as impossible, by assumption. > (This is a strengthening of security assumptions, thus a weakening of the > security of the scheme --- if Bob does not take the above mitigations, Bob > ***is*** vulnerable to a signature-deletion attack and might have ***all*** > funds in hostage). > Only where ***all*** refers to the funds in the fast forward -- funds consolidated into the channel balance are not at risk (modulo enforcing correct state on chain). I think it should be easy to get a stream of signatures so they can't be deleted. The user "Bob" is creating and sending the invoices so they can always demand and save the signatures from "Carol the Cashier" that correspond to each payment so the "deletion attack" will be thwarted. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Good morning LL, > Hi Z, > > Thanks again for getting to the bottom of this. I think we are on the same > page except for one clarification: > > On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote: > > > > Thus, in our model, we have the property that Bob can always recover all > > signatures sent by Alice, even if Carol is corrupted by Alice --- we model > > the signature-deletion attack as impossible, by assumption. > > (This is a strengthening of security assumptions, thus a weakening of the > > security of the scheme --- if Bob does not take the above mitigations, Bob > > ***is*** vulnerable to a signature-deletion attack and might have ***all*** > > funds in hostage). > > Only where ***all*** refers to the funds in the fast forward -- funds > consolidated into the channel balance are not at risk (modulo enforcing > correct state on chain). > I think it should be easy to get a stream of signatures so they can't be > deleted. The user "Bob" is creating and sending the invoices so they can > always demand and save the signatures from "Carol the Cashier" that > correspond to each payment so the "deletion attack" will be thwarted. To be clear, what I meant here with "***all***" was that risk of funds hostage exists if Bob has absolutely no mitigation against this (i.e. makes no copies of signatures for itself). What you suggest is a mitigation that *does* prevent this "***all***" case (i.e. Bob makes its own copies of signatures, it does not delegate signature storage to Carol the Cashier). Thus, the model outright assumes that Bob makes *some* mitigation to prevent signature deletion, as without *any* mitigation the model is insecure. Otherwise I think we are mostly in agreement here. -- Another thing I have been mulling over is an older proposal where some Lightning service-provider (who takes on the role of Alice in our description) simply generates the invoice+preimage itself. Then when Bob comes online, the Lightning service-provider (Alice hmmm A Lightning Service-provider hence "ALS" or "Alice") simply forwards the payment to Bob at that time. i.e. * Bob makes an invoice+preimage for a third party to pay. * Bob hands over the preimage to Alice. * Bob goes offline. * Sender sends to Alice, who has the preimage and can claim it. * Bob goes online. * Alice sends the payment. Note that Alice is trusted to honestly forward the payment to Bob when Bob comes online in this older proposal. However, in this older proposal, any funds "already" in the Bob-side of the channel are safe --- Alice cannot steal them. Alice can only steal funds it has not forwarded to Bob yet. Now, let us return to the detailed FF scheme (with separate Carol the Cashier and Kelly the Keykeeper). If Carol was operated by Alice, it would have similar security to the above older proposal. * Carol does not have any Bob privkeys or the entire set of revocation keys, so cannot steal channel funds outright. * We assume that Bob has mitigations against signature deletion (i.e. Bob has backups of signatures). * We have already established in previous discussion, Alice+Carol cannot cooperate to steal funds "already" in the channel --- they can only steal funds from payments that Bob has not come online to claim yet. However, the older proposal has significant advantage: * It is simpler and can reuse existing code and tests. Indeed, C-Lightning plus plugins can implement the older proposal today, with fairly small amount of new code (only for the plugin --- no changes to C-Lightning necessary, just add a plugin, thus significantly lower testing burden). Contrast this with FF, which requires a new state machine and protocol to implement, with greatly increased potential for CVEs. What FF *does* have as an advantage is that Carol the Cashier can be operated by **Bob** rather than Alice. For example, Bob can have a single-board computer that runs Carol-software, and the mobile phone of Bob is simply a remote control for the Carol-software. The advantage here is that the single-board computer, which is 100% online, does *not* have any privkeys. This is in contrast with current Lightning implementations, where such a "remote control" scheme would need privkeys to be kept on the single-board computer, at risk of exfiltration. Bob can have a separate Kelly-hardware that it connects to its mobile phone whenever Bob needs to send out money, thus greatly reducing the risk experienced by Bob. The previous proposal cannot do this as honest resolution of the payment is simply immediately trusted to Alice A Lightning Service-provider. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
