{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-10-10\n📝 Original message:\nHi ZmnSCPxj,\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 `OP_CHECKSIG`s\nand Lightning, would be the requirement to reveal scalars rather than prove\nyour knowledge of them.\n\nI've thought about this too. I've been pitching the language name as\n\"Improv\" (since it's scriptless!). I think it would allow you to specify\nthe rules by which each output on each transaction can be spent and would\ncompile those rules into a protocol that does the secure key and signature\nexchange for all the transactions in the scaffold. In other words, a\nprotocol compiler. I think this could be really useful for formal\nspecification of layer-2 protocols.\n\nLL\n\nOn Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Nadav,\n\u003e\n\u003e Thank you very much for this framework!\n\u003e It seems very good idea, kudos to making this framework.\n\u003e\n\u003e I think, it is possible to make, a miniscript-like language for such\n\u003e things.\n\u003e Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s\n\u003e and Lightning, would be the requirement to reveal scalars rather than prove\n\u003e your knowledge of them.\n\u003e\n\u003e\n\u003e \u003e Idea 2: DLCs Routed over Lightning\n\u003e \u003e Say that some DLC oracle will either broadcast s_A or s_B whose public\n\u003e points are S_A and S_B (which can be computed from public information as\n\u003e per the DLC scheme). Then say that Alice and Bob enter into a contract\n\u003e under which Alice wins some amount if s_A is broadcasted and Bob if s_B is\n\u003e broadcasted. Say Alice has a point A and Bob has a point B. They each send\n\u003e the other a payment with the amount that party must receive if they win\n\u003e with the payment point A + S_A for Bob's payment to Alice and B + S_B for\n\u003e Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice\n\u003e gets paid (and Bob gets proof of payment a, which is the scalar to A),\n\u003e otherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as\n\u003e PoP). An interesting note is that under this scheme neither party is forced\n\u003e to pay extra on-chain fees in the case of a counter-party who doesn't\n\u003e cooperate whilst in the wrong.\n\u003e \u003e One wrinkle with this scheme is that setup isn't trustless. Although it\n\u003e is generally true that one party must sign the funding transaction for a\n\u003e DLC before the other party for on-chain DLCs, at least there is the\n\u003e mitigation that when your counter-party goes silent, you can move your\n\u003e input funds invalidating the funding transaction you signed (at a cost\n\u003e because fees). So what can we do here to ensure that both payments are\n\u003e setup at the same time in the case that Alice and Bob don't trust each\n\u003e other?\n\u003e \u003e Say that although they don't trust each other, they're both willing to\n\u003e trust some escrow entity who generates some point E for their payment.\n\u003e Alice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes\n\u003e A + S_A + E. The escrow now waits to hear from Alice and Bob that they have\n\u003e incoming payments setup and only once both of them attest to this (using\n\u003e signatures, for example) does the escrow release the scalar to E to them\n\u003e both. The escrow can also have a timeout at which it will never reveal the\n\u003e scalar to E: forcing both parties to commit to the contract well before the\n\u003e DLC event. In this way, trust has been moved from counter-party to\n\u003e trustworthy (hopefully) escrow in such a way that the Escrow learns nothing\n\u003e about the contract itself (other than that there is one of some kind).\n\u003e\n\u003e I think we can call this a \"barrier escrow\".\n\u003e\n\u003e * It is similar to the concept of synchronization barriers for multithread\n\u003e coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science)\n\u003e * In effect, each sub-transaction of the entire arrangement is a \"thread\"\n\u003e of operation, and the \"barrier escrow\" ensures that all the threads have\n\u003e reached it before letting them continue to claim the payments.\n\u003e\n\u003e\n\u003e I seem, this is applicable to *not only* DLC, but others as well.\n\u003e Instead, it seems to me to also provide an alternate solution to the\n\u003e Premium-free American Call Option Problem.\n\u003e\n\u003e Let us introduce our characters:\n\u003e\n\u003e * B, a supposed buyer, holding some Bitcoin.\n\u003e * S, a supposed seller, who wishes to be paid in another asset.\n\u003e * X, a cross-currency exchange Lightning node.\n\u003e * E, a tr\\*sted escrow.\n\u003e\n\u003e X would like to facilitate exchanges across different assets, but wants to\n\u003e be paid a premium in order to prevent the Premium-free American Call Option\n\u003e Problem.\n\u003e B would like to swap its Bitcoin for another asset to pay S, and would be\n\u003e willing to pay the above premium, but only conditional on S actually\n\u003e getting the asset it wants to be paid in.\n\u003e X and B are non-trusting to each other, but are willing to tr\\*st escrow E.\n\u003e\n\u003e This again is another \"two transactions\" setup, where we move tr\\*st from\n\u003e X and B and transfer it to E.\n\u003e\n\u003e * B forwards the payment to be exchanged through X and onward to S,\n\u003e conditional on receiving the scalar behind `S + E`.\n\u003e * B gives a payment to X conditional on receiving the scalar behind `X +\n\u003e E`.\n\u003e * X continues to forward the payment, in the target asset, to S.\n\u003e * X contacts E and requests for the secret behind `E`.\n\u003e * S, on receiving the incoming payment, contacts E and requests for the\n\u003e secret behind `E`.\n\u003e * As E has now received both requests, it releases the secret\n\u003e simultaneously to both branches.\n\u003e * S and X can now claim their payments.\n\u003e\n\u003e Now, I would also like to observe the below fact:\n\u003e\n\u003e * Proof-of-payment can be reconsidered, under payment point + scalar\n\u003e scheme, to be \"pay-for-scalar\" scheme.\n\u003e\n\u003e I would also like to point out the below assumption, which underlies Bass\n\u003e 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\n\u003e perfectly rational economic agent) will not claim any payments conditional\n\u003e on my revelation of `s` that sum up to less than `m` millisatoshi: I will\n\u003e only claim *all* of them when I can get multiple payments conditional on my\n\u003e revelation of `s` that sum up to `m` millisatoshi or more.\n\u003e   * I now call this \"economically-rational atomicity\", and describe also\n\u003e them mildly here:\n\u003e 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\n\u003e receives both requests to reveal its secret `e` behind `E`, will it\n\u003e actually reveal the secret.\n\u003e In our case, we turn the requests to E into partial payments of a single\n\u003e invoice (though of course, the payment from S to E would be in the asset\n\u003e 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\n\u003e its service, thus if E is economically rational, it would only claim\n\u003e payments (and reveal `e`) once *all* incoming payments sum up to the price\n\u003e of its service.\n\u003e\n\u003e In particular, the existing High AMP scheme would be reused to implement\n\u003e the escrow E, and all that would be needed would be some way to request\n\u003e invoices from E!\n\u003e No additional code on top of High AMP is needed (very important, being a\n\u003e lazy developer is hard work).\n\u003e This should help make setting up new Es to be very simple, improving\n\u003e competition in this space and helping further ensure economically-rational\n\u003e behavior.\n\u003e\n\u003e If we squint, we can even say that:\n\u003e\n\u003e * This is actually a payment from B to E.\n\u003e * The payment is split into two paths, B-\u003eX-\u003eE and B-\u003eX-\u003eS-\u003eE.\n\u003e * X and S are just being paid surprisingly high fees, and are not in fact\n\u003e being paid premiums or payment-for-product/service.\n\u003e\n\u003e Thus, any argument that we could make, about the safety of Bass Amplifier,\n\u003e would also serve as an argument we could make about E behaving as we would\n\u003e like it to behave!\n\u003e This should greatly reduce the tr\\*st requirement from B and X to E: they\n\u003e only need to trust that E operates econmically-rationally, and not trust\n\u003e that E will, from the goodness of its own heart, operate correctly.\n\u003e\n\u003e (A remaining issue for the above scheme is that B learns `s + e` and `x +\n\u003e e`, not either `s` or `x`, and thus does not actually get full\n\u003e proof-of-payment.)\n\u003e\n\u003e\n\u003e Further, this lets us extend this scheme to more than just two\n\u003e simultaneous transactions.\n\u003e If for example we need to set up 5 simultaneous transactions, and E\n\u003e charges 1000 millisatoshi for its service, then we just have each receiver\n\u003e forward 200 millisatoshi each to E once their incoming payment has been set\n\u003e up.\n\u003e\n\u003e In fact, the above problem, where B learns `s + e` and `x + e` but not\n\u003e either `s` or `x`, could be solved by splitting the payment to E three\n\u003e ways, with a third split from B to E, so that B learns `e` and can solve\n\u003e `(s + e) - e` == `s` and `(x + e) - e` == `x` to get proof-of-payment for\n\u003e both the actual purchase, and the premium charged by the exchange.\n\u003e\n\u003e In all of these, E remains unaware of the exact details of the\n\u003e arrangement, it only cares that it is paid, with the use of High AMP being\n\u003e the \"coordination\n\u003e\n\u003e\n\u003e Thus this scheme is surprisingly flexible, and may solve more problems\n\u003e than you might think.\n\u003e Thank you for this insight, Nadav!\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/0c0cc4f2/attachment.html\u003e"}