{"type":"rich","version":"1.0","title":"Nadav Kohen [ARCHIVE] wrote","author_name":"Nadav Kohen [ARCHIVE] (npub1ge…rtua0)","author_url":"https://yabu.me/npub1geqdlge6ysz9qlq3w758422flnkgqklpu9veu80ehjprcd04ugyqkrtua0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-10-10\n📝 Original message:\nHi list and ZmnSCPxj,\n\nGlad this has been helpful and I'm not just stating obvious things :)\nalways hard to tell once the idea has been had.\n\n\u003e  I think, it is possible to make, a miniscript-like language for such\nthings.\n\u003e  Indeed, the only material difference, between SCRIPT-based\n`OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars\nrather than prove your knowledge of them.\n\nTotally agree, and furthermore, another idea I had is that if we want to\nadjust any of this to a scheme where you reveal proof of knowledge rather\nthan the scalars themselves, then rather than just a point, the parties can\nagree on a point, a nonce point, and a message and then essentially use\npay-for-signature to have Schnorr signatures revealed rather than the\nscalars themselves. This scheme even lets participants use partial\nsignatures that they can add (though there is potentially some nonce\nnastiness involved). It certainly would add complexity but is an option\nshould it ever be useful. I think. Another thought is that maybe users can\nhave one key be static (like the node id?) and have the nonce be the\n\"Payment Point\" in my scheme so that the signature is proof that this set\nof node ids has collective access to the nonce point?\n\nI really like the Premium-free American Call Option mitigation you've\ndescribed here! I totally agree that it is probably best to move to\ncomputational security rather than rational security. I hadn't thought\nabout how well High AMP inter-operates with the AND/OR scheme to make\nthings like barrier escrows :) I wonder if there is some nice\ngeneralization of this kind of setup so that being a Barrier Escrow as a\nService can be another way to make money by participating in the Lightning\necosystem. Maybe this modified High AMP is all there is to it and all we\nneed is some standard communication interface for these Barrier Escrows?\n\nBest,\nNadav\n\nOn Thu, Oct 10, 2019 at 10:15 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning list, and Nadav,\n\u003e\n\u003e\n\u003e \u003e     I would also like to point out the below assumption, which underlies\n\u003e Bass Amplifier (\"multipath payments\", \"base AMP\") and its claim to\n\u003e atomicity:\n\u003e \u003e\n\u003e \u003e -   If we agree that my secret `s` is worth `m` millisatoshi, then I (as\n\u003e a perfectly rational economic agent) will not claim any payments\n\u003e conditional on my revelation of `s` that sum up to less than `m`\n\u003e millisatoshi: I will only claim all of them when I can get multiple\n\u003e payments conditional on my revelation of `s` that sum up to `m`\n\u003e millisatoshi or more.\n\u003e \u003e     -   I now call this \"economically-rational atomicity\", and describe\n\u003e also them mildly here:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html\n\u003e \u003e\n\u003e \u003e         The above is exactly the behavior we want E to perform: only if\n\u003e it receives both requests to reveal its secret `e` behind `E`, will it\n\u003e actually reveal the secret.\n\u003e \u003e         In our case, we turn the requests to E into partial payments of\n\u003e a single invoice (though of course, the payment from S to E would be in the\n\u003e asset that S wants rather than in Bitcoin).\n\u003e \u003e         E would not like to \"sell short\" its secret `e` for less than\n\u003e the price of its service, thus if E is economically rational, it would only\n\u003e claim payments (and reveal `e`) once all incoming payments sum up to the\n\u003e price of its service.\n\u003e\n\u003e Right right, except an economically-rational actor will also accept a\n\u003e *single* payment that exceeds the price `m` miilisatoshi.\n\u003e Meaning anyone can then subvert the behavior of the barrier escrow E.\n\u003e For example, as soon as the exchange X is able to get the incoming premium\n\u003e payment conditional on release of the secret behind `X + E`, the exchange\n\u003e can simply directly send the entire payment asked by the escrow E for the\n\u003e secret behind `e` and claim the premium without actually performing the\n\u003e swap and forwarding to `S`.\n\u003e\n\u003e Fortunately,\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html\n\u003e also notes that it is possible to upgrade the High AMP with\n\u003e economically-rational security to a High AMP with\n\u003e computationally-intractable security.\n\u003e The sketch given in that link is different, but we can use a conversion\n\u003e that utilizes points and scalars in much the same way as Nadav suggests as\n\u003e part of the framework.\n\u003e\n\u003e That is, we can create a High AMP with the following rules for the\n\u003e receiver:\n\u003e\n\u003e * If the receiver knows a secret `e` behind a point `E`, payment is\n\u003e demanded in exchange for the secret `e + z` behind a point `E + Z` instead.\n\u003e   * The receiver is informed what `E` is being talked about, in some TLV\n\u003e to the receiver, as well as the point `Z`.\n\u003e * Every branch of the multipath also includes, in some TLV, a secret\n\u003e `z[i]`.\n\u003e   * `sum[i=1..n](z[i]) == z`, i.e. the sum of all the branch secrets is\n\u003e the secret `z` behind the point `Z`.\n\u003e * Thus, only once the receiver acquires all branches as incoming payments,\n\u003e will it be able to reconstruct the secret `z` and thereby claim its payment\n\u003e (and incidentally reveal `e + z`; if the ultimate payer then knows `z` it\n\u003e is able to acquire `e` as proof-of-payment).\n\u003e\n\u003e So let us reconsider the protocol:\n\u003e\n\u003e * B, S, and X generate additional keypairs `b2, B2`, `s2, S2`, and `x2,\n\u003e X2` respectively and give the public keys to buyer B.\n\u003e * B generates `Z` from `B2 + S2 + X2`.\n\u003e * B sends the premium payment to X, in exchange for revelation of the\n\u003e secret behind `X + E + Z`.\n\u003e * X sends the request to the barrier escrow E to reveal the secret behind\n\u003e `E + Z`, also providing its share of the secret behind `Z`, `x2`.\n\u003e * B sends the payment to be swapped to the other asset to X, in exchange\n\u003e for revelation of the secret behind `S + E + Z`.\n\u003e * X swaps the asset and forwards to S, in exchange for the revelation of\n\u003e the secret behind `S + E + Z`.\n\u003e * S sends the request to the barrier escrow E to reveal the secret behind\n\u003e `E + Z`, also providing its share of the secret behind `Z`, `s2`.\n\u003e * B sends the request to the barrier escrow E to reveal the secret behind\n\u003e `E + Z`, also providing its share of the secret behind `Z`, `b2`.\n\u003e * E reconstructs `z` from `b2 + s2 + x2`, then reveals `e + z` to claim\n\u003e all the escrow service sub-payments.\n\u003e * X learns `e + z` and is able to reveal `x + e + z` to claim the premium.\n\u003e * S learns `e + z` and is able to reveal `s + e + z` to claim the premium.\n\u003e * B learns `e + z`, `x + e + z`, and `s + e + z`, and is able to recover\n\u003e proof-of-payment for the premium as `(x + e + z) - (e + z)`, and\n\u003e proof-of-payment for the actual service or product as `(s + e + z) - (e +\n\u003e z)`.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191010/7b38f17c/attachment.html\u003e"}