[Lightning-dev] Atomic Secrets Exchange

[CJP]

(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