From lloyd.fourn at gmail.com Wed Oct 13 04:15:14 2021 From: lloyd.fourn at gmail.com (Lloyd Fournier) Date: Wed, 13 Oct 2021 15:15:14 +1100 Subject: [Lightning-dev] Lightning over taproot with PTLCs In-Reply-To: <20211012030821.GA6074@erisian.com.au> References: <20211009011207.GA3984@erisian.com.au> <20211011062951.GA5165@erisian.com.au> <20211012030821.GA6074@erisian.com.au> Message-ID: On Tue, 12 Oct 2021 at 14:08, Anthony Towns wrote: > > If you're willing to accept that "worst case" happening more often, I > think you could then retain the low latency forwarding, by having the > transaction structure be: > > commitment tx > input: > funding tx > outputs: > Alice's balance > (others) > > low-latency inflight tx: > input: > Alice's balance > output: > (1) or (2) > Alice's remaining balance > > Bob claim: > input: > (1) [ CSV bob CHECKSIG] > output: > [ checksigverify checksig > ifdup notif csv endif] > > Too-slow: > input: > (2) [ CLTV alice CHECKSIG] > output: > Alice > > The idea being: > > * Alice sends the low-latency inflight tx which Bob then forwards > immediately. > > * Bob then tries to update the base channel state with Alice, so both > sides have a commitment to the new payment, and the low-latency > inflight tx is voided (since it's based on a revoked channel state) > If this succeeds, everything is fine as usual. > > * If Alice is unavailable to confirm that update, Bob closes the > channel prior to (payment-timeout - payment-recover-delay), and posts > "Bob claim". After an additional pyment recovery delay (and prior > to payment-timeout) Bob posts Bob claim, ensuring that the only way > Alice can claim the funds is if he had posted a revoked state. > > * In this case, Alice has at least one payment-recovery-delay period > prior to the payment-timeout to notice the transaction onchain and > recover the preimage. > > * If Bob posted the low-latency inflight tx later than > (payment-timeout - payment-recovery-delay) then Alice will have > payment-recovery-delay time to notice and post the "too-slow" tx and > claim the funds via the timeout path. > > * If Bob posted a revoked state, Alice can also claim the funds via > Bob claim, provided she notices within the channel-recovery-delay > In my mind your "update the base channel state" idea seems to fix everything by itself. So at T - to_self_delay (or a bit before) you say to your counterparty "can we lift this HTLC out of your in-flight tx into the 'balance tx' (which will go back to naming a 'commitment tx' since it doesn't just have balance outputs anymore) so I can use it too? -- otherwise I'll have to close the channel on chain now to force you to reveal it to me on time?". If they agree, after the revocation and new commit tx everything is back to (tx symmetric) Poon-Dryja so no need for extra CSVs. Am I missing something? I realise this kills some of the elegance of your original protocol and adds quite a bit of complexity but I think it retains the important properties. > That only allows one low-latency payment to be inflight though, which I'm > not sure is that interesting... It's also kinda complicated, and doesn't > cover both the low-latency and offline cases, which is disappointing... > > It seems to me lazily lifting the HTLCs into the commitment tx would allow as many low-latency payments as you want to be in-flight. You would probably just lift them all up to the commitment tx if you lift one. I think in the case of nodes that want to keep channel keys offline, having to go on-chain at T - to_self_delay is not a disaster since it will likely only be the payment receiver who has their keys offline i.e. the merchant or end user. So only the last hop would go on chain if the user fails to claim payment as per usual (just to_self_delay earlier than usual). Cheers, LL -------------- next part -------------- An HTML attachment was scrubbed... URL: