rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 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