[bisq-network/proposals] Reduce trade protocol to 1 single transaction (#279)

[Steven Barclay]

I was thinking further about the above problem of exchanging 2-of-2 private keys directly in place of nonces (caused by the delayed payout tx signature containing Alice's and Bob's payout public key(s), and therefore being unable to use any of the latter as effective keys to unlock the other party's funds). There may be a solution whereby the traders create and sign a delayed payout tx that moves just the buyer's (say Alice's) UXTO to an intermediate 2-of-2 address, together with a second, non-timelocked tx that moves both funds onward to the donation address. The latter is created in such a way that Alice doesn't learn Bob's public key when signing it (and thus only Bob holds the fully signed tx) - some special cryptographic techniques involving zero-knowledge proofs might be needed there. That way the seller (say Bob) can first move Alice's UXTO to the intermediate address in the case of a dispute and wait for it confirm. Then sending both funds onward won't have the side effect of releasing Alice's payout.

If Alice wants to raise a dispute, she would first move her funds to the intermediate address. At that point it becomes a little tricky - Alice would need to hold Bob's public key for his UXTO (which was redacted from the signature of the payment to the donation address) in an encrypted form. This would need to be decrypted by a third party, say the donation address holder himself, who would refuse to do so until at least 10 days had passed or the movement of her funds to the intermediate address had confirmed. Without that protection, she could run off with her payout before starting fiat payment to Bob. So unfortunately this weakens the security a bit, back towards that of the old arbitration scheme, as collusion between the buyer and the third party (arbitrator / donation address holder / etc.) would allow immediate theft of most of the funds.

In the happy path, when Alice starts payment, she would just send her private key to Bob's UXTO straight to him. (It would need to be a hardened private key if it had a BIP32 derivation path.) He would release either by spending his UXTO or sending Alice _his public_ key to his UXTO (which is revealed by any spend of the UXTO). From this, Bob's private key to Alice's UXTO could be calculated, say by having provided him with the private key (at the start of the trade) AES encrypted with the public key. For this to work, i.e. that Bob won't just get gibberish upon decryption, a zero knowledge proof is required.

So using zero knowledge proofs (which would be exchanged at the start of the trade), it should be possible to use standard 2-of-2 multisig p2wsh payout addresses for Alice and Bob, in place of custom payout scripts. In fact, using the secure two-party ECDSA signing algorithm described in https://github.com/bisq-network/proposals/issues/275 or the papers mentioned therein, I believe it would be even be possible to use a deposit tx with just two ordinary p2wpkh payout addresses for Alice and Bob. This would result in further tx size reductions and hopefully enhanced resistance to chain analysis. (There may be further elaborate techniques one could use to hide entropy in the payout outputs to avoid having to use an OP_RETURN output for the contract hash.)

If the aforementioned security weakening towards that of the old arbitration scheme is unacceptable, I think the best you could probably do is one p2wpkh output for the buyer and one 1-of-2 multisig p2wsh output for the seller. There might be a way round using time-lock puzzles (e.g. repeated RSA modular exponentiation) that the buyer needs to take days to complete in order to send the funds to the donation address. But I'm not sure that's practical, due to there possibly being a large speed variation between an ordinary CPU and dedicated hardware for solving the puzzle.


-- 
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/279#issuecomment-723726439
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201108/55d95536/attachment-0001.html>