Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-19 📝 Original message: Hey CJP and list, Thanks ...
📅 Original date posted:2019-10-19
📝 Original message:
Hey CJP and list,
Thanks for the post!
> Maybe the problem of atomically exchanging two secrets has already been
> solved in a more elegant way (ECDH, anyone?)
I don't know of any nice way of doing this since it seems like it should be
impossible for both parties to learn something in a single action (since
one person would have to perform that action and learn nothing) though I'd
be happy to be wrong on that if anyone else on the list knows something.
But I do believe that the best that can be done is motivate one party to
act once the other party has, much like you suggest.
> * Alice locks in a Lightning tx to Bob that requires Bob to know sa and
> sb, and reveal at least sb to Alice.
> * Bob then locks in a Lightning tx, with a similar amount of funds,
> back to Alice that requires Alice to know sa and reveal sa to Bob. This
> must time out sooner than the first tx.
> * Alice redeems the second tx, revealing sa to Bob.
> * Bob redeems the first tx, revealing sb to Alice.
> Note that Bob can actually 'split the atom' by not redeeming the first
> tx, but he receives a penalty for this that roughly equals the tx
> amount. This amount can be made sufficiently large (in comparison to
> e.g. the bet) as required to move Bob's incentives towards honest
> behavior.
Very nice :) I think this approach is correct and should be successful in
the two-party binary outcome case. I'd be curious if it is possible to
extend this to multiple payments in each direction (which is how you do
more than two outcomes) and if it is possible to involve more parties as
well, though I suspect these two things are essentially the same in terms
of the process required/complexity involved.
I would say the up-side to this scheme is no third party is required, which
of course is great!
The down-side seems to be that you must temporarily over-collateralize
which means more than double the routing (and fees associated) as well as
more than double the capital requirements. I don't see this being an issue
in a micro-betting setting but in such a setting it is also a little
sub-optimal that you would have to temporarily over-collateralize and open
yourself up to grieving attacks of 2-3x a single bet's size while trying to
keep things micro in micro-betting.
> P = p*G
> Q = q*G
> SA = sa*G
> SB = sb*G
> Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB
> Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA
> Bob has to know SA to verify the value of PP_x0, and to generate PP_x1.
> I don't know if a subtract operation exists for elliptic curve points;
> in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
> just tell Bob SA, e.g. as meta-data included in the first bet tx.
Subtraction is a thing and that is indeed hou you would use it.
I will note that as a detail both of the Bet txs should also include one
more point that gets added in by the person getting paid (which can be in
an invoice or something like that) so that the scalar to that point can act
as Proof of Payment (since for example p and sa are both already known to
Alice, it is nice to have Bob add a scalar b to this, by invoicing B = b*G
before setup, so that Alice can subtract off the things she knows and get
an atomic receipt of payment).
One last detail is that I think the oracle scheme is nicest if rather than
having points P and Q with their pre-images, which is quite
lightning-specific, we instead use normal DLC oracles which pre-commit to a
public key P and a public nonce for each event R from which for each
possible signature that will be broadcasted, sig_Event, the point
sig_Event*G = R + h(event)*P can be computed and thus we can use these
signatures as our scalar pre-images :)
Best,
Nadav
On Fri, Oct 18, 2019 at 11:14 PM CJP <cjp at ultimatestunts.nl> wrote:
> (Note to IAEA & others: this is not about nuclear technology. Feel free
> to read it though.)
> (Note 2: beware of awkward misspellings like atomic secret sexchange or
> the like. I have no idea how to fix this.)
>
> Hi,
>
> I admit I spend way too little time reading this mailing list, but in
> my recent futile attempt to get up-to-date, I got inspired by the
> recent elliptic curve based smart contracting discussions. I'd like to
> present my still somewhat half-baked solution to a problem I found in
> the discussion. I believe my solution, Atomic Secrets Exchange, is
> likely to have applications beyond this particular problem. In the
> description below, I am assuming some future Lightning where elliptic
> curve payment points are already used which allow EC arithmetic.
>
> # The use case
> The problem I'm trying to solve is in the proposed protocol for placing
> bets, as described by Nadav[1]. The idea is:
>
> * There is an oracle that promises to either publish p, or publish q,
> at a certain point in time, for instance, based on some real-world
> information.
> * Alice and Bob place bets on what the oracle will publish: Alice pays
> Bob if the oracle publishes p; Bob pays Alice if the oracle publishes
> q.
> * This can be realized by locking funds in two Lightning transactions:
> one from Alice to Bob, which can be redeemed by Bob with knowledge of
> p, and one from Bob to Alice, which can be redeemed by Alice with
> knowledge of q. The time-out of these transactions must be after the
> point of publication of the oracle.
>
> The problem is that one of the two transactions will always be created
> first; if, for instance, the tx from Alice to Bob is the first, then
> Bob no longer has an incentive to create his tx to Alice. Not creating
> the second tx results in a one-sided bet; this makes it risky to take
> part in the protocol (in this case, Alice is the victim).
>
> Nadav proposed a solution with a partially trusted escrow party. I will
> try to find a solution without an escrow party.
>
> #Solution outline
> In my approach, the payment from Alice to Bob requires Bob to know p
> *and* know a secret sa, which is initially only known by Alice.
> Similarly, the payment from Bob to Alice requires Alice to know q *and*
> a secret sb, which is initially only known to Bob. As long as they
> don't reveal these secrets to anyone, these are bound to time out (or
> voluntarily canceled), even after the oracle has spoken. This makes
> them safe to be locked in in any order. After locking in the
> transactions, Alice and Bob must reveal their secrets to each other, to
> make the locked-in transactions equivalent to an honest, two-sided bet.
>
> This changes the problem of atomically locking two transactions into
> atomically exchanging two secrets.
>
> Maybe the problem of atomically exchanging two secrets has already been
> solved in a more elegant way (ECDH, anyone?), but I came up with this
> method:
>
> * Alice locks in a Lightning tx to Bob that requires Bob to know sa and
> sb, and reveal at least sb to Alice.
> * Bob then locks in a Lightning tx, with a similar amount of funds,
> back to Alice that requires Alice to know sa and reveal sa to Bob. This
> must time out sooner than the first tx.
> * Alice redeems the second tx, revealing sa to Bob.
> * Bob redeems the first tx, revealing sb to Alice.
>
> Note that Bob can actually 'split the atom' by not redeeming the first
> tx, but he receives a penalty for this that roughly equals the tx
> amount. This amount can be made sufficiently large (in comparison to
> e.g. the bet) as required to move Bob's incentives towards honest
> behavior.
>
> #Some details
> In the application of paid bets, one detail is time-outs of the three
> transactions. I believe this is the correct order:
>
> * Locking in the bet txes
> * Locking in the secrets exchange txes
> * Time-out of the secrets exchange txes
> * Publication by the oracle
> * Time-out of the bet txes
>
> Another "detail" is how to do the elliptic curve magic. This is my
> beginners' attempt:
> P = p*G
> Q = q*G
> SA = sa*G
> SB = sb*G
> Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB
> Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA
> Bob has to know SA to verify the value of PP_x0, and to generate PP_x1.
> I don't know if a subtract operation exists for elliptic curve points;
> in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
> just tell Bob SA, e.g. as meta-data included in the first bet tx.
> Similarly, Alice has to know SB to generate PP_x0; Alice could
> calculate SB = PP_b1 - Q, or Bob could tell Alice SB, e.g. as meta-data
> included in the second bet tx.
>
> CJP
>
> [1] idea 2 in https://lists.linuxfoundation.org/pipermail/lightning-dev
> /2019-October/002213.html
> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002213.html>;
>
> _______________________________________________
> 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/20191019/eab1ea4a/attachment.html>;
📝 Original message:
Hey CJP and list,
Thanks for the post!
> Maybe the problem of atomically exchanging two secrets has already been
> solved in a more elegant way (ECDH, anyone?)
I don't know of any nice way of doing this since it seems like it should be
impossible for both parties to learn something in a single action (since
one person would have to perform that action and learn nothing) though I'd
be happy to be wrong on that if anyone else on the list knows something.
But I do believe that the best that can be done is motivate one party to
act once the other party has, much like you suggest.
> * Alice locks in a Lightning tx to Bob that requires Bob to know sa and
> sb, and reveal at least sb to Alice.
> * Bob then locks in a Lightning tx, with a similar amount of funds,
> back to Alice that requires Alice to know sa and reveal sa to Bob. This
> must time out sooner than the first tx.
> * Alice redeems the second tx, revealing sa to Bob.
> * Bob redeems the first tx, revealing sb to Alice.
> Note that Bob can actually 'split the atom' by not redeeming the first
> tx, but he receives a penalty for this that roughly equals the tx
> amount. This amount can be made sufficiently large (in comparison to
> e.g. the bet) as required to move Bob's incentives towards honest
> behavior.
Very nice :) I think this approach is correct and should be successful in
the two-party binary outcome case. I'd be curious if it is possible to
extend this to multiple payments in each direction (which is how you do
more than two outcomes) and if it is possible to involve more parties as
well, though I suspect these two things are essentially the same in terms
of the process required/complexity involved.
I would say the up-side to this scheme is no third party is required, which
of course is great!
The down-side seems to be that you must temporarily over-collateralize
which means more than double the routing (and fees associated) as well as
more than double the capital requirements. I don't see this being an issue
in a micro-betting setting but in such a setting it is also a little
sub-optimal that you would have to temporarily over-collateralize and open
yourself up to grieving attacks of 2-3x a single bet's size while trying to
keep things micro in micro-betting.
> P = p*G
> Q = q*G
> SA = sa*G
> SB = sb*G
> Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB
> Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA
> Bob has to know SA to verify the value of PP_x0, and to generate PP_x1.
> I don't know if a subtract operation exists for elliptic curve points;
> in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
> just tell Bob SA, e.g. as meta-data included in the first bet tx.
Subtraction is a thing and that is indeed hou you would use it.
I will note that as a detail both of the Bet txs should also include one
more point that gets added in by the person getting paid (which can be in
an invoice or something like that) so that the scalar to that point can act
as Proof of Payment (since for example p and sa are both already known to
Alice, it is nice to have Bob add a scalar b to this, by invoicing B = b*G
before setup, so that Alice can subtract off the things she knows and get
an atomic receipt of payment).
One last detail is that I think the oracle scheme is nicest if rather than
having points P and Q with their pre-images, which is quite
lightning-specific, we instead use normal DLC oracles which pre-commit to a
public key P and a public nonce for each event R from which for each
possible signature that will be broadcasted, sig_Event, the point
sig_Event*G = R + h(event)*P can be computed and thus we can use these
signatures as our scalar pre-images :)
Best,
Nadav
On Fri, Oct 18, 2019 at 11:14 PM CJP <cjp at ultimatestunts.nl> wrote:
> (Note to IAEA & others: this is not about nuclear technology. Feel free
> to read it though.)
> (Note 2: beware of awkward misspellings like atomic secret sexchange or
> the like. I have no idea how to fix this.)
>
> Hi,
>
> I admit I spend way too little time reading this mailing list, but in
> my recent futile attempt to get up-to-date, I got inspired by the
> recent elliptic curve based smart contracting discussions. I'd like to
> present my still somewhat half-baked solution to a problem I found in
> the discussion. I believe my solution, Atomic Secrets Exchange, is
> likely to have applications beyond this particular problem. In the
> description below, I am assuming some future Lightning where elliptic
> curve payment points are already used which allow EC arithmetic.
>
> # The use case
> The problem I'm trying to solve is in the proposed protocol for placing
> bets, as described by Nadav[1]. The idea is:
>
> * There is an oracle that promises to either publish p, or publish q,
> at a certain point in time, for instance, based on some real-world
> information.
> * Alice and Bob place bets on what the oracle will publish: Alice pays
> Bob if the oracle publishes p; Bob pays Alice if the oracle publishes
> q.
> * This can be realized by locking funds in two Lightning transactions:
> one from Alice to Bob, which can be redeemed by Bob with knowledge of
> p, and one from Bob to Alice, which can be redeemed by Alice with
> knowledge of q. The time-out of these transactions must be after the
> point of publication of the oracle.
>
> The problem is that one of the two transactions will always be created
> first; if, for instance, the tx from Alice to Bob is the first, then
> Bob no longer has an incentive to create his tx to Alice. Not creating
> the second tx results in a one-sided bet; this makes it risky to take
> part in the protocol (in this case, Alice is the victim).
>
> Nadav proposed a solution with a partially trusted escrow party. I will
> try to find a solution without an escrow party.
>
> #Solution outline
> In my approach, the payment from Alice to Bob requires Bob to know p
> *and* know a secret sa, which is initially only known by Alice.
> Similarly, the payment from Bob to Alice requires Alice to know q *and*
> a secret sb, which is initially only known to Bob. As long as they
> don't reveal these secrets to anyone, these are bound to time out (or
> voluntarily canceled), even after the oracle has spoken. This makes
> them safe to be locked in in any order. After locking in the
> transactions, Alice and Bob must reveal their secrets to each other, to
> make the locked-in transactions equivalent to an honest, two-sided bet.
>
> This changes the problem of atomically locking two transactions into
> atomically exchanging two secrets.
>
> Maybe the problem of atomically exchanging two secrets has already been
> solved in a more elegant way (ECDH, anyone?), but I came up with this
> method:
>
> * Alice locks in a Lightning tx to Bob that requires Bob to know sa and
> sb, and reveal at least sb to Alice.
> * Bob then locks in a Lightning tx, with a similar amount of funds,
> back to Alice that requires Alice to know sa and reveal sa to Bob. This
> must time out sooner than the first tx.
> * Alice redeems the second tx, revealing sa to Bob.
> * Bob redeems the first tx, revealing sb to Alice.
>
> Note that Bob can actually 'split the atom' by not redeeming the first
> tx, but he receives a penalty for this that roughly equals the tx
> amount. This amount can be made sufficiently large (in comparison to
> e.g. the bet) as required to move Bob's incentives towards honest
> behavior.
>
> #Some details
> In the application of paid bets, one detail is time-outs of the three
> transactions. I believe this is the correct order:
>
> * Locking in the bet txes
> * Locking in the secrets exchange txes
> * Time-out of the secrets exchange txes
> * Publication by the oracle
> * Time-out of the bet txes
>
> Another "detail" is how to do the elliptic curve magic. This is my
> beginners' attempt:
> P = p*G
> Q = q*G
> SA = sa*G
> SB = sb*G
> Bet txes: PP_b0 = P+SA, PP_b1 = Q+SB
> Secrets Exchange txes: PP_x0 = SA+SB, PP_x1 = SA
> Bob has to know SA to verify the value of PP_x0, and to generate PP_x1.
> I don't know if a subtract operation exists for elliptic curve points;
> in that case Bob could calculate SA = PP_b0 - P. Otherwise, Alice could
> just tell Bob SA, e.g. as meta-data included in the first bet tx.
> Similarly, Alice has to know SB to generate PP_x0; Alice could
> calculate SB = PP_b1 - Q, or Bob could tell Alice SB, e.g. as meta-data
> included in the second bet tx.
>
> CJP
>
> [1] idea 2 in https://lists.linuxfoundation.org/pipermail/lightning-dev
> /2019-October/002213.html
> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002213.html>;
>
> _______________________________________________
> 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/20191019/eab1ea4a/attachment.html>;