[bisq-network/proposals] Proposal to increase liquidity on Bisq by allowing each offer to have multiple payment methods and currencies associated with it. (#288)

[chimp1984]

Thanks @pazza83 for taking the time to putting a UI mock together and for bringing up the proposal!
I agree that it would increase liquidity and usability. To not make it too hard for newbies there sould be probably a different user mode as @ripcurlx mentioned.

The effort for that on the UI side should not be underestimated. The "create offer" screen is probably the most complex in the app and a bigger change here would require basically a rewrite of that code. The complexity lies in all the calculations and validations and dealing with a lot of different options...

On the data side it also comes with a profound change and I dont see any easy/good way how it could be added to the existing model. 

> Adding this on top of the current offer protocol could work by adding a new repeated account field to OfferPayload and using the first of those OfferPayloads as the data for the current message. Old clients would see only one possible account/market but new clients could parse the repeated field which would allow to trade with all those accounts.

Unfortunately no change of the existing fields is possible as the offers' hash is signed and it would fail validation by not updated peers on the p2p network layer, so they would not relay even those offers. The only flexibility is in the extraDataMap which is a hashmap for arbitrary new data. This was added to allow extensions but the required changes for that proposal would excceed the scope that field was designed for. Technically that could be hacked in (I guess) but with high costs on technical dept and added complexity, loss of type safety and readibility,....

Here are some options which come to my mind:
1. Add it to extraDataMap and client code checks for those fields and then ignore the one's in the default fields
2. Deploy multiple offers which are connected by either the offerID or some newly added parentId (to extraDataMap). This might be the least intrusive way but the network has to proccess multiple "virtual" offers. As it can be expected that more users will use that we can expect that number of offers rise a lot higher and we might hit some limits of the current p2p network capacity. We have to be aware that the p2p network does not scale well as it is a flood fill network. Offers are the dominant data and probably responsible for about 80% of the traffic. I think with having 1000 offers in the network we will see degradation of network reliability for other data (mailbox messages) which will increase rate for bugs from missing data. So I don't think that this trade off is a good one. We shift the problem to the network.
3. Extending the offer by a new MultiMarket offer data structure. Will add complexity how to mix and deal with 2 types of offers, but might be better than option 1. Old clients might not see those new offers, but that might be an acceptable compromise to avoid a hard fork. Though not sure about the implications as the offer goes though the whole trade domain and will have many impacts.
4. Do it via a protocol update. Would allow to cleanup old offer data (make it smaller, improve privacy). Complexity moves from implementation to deployment. But each protocol update carries higher risks and in the past none went really smooth.

>From dev POV I would prefer option 4, but would require more thought and investigation.... 

There are also some features for improving privacy in the pipeline: 
- Using dedicated signature and encryption key pairs per offer. That would be also difficult to deploy without some sort of protocol update. So that could/should be done in one go then.
- A dedicated onion address per offer would be another related privacy improvement but that would require a bit more research about the limitation of number of hidden services.

-- 
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/288#issuecomment-748426475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201218/1acd1bb5/attachment.htm>