[bisq-network/proposals] Scheme for locked funds with non responsive peers (#275)

[sqrrm]

It's one extra transaction if Alice tries to take the funds with txA and Bob has to publish txAP. The extra fees is not really a problem, but it would be a problem if one of these transactions don't get confirmed. In particular, if txAP don't confirm soon enough, then Alice can broadcast txAA and then spend that output with a high fee, CPFP.

Let `_u`, `_a`, `_b`, `_ab` indicate unsigned, partially signed by alice/bob and signed transactions.

I suspect one more roundtrip, or half a roundtrip more will be needed, quick logic on it:
1. Create deposittx
1. Alice as maker creates `txP_a`, `txB_a`, `txA_u` as all info needed could be provided in an earlier message. Sends to Bob.
1. Bob signs `txP_ab`, `txA_b`, `txB_ab`. Creates `txBB_b`, `txBP_b`, sends `txP_ab`, `txA_b`, `txBB_b`, `txBP_b` to Alice. (I think this is the last step in the current protocol, both parties have `txP_ab`)
1. Alice signs `txBB_ba`, `txBP_ba`, `txA_ba`. Creates `txAA_a`, `txAP_a`. Sends `txBB_ba`, `txBP_ba`, `txAA_a`, `txAP_a` to Bob. (Alice now has `txP_ab`, `txA_ba`, `txBB_ba`, 'txBP_ba`)
1. Bob signs `txAA_ab`, `txAP_ab` and sends them to Alice. (Bob has `txP_ab`, `txB_ab`, `txBB_ba`, `txBP_ba`, `txAA_ab`, `txAP_ab`)
1. Alice receives last message and has `txP_ab`, `txA_ba`, `txBB_ba`, `txBP_ba`, `txAA_ab`, `txAP_ab`

This is one round more. It could be shortened by one step by letting both parties have access to fully signed `txA` and `txB`. Need to think more in detail if there are any other issues with who can spend what, but I don't think so. The fact that `txP_ab` is known early in the sequence is all the security they need. One party could probably have a benefit of stopping the protocol earlier, such as Bob in step 5, not sending the fully signed `txAA_ab` and `txAP_ab` to Alice, but she wouldn't publish the deposit tx in that case.

Alice could stop after step 3 when she has `txP_ab` and then publish the deposit tx. That's the current protocol. In that case Bob could choose not to send the fiat.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/275#issuecomment-719687708
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201030/b0e1292e/attachment-0001.html>