ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-10 📝 Original message: Good morning list, and ...
📅 Original date posted:2019-10-10
📝 Original message:
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
📝 Original message:
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