Good morning Nadav, Thank you very much for this framework! It seems very good idea, kudos to making this framework.
I think, it is possible to make, a miniscript-like language for such things. Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars rather than prove your knowledge of them. > Idea 2: DLCs Routed over Lightning > Say that some DLC oracle will either broadcast s_A or s_B whose public points > are S_A and S_B (which can be computed from public information as per the DLC > scheme). Then say that Alice and Bob enter into a contract under which Alice > wins some amount if s_A is broadcasted and Bob if s_B is broadcasted. Say > Alice has a point A and Bob has a point B. They each send the other a payment > with the amount that party must receive if they win with the payment point A > + S_A for Bob's payment to Alice and B + S_B for Alice's payment to Bob. And > this is it! If s_A is broadcasted then Alice gets paid (and Bob gets proof of > payment a, which is the scalar to A), otherwise s_B is broadcasted and Bob > gets paid (with Alice receiving b as PoP). An interesting note is that under > this scheme neither party is forced to pay extra on-chain fees in the case of > a counter-party who doesn't cooperate whilst in the wrong. > One wrinkle with this scheme is that setup isn't trustless. Although it is > generally true that one party must sign the funding transaction for a DLC > before the other party for on-chain DLCs, at least there is the mitigation > that when your counter-party goes silent, you can move your input funds > invalidating the funding transaction you signed (at a cost because fees). So > what can we do here to ensure that both payments are setup at the same time > in the case that Alice and Bob don't trust each other? > Say that although they don't trust each other, they're both willing to trust > some escrow entity who generates some point E for their payment. Alice's > payment point to Bob becomes B + S_B + E and Bob's to Alice becomes A + S_A + > E. The escrow now waits to hear from Alice and Bob that they have incoming > payments setup and only once both of them attest to this (using signatures, > for example) does the escrow release the scalar to E to them both. The escrow > can also have a timeout at which it will never reveal the scalar to E: > forcing both parties to commit to the contract well before the DLC event. In > this way, trust has been moved from counter-party to trustworthy (hopefully) > escrow in such a way that the Escrow learns nothing about the contract itself > (other than that there is one of some kind). I think we can call this a "barrier escrow". * It is similar to the concept of synchronization barriers for multithread coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science) * In effect, each sub-transaction of the entire arrangement is a "thread" of operation, and the "barrier escrow" ensures that all the threads have reached it before letting them continue to claim the payments. I seem, this is applicable to *not only* DLC, but others as well. Instead, it seems to me to also provide an alternate solution to the Premium-free American Call Option Problem. Let us introduce our characters: * B, a supposed buyer, holding some Bitcoin. * S, a supposed seller, who wishes to be paid in another asset. * X, a cross-currency exchange Lightning node. * E, a tr\*sted escrow. X would like to facilitate exchanges across different assets, but wants to be paid a premium in order to prevent the Premium-free American Call Option Problem. B would like to swap its Bitcoin for another asset to pay S, and would be willing to pay the above premium, but only conditional on S actually getting the asset it wants to be paid in. X and B are non-trusting to each other, but are willing to tr\*st escrow E. This again is another "two transactions" setup, where we move tr\*st from X and B and transfer it to E. * B forwards the payment to be exchanged through X and onward to S, conditional on receiving the scalar behind `S + E`. * B gives a payment to X conditional on receiving the scalar behind `X + E`. * X continues to forward the payment, in the target asset, to S. * X contacts E and requests for the secret behind `E`. * S, on receiving the incoming payment, contacts E and requests for the secret behind `E`. * As E has now received both requests, it releases the secret simultaneously to both branches. * S and X can now claim their payments. Now, I would also like to observe the below fact: * Proof-of-payment can be reconsidered, under payment point + scalar scheme, to be "pay-for-scalar" scheme. 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. In particular, the existing High AMP scheme would be reused to implement the escrow E, and all that would be needed would be some way to request invoices from E! No additional code on top of High AMP is needed (very important, being a lazy developer is hard work). This should help make setting up new Es to be very simple, improving competition in this space and helping further ensure economically-rational behavior. If we squint, we can even say that: * This is actually a payment from B to E. * The payment is split into two paths, B->X->E and B->X->S->E. * X and S are just being paid surprisingly high fees, and are not in fact being paid premiums or payment-for-product/service. Thus, any argument that we could make, about the safety of Bass Amplifier, would also serve as an argument we could make about E behaving as we would like it to behave! This should greatly reduce the tr\*st requirement from B and X to E: they only need to trust that E operates econmically-rationally, and not trust that E will, from the goodness of its own heart, operate correctly. (A remaining issue for the above scheme is that B learns `s + e` and `x + e`, not either `s` or `x`, and thus does not actually get full proof-of-payment.) Further, this lets us extend this scheme to more than just two simultaneous transactions. If for example we need to set up 5 simultaneous transactions, and E charges 1000 millisatoshi for its service, then we just have each receiver forward 200 millisatoshi each to E once their incoming payment has been set up. In fact, the above problem, where B learns `s + e` and `x + e` but not either `s` or `x`, could be solved by splitting the payment to E three ways, with a third split from B to E, so that B learns `e` and can solve `(s + e) - e` == `s` and `(x + e) - e` == `x` to get proof-of-payment for both the actual purchase, and the premium charged by the exchange. In all of these, E remains unaware of the exact details of the arrangement, it only cares that it is paid, with the use of High AMP being the "coordination Thus this scheme is surprisingly flexible, and may solve more problems than you might think. Thank you for this insight, Nadav! Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
