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