[Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Rusty Russell rusty at rustcorp.com.au
Wed Feb 14 00:47:49 UTC 2018


Conner Fromknecht <conner at lightning.engineering> writes:
> IMHO, the current signed invoice + preimage is a very weak proof of payment.
> It's the hash equivalent to proving you own a public key by publishing the
> secret key. There is an assumption that the only way someone could get that
> preimage is by having made a payment, but this assumption is broken most
> directly by the proving mechanism. Similarly, any intermediary who acquires
> an invoice with the appropriate hash could also make this claim since they
> also have the preimage.

Agreed.

> Further, I think it's a mistake to conflate
>   1) me being able to present a valid preimage/invoice pair, with
>   2) me having received the correct preimage in response to an onion packet
>     that I personally crafted for the receiving node in the invoice.
>
> The main issue is that the proof does not bind a specific sender,
> making statement 1 producible by multiple individuals. I think it would be
> potentially worthwhile to explore proofs of stronger statements, such as 2,
> that could utilize the ephemeral keys in the onion packets, or even the
> onion as a witness, which is more rigidly coupled to having actually
> completed a payment.

Yes; this places more emphasis on the invoice's precision, eg. "I will
ship X to Y".

In practice, as we move to payment decorrelation the proof-of-payment
does half of what you suggest: only the initial payer has the necessary
proof, but it's still open-kimono if they reveal it.

Using some kind of point-supplied-in-onion to tweak result might help
here (handwave?!) since you can prove you know the secret for the point
easily without revealing it, and then AMP is simply an aggregation of
tweaks.

> TL;DR: I'm not convinced the signed invoice + hash is really a good
> yardstick
> by which to measure provability, and I think doing some research into proofs
> of payment on stronger statements would be incredibly valuable. Therefore,
> I'm not sure if AMPs really lose this, so much as force us to reconsider
> what it actually requires to soundly prove a payment to an external
> verifier.

Proof-of-payment is a unique lightning property, which I think is
terribly underrated (because we're used to not having it).  Our actions
so far have been to boltser this (hence BOLT11), and I'd hate to see us
discard it for convenience: I fear we'd never get it back!

Fortunately I think we *can* have our cake and eat it too...

Thanks,
Rusty.


More information about the Lightning-dev mailing list