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 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
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
