Replies: 1 comment 1 reply
-
Ah there is one more issue to discuss: One open question is if we should use different keypairs for different networks but the same ID. I think that might be too much and as the receiver would get anyway both identical messages the re-use of the pubKey does not matter here. Over the wire the senders pubKey is part of the message for verifying the signature but as the message is encrypted in the tor/i2p layer no observer could see that anyway. When used for public messages like offers, we reveal anyway that multiple addresses (e.g. Tor+I2P) are from the same entity. I do not see a privacy concern here. There might be some weakening of the anonymity if same messages are sent over 2 networks, but I think that threat we can ignore for our context. Also users concerned about that can just use one network. Using multiple networks might potentially weaken privacy (thought I am not aware of any research about that) but increases resilience and hopefully speed. To make it more clear here is an overview of the current design (using tor as example):
In case the user supports multiple networks, we start for the same network ID multiple nodes using those networks (tor, i2p, clearnet). |
Beta Was this translation helpful? Give feedback.
-
I have a conceptual challenge and would like to ask for feedback:
The goal of the p2p network is to isolate connections so that users do not leak their identity (via reuse of an onion address) at trading.
Example:
Alice has offer1 and offer2 and decided to use the same network ID (onion address+ keys).
Bob prefers max. privacy so he has his settings defined to create a new onion address for each trade.
He takes offer1 with new ID (onion) and then offer2 with another new ID (onion).
That way Alice cannot learn that the takers of offer1 and offer2 are the same entity (if payment method data do not reveal that, for altcoin that should be no issue beside privacy leaks via chain analysis).
The downsides from the above is that when Bob takes an offer he needs to create a new onion address which takes about 10-20 sec but can be also slower. I2P seems to be faster if they choose to use I2P.
To mitigate that we could create a pool of hidden services upfront, so when he takes an offer there is already an un-used onion address available. The pool size can be rather small (e.g. 2) as take offer will take a while and in the meantime the pool will trigger recreation of a new one to have its target reached, so when Bob takes the next offer 1 min. later the pool has sufficient fresh onions again.
All that includes that client need to offer some sort of identity management. If not there would be a default one but that would have then the same privacy issues as in current bisq (onion and keys are ID).
Beside that there is another feature I wanted to discuss:
If the maker support both I2P and Tor then there will be 2 addresses in the offer and if the taker also supports both, the messages would be sent on both networks. This will lead to higher redundancy and better performance as the faster network wins. The message listeners will drop the later arriving message if the same message has already been delivered to the client. I am not sure yet if that should be built into the p2p layer but I guess so as otherwise each client need to deal with it. But as in the trade protocol it can be an expected case that messages arrive multiple times the client code base should handle such duplicated messages gracefully anyway.
For I2P I use atm SAM, a protocol to talk to the I2P app which needs to be started manually. For better integration we might consider to ship I2P (its java) but that will come with a more complex I2P setup (though SAM is also not trivial and not really nice to use) and to get reasonable perforance it requires some native bindings of some crypto/math libs. Beside that I2P seems to require longer time to start up and works better if its running long term instead of frequent startup/shutdowns. So leaving i2P running in the background independent of Misq would fulfill that better. This could be mitigated to allow users to use their already running I2P (external) and/or to allow to leave I2P process running after Bisq has been shut down - but that would require to not embed it as jars but to start it as process.
I leave that atm for later as it will be considerable effort and i want to get more experience first how stable I2P behaves once there are more complex use cases.
So why I ask for feedback is because I have the feeling the initial estimation for the effort to support multiple networks and a new address for each trade have been too optimistic. It turned out to be more complex and will add also complexity to the clients (if the benefits are used). I still think its worth it as those privacy issues in Bisq are a main weakness IMO, but wanted to get feedback and maybe someone has a more simple idea to solve the problems.
Beta Was this translation helpful? Give feedback.
All reactions