[Research] SWAP protocol v3

[kilrau]

Continuation of https://github.com/ExchangeUnion/xud/issues/277#issuecomment-416398920:

I would like to propose to change the swap protocol for the taker to start the swap. Reason: save the SWAP_REQUEST message.

Also as @sangaman pointed out we can save all DEAL messages by sharing LND & Raiden PUBKEYs on handshake. I created an issue for this https://github.com/ExchangeUnion/xud/issues/409.

Additionally, we'll put the maker in control via a cancelSwap which it can send after the taker did initiate the swap. Please also your opinion @sangaman

0. LND & Raiden PUBKEYs get exchanged on handshake
1. Taker finds a match
2. Taker initiates the swap (includes hash, orderID, quantity in payload + which changes required to LND?) (taker initiating eliminates SWAP_REQUEST, done in https://github.com/ExchangeUnion/xud/issues/421)
3. If maker accepts, it constructs the second payment with the provided hash. If maker doesn't accept (e.g. order was cancelled in the meanwhile: send cancelSwap packet. Unilaterally cancels the swap. (which changes required to LND?)
4. Taker send the preimage to maker via payment channel to claim its funds (not in a separate message)
5. MakerLND forwards preimage to makerXUD (another change required to lnd? @offerm ), makerXUD sends it to 2nd LND, TakerLND sends it to 2nd LND (eliminates SWAP_RESPONSE, done in https://github.com/ExchangeUnion/xud/issues/421)

[sangaman]

What happens exactly in step 2? If it entails taker attempting to pay maker via lnd, I don't think this will work, because the maker won't know what to do to get the preimage from maker (namely which lnd node to pay, for how much, and in which currency/network).

I think the first step of requesting and agreeing to a deal is key. In the current flow, by the time the maker attempts to send payment over lnd, both maker and taker have agreed to and are aware of the hash, each other's lnd pub key, and the amounts that must be exchanged.

I think in the current flow, we could do without the last 2 packets. But the first packet that agrees on the specifics of the deal is the most important, and I think it makes sense to keep it as a request from taker to maker.

[kilrau]

What happens exactly in step 2

added details on that: hash, orderID, quantity in payload. That should work then!?

I think in the current flow, we could do without the last 2 packets.

As discussed in our call, I agree on this. So let's define this issue as a research task for @offerm @sangaman if it's feasible to a) pack all this into the payload and b) how substantial the changes to lnd for that would be.

Elimination of the 2 packets in the next iteration: https://github.com/ExchangeUnion/xud/issues/421

[offerm]

See comment from #421

@kilrau @sangaman hold horses on this. We are not done yet with the swap. Remember that we did the happy flow.

We still need to deal with expiry calculation of the HTLCs. For this we may need to share some information in the P2P packets (like the route and how many hopes are in route). This may also impact the decision if the maker should start the swap or the taker.

[kilrau]

New idea tbd: https://hackmd.io/s/SJ2qZUzdX#Swap-protocol-V3

[offerm]

@kilrau @sangaman is this still relevant?

[sangaman]

I don't think so. I'm pretty satisfied with how things work currently as far as the swap protocol.