Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-10 📝 Original message: Hi ZmnSCPxj, > I think, ...
📅 Original date posted:2019-10-10
📝 Original message:
Hi ZmnSCPxj,
> 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.
I've thought about this too. I've been pitching the language name as
"Improv" (since it's scriptless!). I think it would allow you to specify
the rules by which each output on each transaction can be spent and would
compile those rules into a protocol that does the secure key and signature
exchange for all the transactions in the scaffold. In other words, a
protocol compiler. I think this could be really useful for formal
specification of layer-2 protocols.
LL
On Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/0c0cc4f2/attachment.html>;
📝 Original message:
Hi ZmnSCPxj,
> 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.
I've thought about this too. I've been pitching the language name as
"Improv" (since it's scriptless!). I think it would allow you to specify
the rules by which each output on each transaction can be spent and would
compile those rules into a protocol that does the secure key and signature
exchange for all the transactions in the scaffold. In other words, a
protocol compiler. I think this could be really useful for formal
specification of layer-2 protocols.
LL
On Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/0c0cc4f2/attachment.html>;