Published on: 2019-10-19T06:40:38+00:00
In a recent discussion on the Lightning network, a problem was identified in the protocol for placing bets. The issue arises when one of the two transactions is created before the other, resulting in a one-sided bet and making it risky to take part in the protocol. To address this problem, a proposed solution called the Atomic Secrets Exchange was introduced.The proposed solution involves atomically exchanging two secrets instead of locking two transactions. Both parties, Alice and Bob, must know a secret initially only known by the other party, ensuring that the transactions are bound to time out or be voluntarily canceled even after the oracle has spoken. This makes them safe to be locked in any order.To implement the solution, Alice locks in a Lightning transaction to Bob that requires Bob to know 'sa' and 'sb', with 'sa' initially known only to Alice. Similarly, Bob locks in a Lightning transaction back to Alice that requires Alice to know 'sa' and reveal it to Bob. However, Bob's transaction must time out sooner than Alice's transaction. Once the transactions are locked in, Alice redeems the second transaction, revealing 'sa' to Bob. Bob then redeems the first transaction, revealing 'sb' to Alice. If Bob chooses not to redeem the first transaction, he receives a penalty that roughly equals the transaction amount. This penalty incentivizes honest behavior from Bob.The correct order of time-outs for the three transactions is as follows: 1. Locking in the bet transactions2. Locking in the secrets exchange transactions3. Time-out of the secrets exchange transactions4. Publication by the oracle5. Time-out of the bet transactionsThe elliptic curve magic involved in the solution includes calculating P=p*G, Q=q*G, SA=sa*G, and SB=sb*G. Bob needs to know SA to verify the value of PP_x0 and generate PP_x1. Similarly, Alice has to know SB to generate PP_x0.In a discussion thread on the Lightning-dev mailing list, a user named CJP suggested an idea regarding generating PP_x1. The user was unsure if a subtract operation exists for elliptic curve points. If it does, Bob could calculate SA by subtracting P from PP_b0. Otherwise, Alice could simply tell Bob SA as metadata included in the first bet transaction. Similarly, to generate PP_x0, Alice needs to know SB. She could calculate SB by subtracting Q from PP_b1, or Bob could inform her of SB as metadata included in the second bet transaction.For further details on this proposed solution and the specific idea mentioned above, you can refer to [1] on the Lightning-dev mailing list.
Updated on: 2023-07-31T22:11:47.893763+00:00