You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: md/multi-hop-locks.md
+37
Original file line number
Diff line number
Diff line change
@@ -124,6 +124,42 @@ An adversary may not choose the latest update to reply to but instead selects a
124
124
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.
125
125
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.
126
126
127
+
Cancellable payments
128
+
---
129
+
130
+
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.
131
+
The payer cannot safely retry, because if the intermediate node goes back online before the HTLC times out, the payer may pay twice.
132
+
133
+
Example scenario:
134
+
135
+
1. Alice sends a 10mBTC HTLC to Bob, who should forward to Dave (Alice -> Bob -> Dave).
136
+
2. Bob receives the HTLC but does not forward anything to Dave.
137
+
3. After a few blocks, Alice gets impatient and retries the payment via Carol instead of Bob (Alice -> Carol -> Dave).
138
+
4. This payment succeeds: Alice has correctly paid 10mBTC to Dave and receives a proof-of-payment.
139
+
5. However, Bob wakes up before his HTLC-timeout and forwards the first 10mBTC to Dave.
140
+
6. It's free money for Dave, so Dave accepts it and the HTLC correctly fulfills.
141
+
7. Alice has received her proof-of-payment, but she paid 20mBTC instead of 10mBTC.
142
+
143
+
This can be avoided if the payment needs a secret from the sender to be fulfilled.
144
+
This solution was originally introduced as [stuckless payments](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002029.html).
145
+
146
+
The sender secret is `y0+y1+y2`. Alice MUST NOT send it to Dave during the setup phase.
147
+
Alice does send `(z+y0+y1+y2)*G` to Dave as his left lock, which lets Dave discover `(y0+y1+y2)*G`.
148
+
At the end of the update phase, Dave cannot create the adaptor signature because he is missing `y0+y1+y2`.
149
+
Dave can request `y0+y1+y2` from Alice (and present `(y0+y1+y2)*G` to prove that he received the HTLC).
150
+
When Alice receives that request, she knows that the HTLC was correctly forwarded all the way to Dave.
151
+
She can now safely send `y0+y1+y2` to Dave which allows the settlement phase to begin.
152
+
153
+
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).
154
+
If this one succeeds, she simply needs to never reveal `y0+y1+y2` and the stuck payment can never be fulfilled.
155
+
Thanks to that mechanism, Alice can safely retry stuck payments without the risk of being double-spent.
156
+
157
+
Note that this doesn't prevent the payment from being stuck during the settlement phase (if a node goes offline).
158
+
However intermediate nodes have a much bigger incentive to be online and forward during the settlement phase:
159
+
160
+
- During the update phase they're receiving bitcoins from their left peer: they haven't sent anything yet so their only incentive to forward is the fee they will collect.
161
+
- During the settlement phase they have sent bitcoins to their right peer: they now have an incentive to forward to the left peer to collect the incoming payment.
0 commit comments