[bisq-network/proposals] Future off chain trade protocol (#32)

[sqrrm]

## Trying to make the data less public
User `A` wants to use part of a bond as security for an interaction with `B`, in this case a trade. First `A` needs to prove ownership of a bond by signing some data with the EC keys used for the bond lockup. This data is the `contract`. `A` doesn't want the `contract` to be public to everyone on the network. `A` also doesn't want the claim on the bond to be held longer than necessary.

`B` wants to verify that `A` is the bondholder and that the `contract` is correct.

`A` will sign a hash of the `contract` that includes the amount claimed towards the bond for this interaction and any other contract specifics and then publish the TransactionStartedWitness
```
String bondTxId
byte[] hashOfContract
byte[] sigA
byte[] pubkeyB
long timeout
```

`B` has the contract and can verify that the contract is correct. `B` also needs all the other contracts currently in effect for this bondTxId to be able to see the total amount the bond is already covering. `A` will provide them.

Once the transaction is done `B` publish the TransactionCompletedWitness
```
byte[] hashOfContract
byte[] sigB
```

A timeout would be needed in case `B` doesn't publish the TransactionCompletedWitness

This method would avoid displaying the amount covered by each bond but the number of transactions per bond would be open.

## Bond opreturn salt hash
It would be nicer if `bondTxId` wasn't public. A hash of a secret `salt` could be included in the opreturn of the bond transaction. The TransactionStartedWitness then includes the hash of bondTxId + `salt` instead of the clear text bondTxId. `A` will send the `salt` and bondTxId to `B` who can now verify which bond it is. Over longer running bonds there is still a risk that the `salt` becomes known to an attacker but the risks are still lower than a clear text bondTxId.
```
byte[] hashOfSaltedBondTxId
byte[] hashOfContract
byte[] sigA
byte[] pubkeyB
long timeout
```


-- 
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/32#issuecomment-416378121
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20180827/1d3efae0/attachment.html>