From lloyd.fourn at gmail.com Mon May 24 05:53:16 2021 From: lloyd.fourn at gmail.com (Lloyd Fournier) Date: Mon, 24 May 2021 15:53:16 +1000 Subject: [Lightning-dev] Improving Payment Latency by Fast Forwards In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: