[Lightning-dev] Improving Payment Latency by Fast Forwards

[ZmnSCPxj]

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