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

sqrrm notifications at github.com
Sat Nov 7 17:41:51 CET 2020


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

<!-- Please do not remove the text above. -->

This idea relates to the efforts to reduce the number of transactions in a trade as suggested in #265. This is not a suggestion to implement this scheme, merely describing the possibilities available.

## Core of current scheme
With the removal of taker and maker fee transactions as suggested in #265 there are still two transactions left as part of the happy path of the trade protocol, the deposit transaction where traders lock up funds in a 2of2 output, and the subsequent spending of that output to the traders payout addresses. In the unhappy path there are more transactions, where the 2of2 output is spent to the donation address and further actions are needed to recover the funds. An idea to improve on the recovery scheme is described in #275.

## Single tx scheme
The core of the idea is to lock up funds with a deposit tx with two outputs, one that can be spent by Alice and one that can be spent by Bob, but Bob holds a secret needed to spend Alice's output and Alice holds a secret needed to spend Bob's output. There is also an optional spending path, with a 2of2 by Alice and Bob. All other outputs from the the deposit tx, such as fees and change do not affect this scheme and are not considered in this description.

### Trade steps
1. Alice and Bob generate a secret nonce each, `N_a`, `N_b` respectively. They share a hash of their nonce with each other, ie, Alice sends `hash160(N_a) = H_a` to Bob and Bob sends `hash160(N_b) = H_b` to Alice.
2. The deposit tx is created taking inputs from Alice covering her part of the trade amount and deposit and from Bob covering his part. Two outputs are created, the first, `D_a`, that can be spent either by knowing `N_a`, `N_b` and Alice's privKey, or by a 2of2 of Alice and Bob. The second, `D_b`, can be spent by knowing `N_a`, `N_b` and Bob's privKey, or by a 2of2 of Alice and Bob. The scripts would look like this (my best attempt at Bitcoin scripts)
 ```
OP_HASH160 H_a OP_EQUALVERIFY OP_HASH160 H_b OP_EQUAL
OP_IF
    OP_DUP OP_HASH160 <AlicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    2 <AlicePubKey> <BobPubKey> 2 OP_CHECKMULTISIG
OP_ENDIF
```
```
OP_HASH160 H_a OP_EQUALVERIFY OP_HASH160 H_b OP_EQUAL
OP_IF
    OP_DUP OP_HASH160 <BobPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    2 <AlicePubKey> <BobPubKey> 2 OP_CHECKMULTISIG
OP_ENDIF
```
3. Alice and Bob sign a delayed payout tx that spends both of the outputs `D_a` and `D_b` in one transaction, using the multisig criterion, to the donation address.
4. When the trade is completed, Alice sends `N_a` to Bob and Bob sends `N_b` to Alice. If Bob refuses to share his nonce, there are two ways to proceed. If he spends his output, `D_b` using the nonce path, his nonce will be visible onchain. If he doesn't spend his output, the delayed payout tx can be published. The delayed payout tx cannot be spent after either output is spent since they're both required as inputs to the delayed payout tx.

## Considerations
This scheme allows for a single transaction to perform the full trade, with some caveats. If neither traders wants to move their coins after completing the trade there is a risk that the delayed payout tx could be published. There is no incentive to do so, except to cause trouble. Once one trader has moved their coins, the other can safely leave their coins as they can only be spent using the nonce option.

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201107/a258a2bb/attachment-0001.html>


More information about the bisq-github mailing list