Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

increase privacy for SingleTX protocol #460

Open
ChrisSon15 opened this issue Aug 16, 2024 · 5 comments
Open

increase privacy for SingleTX protocol #460

ChrisSon15 opened this issue Aug 16, 2024 · 5 comments
Labels
a:proposal https://bisq.wiki/Proposals re:protocol

Comments

@ChrisSon15
Copy link

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

increasing privacy for SingleTx protocol

Overview

In the SingleTx Protocol the Deposit Tx has 2 inputs, one from Alice and one from Bob. Anyone analyzing the blockchain can learn that there is some sort of connection between these UTXOs. While there 2 inputs need to be spent in an atomic way, here is another way to connect them without revealing this connection to the blockchain. We could make 2 doposit transaction instead of one. Each of them having just one input. But them we would have to make these 2 transaction atomic by using an adaptor signature.

proposed new transaction structure

image

Note that the only differece between these transactions and the transaction from the SingleTx Protocol is that the Deposit Tx is replaced by Deposit Tx Aliceand Deposit TX Bob. The total amount of inputs and outputs is the same.

How to make sure that both transaction or none is broadcast.

This is basically an atomic swap using adaptor signature similar to what has been described in the SingleTx Protocol already. I will not repeat this here, since the description fits 1:1.
Alice will broadcast Deposit Tx Bob and by doing so she will enable Bob to broadcast Deposit Tx Alice.

Observers with access to the bisq network

An observer that has access to the blockchain and the bisq network would see all offers. Whenever an offer is not online anymore he could check the blockchain to find 2 transactions which have the amounts that fit the order.
To mitigate this, bisq should

  • not report statistics about the trades.
  • create the default deposit amount with randomness within certain bounds (maybe 15-40% random)
  • have one transaction broadcast by Alice and one by Bob, so they are not appearing on the same bitcoin node at the same time.
  • fake the removal time of the offer. Show it for some time even though its taken already. If a second trader clicks on it, then he gets a popup that the offer is unavailable (and remove it from that traders list of offers, so he cant click on it again).

Summary

With this change the protocol is technically no longer a Single Transaction protocol. But the total amount of inputs and outputs does not increase. So the increase is just the overhead of creating another transaction for the existing inputs/outputs. To construct this we need another adaptor signature scheme, which adds to the communication rounds. Since this is in the initial phase, the traders need to be online at that time anyway. So effectively it will only mean a few more seconds for the communication (if not done in parallel). It makes the protocol a bit more complicated, but not much as we use adaptor signatures anyway. The benefit would be that the 2 transactions appear to be independent for anyone looking at the blockchain. Even the amounts of both transaction appear unrelated. This would mean that bisq would have a build-in coin swap with all its privacy gains.

@suddenwhipvapor suddenwhipvapor added a:proposal https://bisq.wiki/Proposals re:protocol labels Aug 16, 2024
@HenrikJannsen
Copy link

Interesting idea!

The open question as you mentioned is if the added complexity and number of rounds plus the increased costs on miner fees (tx overhead) is worth the benefit. I assume it is, but might need more detail layout to be sure.

fake the removal time of the offer. Show it for some time even though its taken already. If a second trader clicks on it, then he gets a popup that the offer is unavailable (and remove it from that traders list of offers, so he cant click on it again).

I am not sure if that can work. If the maker is online then the taker would get the message that it is taken, but then an observer could also do that to find out about taken offers (more effort though). But if the maker is offline the taker would not have a way to find out that the offer is taken and he would need to wait for the maker getting online again to receive the decline message. That would be a very negative user experience.

@MwithM
Copy link

MwithM commented Aug 17, 2024

create the default deposit amount with randomness within certain bounds (maybe 15-40% random)

Maybe you are already referring to that, but security deposit could be randomized for each trader without hurting the incentives.

If maker decided to create an offer with 20% security deposit (as average), once taken, maker could be placing 22% security deposit while taker only places a 19% one, or any variation that stays between a range of 17-23% or whatever the gap is decided.

@ChrisSon15
Copy link
Author

If the maker is online then the taker would get the message that it is taken, but then an observer could also do that to find out about taken offers (more effort though).

That's why I use the term 'observer'. I think most data collecting organisations (like chainanalysis) are passive. This suggestion would at least exclude this class of passive observers to not learn the timing information.

But if the maker is offline the taker would not have a way to find out that the offer is taken and he would need to wait for the maker getting online again to receive the decline message. That would be a very negative user experience.

I thought if the maker is offline, then the offer is not visible any more? Of course, in case of the maker going offline we don't need to keep the offer online any more. Isn't that the case right now already?

@ChrisSon15
Copy link
Author

create the default deposit amount with randomness within certain bounds (maybe 15-40% random)

Maybe you are already referring to that, but security deposit could be randomized for each trader without hurting the incentives.

If maker decided to create an offer with 20% security deposit (as average), once taken, maker could be placing 22% security deposit while taker only places a 19% one, or any variation that stays between a range of 17-23% or whatever the gap is decided.

You are referring to the current Bisq 1 model, right? In the Single Tx Protocol, both deposit need to have the same amount, as they are swapped. So Alice gets Bob's deposit and Bob gets Alice's deposit. So I guess the maker will set it for both. But the maker can decide how high the amount is. And I am suggesting that by default the amount suggested by bisq 2 for the maker will be a random percentage.

@HenrikJannsen
Copy link

I thought if the maker is offline, then the offer is not visible any more? Of course, in case of the maker going offline we don't need to keep the offer online any more. Isn't that the case right now already?

Ah yes, sorry had too much Bisq Easy in my head...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:proposal https://bisq.wiki/Proposals re:protocol
Projects
None yet
Development

No branches or pull requests

4 participants