Update multi-hop-locks to Musig2

Musig2 will always be preferred over Musig, so the scriptless script
multi-hop-locks construction should use it.

Author: t-bast

md/images/multi-hop-locks.png

@@ -22,21 +22,21 @@ participant Dave
 
 == Update ==
 
-Alice->Bob  : add 2-of-2 MuSig(A,B) output with timelocked refund to A,\ncreate txB spending this to B, nonce(A,txB)
-Bob->Alice  : nonce(B,txB), psig(B,txB,(z+y0)*G)
+Alice->Bob  : add 2-of-2 MuSig(A,B) output with timelocked refund to A,\ncreate txB spending this to B, pnonces(A)
+Bob->Alice  : pnonces(B), psig(B,txB,(z+y0)*G)
 Alice->Bob  : psig(A,txB,(z+y0)*G)
-Bob->Carol  : add 2-of-2 MuSig(B,C) output with timelocked refund to B,\ncreate txC spending this to C, nonce(B,txC)
-Carol->Bob  : nonce(C,txC), psig(C,txC,(z+y0+y1)*G)
+Bob->Carol  : add 2-of-2 MuSig(B,C) output with timelocked refund to B,\ncreate txC spending this to C, pnonces(B)
+Carol->Bob  : pnonces(C), psig(C,txC,(z+y0+y1)*G)
 Bob->Carol  : psig(B,txC,(z+y0+y1)*G)
-Carol->Dave : add 2-of-2 MuSig(C,D) output with timelocked refund to C,\ncreate txD spending this to D, nonce(C,txD)
-Dave->Carol : nonce(D,txD), psig(D,txD,(z+y0+y1+y2)*G)
+Carol->Dave : add 2-of-2 MuSig(C,D) output with timelocked refund to C,\ncreate txD spending this to D, pnonces(C)
+Dave->Carol : pnonces(D), psig(D,txD,(z+y0+y1+y2)*G)
 Carol->Dave : psig(C,txD,(z+y0+y1+y2)*G)
 
 == Settlement ==
 
 Dave->Dave   : create adaptor_sig(D,txD,(z+y0+y1+y2)*G),\nMuSig combine with psig(C,txD,(z+y0+y1+y2)*G),\nbroadcast txD with combined sig
-Carol->Carol : compute z+y0+y1 = adaptor_sig(D,txD,(z+y0+y1+y2)*G) - psig(D,txD,(z+y0+y1+y2)*G) - y2\nto create adaptor_sig(C,txC,(z+y0+y1)*G),\nMuSig combine with psig(B,txC,(z+y0+y1)*G),\nbroadcast txC with combined sig
-Bob->Bob     : compute z+y0 = adaptor_sig(C,txC,(z+y0+y1)*G) - psig(C,txC,(z+y0+y1)*G) - y1\nto create adaptor_sig(B,txB,(z+y0)*G),\nMuSig combine with psig(A,txB,(z+y0)*G),\nbroadcast txB with combined sig
-Alice->Alice : compute z = adaptor_sig(B,txB,(z+y0)*G) - psig(B,txB,(z+y0)*G) - y0
+Carol->Carol : compute z+y0+y1 =\n    adaptor_sig(D,txD,(z+y0+y1+y2)*G)\n    - psig(D,txD,(z+y0+y1+y2)*G)\n    - y2\nto create adaptor_sig(C,txC,(z+y0+y1)*G),\nMuSig combine with psig(B,txC,(z+y0+y1)*G),\nbroadcast txC with combined sig
+Bob->Bob     : compute z+y0 =\n    adaptor_sig(C,txC,(z+y0+y1)*G)\n    - psig(C,txC,(z+y0+y1)*G)\n    - y1\nto create adaptor_sig(B,txB,(z+y0)*G),\nMuSig combine with psig(A,txB,(z+y0)*G),\nbroadcast txB with combined sig
+Alice->Alice : compute z =\n    adaptor_sig(B,txB,(z+y0)*G)\n    - psig(B,txB,(z+y0)*G)\n    - y0
 
 @enduml

md/images/multi-hop-locks.txt

@@ -14,12 +14,13 @@ In addition, scriptless script multi-hop locks enable improved proof of payment
 Notation
 ---
 
-- `Xij := (xi + xj)*G` is the MuSig-combined public key of users `i` and `j`. Note that `xi` and `xj` are MuSig-tweaked secret keys (not the secret keys of users `i` and `j`). See the [MuSig paper](https://eprint.iacr.org/2018/068.pdf) for more details.
-- `nonce(i,m) := ki*G` is the public nonce of user `i` for a MuSig signature on `m` (note that we don't call nonces `R` here to avoid confusion with the right lock `R`).
-- `T := t*G` is an arbitrary tweak applied to the shared nonce.
-- `psig(i,m,T) := ki + H(nonce(i,m)+nonce(j,m)+T,Xij,m)*xi` is a partial 2-of-2 MuSig from user `i` with user `j` for `m`.
+- `Pij := (mui*xi + muj*xj)*G` is the MuSig2 aggregated public key of users `i` and `j`, where `xi` and `xj` are the secret keys of users `i` and `j`. See the [MuSig2 paper](https://eprint.iacr.org/2020/1261) for more details.
+- `pnonces(i)` are the Musig2 nonces of user `i` (note that they are independent of `m` and `T`).
+- `T := t*G` is an arbitrary tweak applied to nonces.
+- `nonce(i,m,T) := ni(m,T)*G` is the public "effective" nonce of user `i` for a Musig2 signature on message `m` (note that we don't call nonces `R` here to avoid confusion with the right lock `R`)
+- `psig(i,m,T) := ni(m,T) + H(Pij, nonce(i,m,T) + nonce(j,m,T) + T, m)*mui*xi` is a partial 2-of-2 MuSig2 from user `i` with user `j` for `m`.
 - `adaptor_sig(i,m,T) := psig(i,m,T) + t`
-- `sig(m,T) := psig(i,m,T) + adaptor_sig(j,m,T)` is the completed 2-of-2 MuSig from user `i` and `j` (public key `Xij`). It can be computed from a partial signature and an adaptor signature.
+- `sig(m,T) := psig(i,m,T) + adaptor_sig(j,m,T)` is the completed 2-of-2 MuSig2 from user `i` and `j`. It can be computed from a partial signature and an adaptor signature.
 
 Protocol
 ---
@@ -39,19 +40,16 @@ The setup phase continues with the sender setting up a tuple `(Li,yi,Ri)` consis
 
 Note that in Lightning, the sender would not directly send `(Li,yi,Ri)` to the intermediate nodes: it will instead use the payment onion to carry those values without disclosing his identity to intermediate nodes.
 
-In the update phase adjacent hops add a multisig output to their off-chain transactions similar to how they would add an HTLC output in the Lightning v1.0.
-Despite significant differences between v1.0 HTLCs and the outputs used to forward payments in scripless scripts multi-hop locks we continue to call the outputs HTLCs because they have the same purpose and work similarly on the surface.
-Just like v1.0 HTLCs, scriptless script HTLCs have a time out condition such that the left hop can reclaim her coins if the payment fails.
-But otherwise scriptless script HTLCs are plain 2-of-2 MuSig outputs and the hashlock is only implicitly added to the output when a partial signature is received (see below).
+In the update phase adjacent hops add a multisig output to their off-chain transactions similar to how they would add an HTLC output in the Lightning v1.0: we will call such outputs PTLC outputs.
+Just like v1.0 HTLCs, scriptless script PTLCs have a time out condition such that the left hop can reclaim her coins if the payment fails.
+But otherwise scriptless script PTLCs are plain 2-of-2 MuSig2 outputs and the hashlock is only implicitly added to the output when a partial signature is received (see below).
 For demonstration purposes we assume [eltoo](https://blockstream.com/eltoo.pdf)-style channels which means that both parties have symmetric state and there's no need for revocation.
 
-If the payment does not time out, the coins in the scriptless script HTLC output shared by two adjacent hops will be spent by the right hop.
-Therefore, the left hop `i` creates a transaction `txj` that spends the HTLC and sends the coins to an output that the right hop `j` controls.
-Because the left hop is now aware of the message (i.e. the transaction digest of `txj`) it is going to sign, its public signature nonce can be sent to the right hop.
-Nonce commitments may have been exchanged earlier whenever convenient for both nodes such that the nonce commitment roundtrips are not on the critical path of the payment.
+If the payment does not time out, the coins in the scriptless script PTLC output shared by two adjacent hops will be spent by the right hop.
+Therefore, the left hop `i` creates a transaction `txj` that spends the PTLC and sends the coins to an output that the right hop `j` controls.
+Nonces may have been exchanged earlier whenever convenient for both nodes such that the first round of Musig2 is not on the critical path of the payment.
 
-Upon receiving notice of the new HTLC and the left hop's public nonce, the right hop `j` creates transaction `txj` as well, combines both nonces and partially signs `txj` as `psig(j,txj,Lj)`.
-This is similar to a regular partial signature except that its left lock `Lj` is added to the combined signature nonce.
+Upon receiving notice of the new PTLC, the right hop `j` creates transaction `txj` as well, combines both nonces and partially signs `txj` as `psig(j,txj,Lj)`.
 The left hop verifies the partial signature and sends its own partial signature for `txj` to the right hop in the following two cases:
 
 - the left hop is the sender
@@ -72,8 +70,8 @@ In this case the left hop notices the combined signature and learns its right lo
 sig(tx,T) - psig(i,tx,Ri) - psig(j,tx,Lj) = adaptor_sig(j,tx,Lj) - psig(j,tx,Lj) = yj
 ```
 
-Alternatively, the right hop can send its secret `yj` directly to the left hop and request to update commitment (Lightning v1.0) or settlement (eltoo) transaction such that the HTLC is removed, the left hop's output amount is decreased by the payment amount and the right hop's output amount is increased by that amount.
-If the left hop would not follow up with an update, the right hop can still broadcast the transaction before the HTLC times out.
+Alternatively, the right hop can send its secret `yj` directly to the left hop and request to update commitment (Lightning v1.0) or settlement (eltoo) transaction such that the PTLC is removed, the left hop's output amount is decreased by the payment amount and the right hop's output amount is increased by that amount.
+If the left hop would not follow up with an update, the right hop can still broadcast the transaction before the PTLC times out.
 
 Either way, once the recipient claims the payment, the left hop learns the right lock secret, computes its left lock secret by subtracting `yi`, computes an adaptor signature, and so on until the sender learns the proof of payment `z` which completes the payment.
 
@@ -114,9 +112,9 @@ As soon as all paths are established, the recipient can compute `q` and claim th
 Batched updates
 ---
 
-In the description of the multi-hop locks flow above we assumed that adding an HTLC output is immediately followed by a signature from the right hop.
+In the description of the multi-hop locks flow above we assumed that adding a PTLC output is immediately followed by a signature from the right hop.
 However, [BOLT #2](https://github.com/lightningnetwork/lightning-rfc/blob/206084c9399abcfacdc95800acc27ebc5ca40b0c/02-peer-protocol.md#normal-operation) specifies that multiple updates (from both sides) can occur before a signature is exchanged.
-MuSig-based multi-hop locks can handle this similarly:
+MuSig2-based multi-hop locks can handle this similarly:
 
 - Each update is accompanied by a public nonce to create a signature of the transaction including the update.
 - Either left or right hop can conclude the batching phase by replying to the latest update with their public nonce and a partial signature.
@@ -129,16 +127,16 @@ Cancellable payments
 ---
 
 In Lightning v1.0, payments may be stuck for a very long time if an intermediate node goes offline while it was forwarding the payment.
-The payer cannot safely retry, because if the intermediate node goes back online before the HTLC times out, the payer may pay twice.
+The payer cannot safely retry, because if the intermediate node goes back online before the PTLC times out, the payer may pay twice.
 
 Example scenario:
 
-1. Alice sends a 10mBTC HTLC to Bob, who should forward to Dave (Alice -> Bob -> Dave).
-2. Bob receives the HTLC but does not forward anything to Dave.
+1. Alice sends a 10mBTC PTLC to Bob, who should forward to Dave (Alice -> Bob -> Dave).
+2. Bob receives the PTLC but does not forward anything to Dave.
 3. After a few blocks, Alice gets impatient and retries the payment via Carol instead of Bob (Alice -> Carol -> Dave).
 4. This payment succeeds: Alice has correctly paid 10mBTC to Dave and receives a proof-of-payment.
-5. However, Bob wakes up before his HTLC-timeout and forwards the first 10mBTC to Dave.
-6. It's free money for Dave, so Dave accepts it and the HTLC correctly fulfills.
+5. However, Bob wakes up before his PTLC-timeout and forwards the first 10mBTC to Dave.
+6. It's free money for Dave, so Dave accepts it and the PTLC correctly fulfills.
 7. Alice has received her proof-of-payment, but she paid 20mBTC instead of 10mBTC.
 
 This can be avoided if the payment needs a secret from the sender to be fulfilled.
@@ -147,8 +145,8 @@ This solution was originally introduced as [stuckless payments](https://lists.li
 The sender secret is `y0+y1+y2`. Alice MUST NOT send it to Dave during the setup phase.
 Alice does send `(z+y0+y1+y2)*G` to Dave as his left lock, which lets Dave discover `(y0+y1+y2)*G`.
 At the end of the update phase, Dave cannot create the adaptor signature because he is missing `y0+y1+y2`.
-Dave can request `y0+y1+y2` from Alice (and present `(y0+y1+y2)*G` to prove that he received the HTLC).
-When Alice receives that request, she knows that the HTLC was correctly forwarded all the way to Dave.
+Dave can request `y0+y1+y2` from Alice (and present `(y0+y1+y2)*G` to prove that he received the PTLC).
+When Alice receives that request, she knows that the PTLC was correctly forwarded all the way to Dave.
 She can now safely send `y0+y1+y2` to Dave which allows the settlement phase to begin.
 
 In case Dave does not reply and the payment seems to be stuck, Alice can now retry with another secret `y0'+y1'+y2'` (and potentially another route).
@@ -164,7 +162,7 @@ However intermediate nodes have a much bigger incentive to be online and forward
 Resources
 ---
 
-* [MuSig](https://eprint.iacr.org/2018/068.pdf)
+* [MuSig2](https://eprint.iacr.org/2020/1261)
 * [Lightning Network protocol version 1.0](https://github.com/lightningnetwork/lightning-rfc)
 * [Scripless Scripts in Lightning](https://lists.launchpad.net/mimblewimble/msg00086.html)
 * [Privacy-preserving Multi-hop Locks for Blockchain Scalability and Interoperability](https://eprint.iacr.org/2018/472.pdf)