ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-01 📝 Original message: Good morning LL, > Hi Z, ...

📅 Original date posted:2021-06-01
📝 Original message:
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