(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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
