{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-10-10\n📝 Original message:\nGood morning list, and Nadav,\n\n\n\u003e     I would also like to point out the below assumption, which underlies Bass Amplifier (\"multipath payments\", \"base AMP\") and its claim to atomicity:\n\u003e\n\u003e -   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.\n\u003e     -   I now call this \"economically-rational atomicity\", and describe also them mildly here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html\n\u003e\n\u003e         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.\n\u003e         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).\n\u003e         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.\n\nRight right, except an economically-rational actor will also accept a *single* payment that exceeds the price `m` miilisatoshi.\nMeaning anyone can then subvert the behavior of the barrier escrow E.\nFor 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`.\n\nFortunately, 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.\nThe 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.\n\nThat is, we can create a High AMP with the following rules for the receiver:\n\n* 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.\n  * The receiver is informed what `E` is being talked about, in some TLV to the receiver, as well as the point `Z`.\n* Every branch of the multipath also includes, in some TLV, a secret `z[i]`.\n  * `sum[i=1..n](z[i]) == z`, i.e. the sum of all the branch secrets is the secret `z` behind the point `Z`.\n* 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).\n\nSo let us reconsider the protocol:\n\n* B, S, and X generate additional keypairs `b2, B2`, `s2, S2`, and `x2, X2` respectively and give the public keys to buyer B.\n* B generates `Z` from `B2 + S2 + X2`.\n* B sends the premium payment to X, in exchange for revelation of the secret behind `X + E + Z`.\n* 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`.\n* B sends the payment to be swapped to the other asset to X, in exchange for revelation of the secret behind `S + E + Z`.\n* X swaps the asset and forwards to S, in exchange for the revelation of the secret behind `S + E + Z`.\n* 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`.\n* 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`.\n* E reconstructs `z` from `b2 + s2 + x2`, then reveals `e + z` to claim all the escrow service sub-payments.\n* X learns `e + z` and is able to reveal `x + e + z` to claim the premium.\n* S learns `e + z` and is able to reveal `s + e + z` to claim the premium.\n* 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)`.\n\nRegards,\nZmnSCPxj"}