Mention batched updates in multi-hop-locks

Author: jonasnick

md/multi-hop-locks.md

@@ -96,6 +96,18 @@ With scriptless script multi-hop locks it is possible to do AMP in a similarly t
 The payer sets up multiple routes to the payee using uncorrelated locks such that any partial payment claimed by the payee reveals the proof of payment (`z`) to the payer.
 Because the payee doesn't want to give up the PoP for just a partial payment, she waits until all routes to her are fully established and claims the all partial payments at once.
 
+Batched updates
+---
+In the description of the multi-hop lock flow above we assumed that adding an HTLC output is immediately followed by a signatures 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:
+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.
+
+An adversary may not choose the latest update to reply to but instead selects a different `(public nonce, transaction)`-pair from the victim's updates.
+This is not vulnerable to an attack similar to the [late message Wagner's attack](https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da) because the adversary should not be able to trick the victim into signing a transaction with a different nonce.
+Instead, the victim's nonce is tied to a specific transaction which prevents the attacker from choosing a message for signing after seeing the victim's nonce.
+
 Resources
 ---