[bisq-network/proposals] Proposal for new trade protocol without the need for arbitrators (#52)

[Manfred Karrer]

I want to add here some discussion regaring an alternative approach using a more complex script with 2 execution paths similar like that example in https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki:
 ```
    IF
        <now + 3 months> CHECKLOCKTIMEVERIFY DROP
        <Lenny's pubkey> CHECKSIGVERIFY
        1
    ELSE
        2
    ENDIF
    <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
```
If we could implement the time lock in the deposit tx we would not need the extra handshakes required for the timelocked payout tx as descibed in the proposal but it would be one atomic tx.

But there are some drawbacks with such an approach.
But lets sketch first how such a tx would look like:
The 2 execution paths are:
Path 1: Both traders sign the 2of2 Multisig and do the payout as agreed. As soon the paypout tx is confirmed the output is spent and therefore the second path irrelevant.
Path 2: After lock time has passed the pubkey of the donation address is the receiver. As soon the donation receiver spends that output in a paypout tx the first path becomes irrelevant. 

And here we have the problem. The donation receiver would need to actively monitor and make a tx to harvest those potential funds. If he does not do that the traders can still do the payout at any time  in the future. That will destroy our feature for securing the reimbursement against scammers doing later a payout from the locked funds to themself. 

Another drawback is that if the donation receiver would make as soon as possible the payout there is no flexibility for the traders if they need more time to resolve the problem (E.g. bank delay and both want to continue just need more time).

-- 
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/52#issuecomment-432940085
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20181025/a9ed435d/attachment-0001.html>