Good morning list, and Nadav,
> I would also like to point out the below assumption, which underlies Bass
> Amplifier ("multipath payments", "base AMP") and its claim to atomicity:
>
> - If we agree that my secret `s` is worth `m` millisatoshi, then I (as a
> perfectly rational economic agent) will not claim any payments conditional on
> my revelation of `s` that sum up to less than `m` millisatoshi: I will only
> claim all of them when I can get multiple payments conditional on my
> revelation of `s` that sum up to `m` millisatoshi or more.
> - I now call this "economically-rational atomicity", and describe also
> them mildly here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
>
> The above is exactly the behavior we want E to perform: only if it
> receives both requests to reveal its secret `e` behind `E`, will it actually
> reveal the secret.
> In our case, we turn the requests to E into partial payments of a
> single invoice (though of course, the payment from S to E would be in the
> asset that S wants rather than in Bitcoin).
> E would not like to "sell short" its secret `e` for less than the
> price of its service, thus if E is economically rational, it would only claim
> payments (and reveal `e`) once all incoming payments sum up to the price of
> its service.
Right right, except an economically-rational actor will also accept a *single*
payment that exceeds the price `m` miilisatoshi.
Meaning anyone can then subvert the behavior of the barrier escrow E.
For example, as soon as the exchange X is able to get the incoming premium
payment conditional on release of the secret behind `X + E`, the exchange can
simply directly send the entire payment asked by the escrow E for the secret
behind `e` and claim the premium without actually performing the swap and
forwarding to `S`.
Fortunately,
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
also notes that it is possible to upgrade the High AMP with
economically-rational security to a High AMP with computationally-intractable
security.
The sketch given in that link is different, but we can use a conversion that
utilizes points and scalars in much the same way as Nadav suggests as part of
the framework.
That is, we can create a High AMP with the following rules for the receiver:
* If the receiver knows a secret `e` behind a point `E`, payment is demanded in
exchange for the secret `e + z` behind a point `E + Z` instead.
* The receiver is informed what `E` is being talked about, in some TLV to the
receiver, as well as the point `Z`.
* Every branch of the multipath also includes, in some TLV, a secret `z[i]`.
* `sum[i=1..n](z[i]) == z`, i.e. the sum of all the branch secrets is the
secret `z` behind the point `Z`.
* Thus, only once the receiver acquires all branches as incoming payments, will
it be able to reconstruct the secret `z` and thereby claim its payment (and
incidentally reveal `e + z`; if the ultimate payer then knows `z` it is able to
acquire `e` as proof-of-payment).
So let us reconsider the protocol:
* B, S, and X generate additional keypairs `b2, B2`, `s2, S2`, and `x2, X2`
respectively and give the public keys to buyer B.
* B generates `Z` from `B2 + S2 + X2`.
* B sends the premium payment to X, in exchange for revelation of the secret
behind `X + E + Z`.
* X sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `x2`.
* B sends the payment to be swapped to the other asset to X, in exchange for
revelation of the secret behind `S + E + Z`.
* X swaps the asset and forwards to S, in exchange for the revelation of the
secret behind `S + E + Z`.
* S sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `s2`.
* B sends the request to the barrier escrow E to reveal the secret behind `E +
Z`, also providing its share of the secret behind `Z`, `b2`.
* E reconstructs `z` from `b2 + s2 + x2`, then reveals `e + z` to claim all the
escrow service sub-payments.
* X learns `e + z` and is able to reveal `x + e + z` to claim the premium.
* S learns `e + z` and is able to reveal `s + e + z` to claim the premium.
* B learns `e + z`, `x + e + z`, and `s + e + z`, and is able to recover
proof-of-payment for the premium as `(x + e + z) - (e + z)`, and
proof-of-payment for the actual service or product as `(s + e + z) - (e + z)`.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
