It seems like you're introducing z2 instead of deferring to send y0+y1+y2 as in the original writeup because that allows Dave to prove that he has y0+y1+y2. How does that help though? If Dave is malicious he can just not claim the payment even if he proves knowledge of y0+y1+y2.

If Dave is malicious he can just not claim the payment

That's true, but in this case we cannot solve anything. If the recipient doesn't want to claim the payment, there's no way you'll be able to get it through. The recipient does have an incentive to claim the payment though, because it's money he's receiving (and he signaled the intent to receive that money by creating an invoice).

I think that it is indeed interesting to consider the case of a malicious recipient for some attack scenario, but in this proposal to add cancellation this is an orthogonal problem.

Forcing Dave to present y0+y1+y2 is a way to prevent spam and reduce attack surface. It forces that step to be only possible at the right moment in the protocol.
It's also a way to distinguish which payment Dave is trying to settle.
If you're trying two routes (first one with y0+y1+y2 and second one with y0'+y1'+y2') you want to only release the sender secret for one of those. We could arguably use another id, but that would waste space in the onion...

I'm not making a very strong case for this as there may be room for improvement there, but I feel it's still a small safety measure.

Forcing Dave to present y0+y1+y2 is a way to prevent spam and reduce attack surface.

My point was that spam or sending messages out of order is not really an issue if Dave can already do something worse, namely not claiming the payment. You have a fair point about attack surface, but I don't see it. The recipient can only send an ACK back if he received the onion, which proves the same to the receiver as showing y0+y1+y2 to the sender.

Distinguishing payments seems to be a clear advantage of your method. Perhaps it would also be possible to fix the original proposal in this regard by sending (y0+y1+y2)*G as part of the the ACK to distinguish the payment (the recipient can read off (y0+y1+y2)*G from the HTLC with the left hop).

In any case we don't need to write a spec here :). I think it would be very helpful to add a sentence mentioning how the original proposal differs and why.

Good points! Some more comments to enrich the discussion:

The recipient can only send an ACK back if he received the onion

That depends on how you plan on making the sender/recipient interaction :)
We don't know yet in Lightning how that will be done, it may be via an onion or something else.
I could easily see that interaction be done outside of the Lightning protocol:

• Alice is on a merchant website and wants to pay with Lightning
• The merchant website displays a QR code containing the invoice
• Alice scans it, which tries sending multiple payment attempts with different sender-side secrets
• Once the merchant receives a valid payment, the web page refreshes to offer a new QR code that contains instructions on where to send the sender-side secret (via an API call for example)
• Alice's wallet can scan this QR code, verify y0+y1+y2 and post the corresponding secret to the given URL

In that case the merchant is able to show that new QR code before he received the payment onion: so you need a way of verifying that he did receive something from Alice.

I think the goal here is to propose the most general way of doing such cancellable payments. Implementations can then add more restrictions or tweaks depending on how the sender and the recipient are able to interact.

Perhaps it would also be possible to fix the original proposal in this regard by sending (y0+y1+y2)*G as part of the the ACK to distinguish the payment (the recipient can read off (y0+y1+y2)*G from the HTLC with the left hop).

Great idea, I really like that. That means that y0+y1+y2 effectively becomes the sender-side secret (no need for a z2). I'll update the proposal to do that.

I think it would be very helpful to add a sentence mentioning how the original proposal differs and why.

I'll re-read the original proposal and do that. Cancellable payments had been floating around with this kind of construction for a while before this was posted on the mailing list: this is why there are many slightly different constructions depending on who you ask :)

It turns out that Hiroki's proposal does what you suggest, I should have re-read it :D

I could easily see that interaction be done outside of the Lightning protocol:

My imagination didn't go that far but it's not implausible.

I think the goal here is to propose the most general way of doing such cancellable payments.

Agreed. I just wanted to know why this differed from what I called the "original" proposal. I didn't know that this was folklore.

The payments can't really be cancelled (you can't cancel an HTLC one it's extended, you either need cooperation or for the time-lock to expire), so IMO a better phrase is: two-phase payments. This solves the issues of the client saying the payment didn't arrive, to get the sender to pay again, which allows them to double settle.

True. The paragraph does explain that though.