Proposal to increase liquidity on Bisq by allowing each offer to have multiple payment methods and currencies associated with it.

[pazza83]

This proposal builds on top of @wiz's proposal #201

Description

For Fiat/BTC trades Bisq currently requires each offer to be associated with one payment method and one fiat. This is a limiting factor to liquidity. A trader whishing to place multiple buy / sell offers of the same amount needs to create multiple offers.

Liquidity would be increased in an offer for a specific amount of BTC could be offered using multiple markets / payment methods by placing only one offer.

Current trade protocol limitations

Currently the trade amount of BTC and the security deposit need to allocated at the time of offer. This means that any proposal needs to work within this restraint.

This proposal is in keeping with those restraints.

Opportunities of increasing perceived liquidity

Allowing each offer to have multiple ways for trader to take the offer would increase perceived liquidity.

Currently in Bisq Alice can make an offer to sell 0.01 BTC with a 0.006 BTC security deposit on ONE market using ONE payment method. This add 0.01 BTC to the liquidity on ONE market.

This proposal would allow Alice to make an offer to sell 0.01 BTC with a 0.006 BTC security deposit on MULTIPLE markets with MULTIPLE payment methods. This would add a perceived liquidity of 0.01 BTC to MULTIPLE payment methods on MULTIPLE markets. As each offer can still only be taken the once the actual liquidity (BTC available for trade) would remain unchanged.

The limit to the above would only be the number of available payment methods and the number of compatible markets.

This would have a dramatic increase in the perceived liquidity of Bisq. Ie less traders complaining their where no offers in their markets or on their preferred payment methods.

My Liquidity Definitions

I am using these terms in a descriptive terms, therefore, I thought it would be good to define what they mean to myself.

• Actual liquidly - amount of BTC reserved in makers offers. Currently on the platform as I type this there is ~30 BTC reserved.

• Perceived liquidly - The sum of the amount of BTC shown to be available on each market. Should this proposal be implemented, perceived liquidly would increase by a multiple of a minimum of 10. Giving a perceived liquidity of ~300 BTC show as being available.

Example:

Alice is based in Switzerland she can now sell 0.01 BTC using the following markets / payment methods:

CHF; National Bank Transfer [Bank 1], National Bank Transfer [Bank 2], Revolut, TransferWise
GBP; Faster Payments, Revolut, TransferWise
EUR; SEPA [Bank 1], SEPA [Bank 2], SEPA Instant [Bank 1], SEPA Instant [Bank 2], Revolut, TransferWise
USD; National bank transfer, Revolut

Etc, etc, Alice could create an offer in every single available market on Revolut and TransferWise

Using this strategy Alice could turn her one offer appear anywhere up to 30 times without much effort.

How can this be achieved

This can be achieved though allowing traders making an offer to specify multiple payment method and markets for each trade. They will also still be able to control deviation from market price for each offer, and choose whether or not to sell a variable amount of BTC as they can now.

I have designed this from a front-end users perspective. I do not have knowledge of the code to know if this is possible on the back end.

Proposed offer screen designs

Please see proposed designs for the new offer screens as they will do a better job of explaining how this can be achieved than my words.

Sell BTC (Fixed trade amount)

Sell BTC (Variable trade amount)

Buy BTC (Fixed trade amount)

Buy BTC (Variable trade amount)

Notes on usability

The above examples are all shown with multiple offers / currencies. This adds complexity to this screen.

Please note however that when you load up the screen you will see pretty much what you already see now. You will then select your currency, and then select your payment type. The result will be a more simpler user experience that allows for additional complexities.

This would both meet the needs of trades still wanting to make just one offer and also traders that would like to make multiple offers at once.

Notes on altcoins (XMR / BSQ)

I did not consider altcoins for addition.

• XMR has the added complexity of auto confirm.
• BSQ has no option for pricing as a deviation from market amount.
• Others could work but I have not given them any consideration

[wiz]

Thanks for expanding my original proposal. As your mockups illustrate, this is a big project for Bisq, and likely requires changes to the P2P messages for offers, so implementing it will probably depend mostly on what @chimp1984 thinks :)

[Bisq-knight]

I think that's a great start. The maker side seems straight forward. How does the taker then select which of these is the one that will actually be in the contract?

I see it in multiple possible ways (also, please elaborate if I'm getting it wrong):

1. Simply use the current offer and p2p Messaging system to create multiple offers (or simply to create them in Bulk), no further changes required apart from disabling the not taken offers once one is taken. Downside here is that each offer would pay its own fee and have it's own deposit: very far from a desirable user experience, imho.
2. Adapt the actual offer model and possibly the trade protocol itself to support this more open ended offer schema (or at least this multi-offer-one-deposit scheme). This may also require us to change the taker side and expand the acceptance configuration (at the moment the only thing you can configure when taking an offer is the account to use and the amount in case of a min max offer)

Between 1 and 2, 1 might be easier to implement but terrible from a user perspective. On 2 we also need to take into account the taker side of the trade and how the protocol itself will handle that

[sqrrm]

I like the idea of allowing more than one account per offer. As @Bisq-knight mentions, the only real method to do this would be to modify the offer protocol. The mock ups are not simple but would work for power users. For casual users I suspect it would lead to more confusion with so many options to deal with while creating an offer. Some thoughts I have on how this could be done:

• Accounts could have a default flag, these accounts will be included in the offer as potential transaction accounts for the trade.
• Offers add the default accounts while created. This includes all the currencies for these accounts, but with an option to configure more specifically as suggested in the mock ups.
• The offerbook shows the offer for all filters it fits.
• Signed account status is per account so the offer size is limited by the lowest account setting, could either fail to create offers if not all accounts are valid for the size, or exclude accounts that don't allow the size as long as some account(s) do.
• 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.

[ripcurlx]

I also like this idea, but I think this will be a power user interface, as it will cause even more confusion as Bisq does for new users already. But for newbies I think we'll need a "simple" mode anyways that probably will be a complete different interface as we see it now. This is one of the tasks I'll start to work beginning of next year.

[pazza83]

How does the taker then select which of these is the one that will actually be in the contract?

I envisaged this being no different for takers. They see the offer they like and take it.

I see it in multiple possible ways (also, please elaborate if I'm getting it wrong):

1. Simply use the current offer and p2p Messaging system to create multiple offers (or simply to create them in Bulk), no further changes required apart from disabling the not taken offers once one is taken. Downside here is that each offer would pay its own fee and have it's own deposit: very far from a desirable user experience, imho.

This was not what I had in mind. The multiple offer would require only one trade amount to be funded and one security deposit, plus maker and miner fees.

2. Adapt the actual offer model and possibly the trade protocol itself to support this more open ended offer schema (or at least this multi-offer-one-deposit scheme). This may also require us to change the taker side and expand the acceptance configuration (at the moment the only thing you can configure when taking an offer is the account to use and the amount in case of a min max offer)

Yes, this is more what I had in mind. I do not understand why the user experience of taking has to be any different?

On 2 we also need to take into account the taker side of the trade and how the protocol itself will handle that

Yes, I did not consider the protocol as I do not understand the architecture of it. I was designing from a user experience perspective.

[pazza83]

The mock ups are not simple but would work for power users. For casual users I suspect it would lead to more confusion with so many options to deal with while creating an offer. Some thoughts I have on how this could be done:

The mockups show how multiple offers would work. If a trader wanted to use only one payment method with one market it would be as simple as it is now. Payment methods would be loaded one at a time at under the users control at all times.

• Accounts could have a default flag, these accounts will be included in the offer as potential transaction accounts for the trade.

Yes, I like this idea. I was thinking off a 'add offer portfolio' or 'add favorites' button or similar but wanted to keep things simple.

• Offers add the default accounts while created. This includes all the currencies for these accounts, but with an option to configure more specifically as suggested in the mock ups.

Yes, my idea was when you select currencies the payment methods available for selection would filter depending on currencies selected. This is already in place per currency market.

• The offerbook shows the offer for all filters it fits

Yes, this is what I was going for.

• Signed account status is per account so the offer size is limited by the lowest account setting, could either fail to create offers if not all accounts are valid for the size, or exclude accounts that don't allow the size as long as some account(s) do.

Yes, this would be required.

• 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.

Thanks, this goes beyond my understanding but, I am happy it might be possible.

[pazza83]

I also like this idea, but I think this will be a power user interface, as it will cause even more confusion as Bisq does for new users already. But for newbies I think we'll need a "simple" mode anyways that probably will be a complete different interface as we see it now. This is one of the tasks I'll start to work beginning of next year.

Thanks, as the payment methods would be loaded one at a time by the user. A simple trade one payment method / one currency should be no more complex than what is shown now. In fact I think it would be easier due to how I have design the switch for fixed / variable amount reducing the variables shown on screen.

[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.

[pazza83]

Thanks for the feedback.

A few people have mentioned a simpler option.

I tried designing it so it could be simple. Here is a screenshot showing a user that would place one offer to sell BTC on one market. I think it is as simple as the current version. The 'fixed / variable' toggle at the top also helps to reduce the options someone sees from what they currently see on Bisq.

[chimp1984]

The 'fixed / variable' toggle at the top also helps to reduce the options someone sees from what they currently see on Bisq.

I actually like that as when I set a fix price i can see the % immediately, making it easier to define the price.

[pazza83]

Yes, I think the variable amount setting can be confusing. Having an option to toggle it on and off would be good.

[Conza88]

Hell yes! This would help spread liquidity to lower frequented markets that appear to have no liquidity when first being investigated by newcomers... a lot leave as a result as well.

I think this is vital proposal. At the moment, I am putting and getting more offers in EUR market and I'm not based there. I suspect this will continue to grow as various payment methods like TW increase... but I feel torn, as I want to support my local market as well and have had an offer in there for some time, only to then change it to EUR and get one much quicker.

Would be fantastic to have multiple methods selected at once, and then where ever the trade was accepted gets locked in.

Definitely for this version: Adapt the actual offer model and possibly the trade protocol itself to support this more open ended offer schema (or at least this multi-offer-one-deposit scheme). This may also require us to change the taker side and expand the acceptance configuration (at the moment the only thing you can configure when taking an offer is the account to use and the amount in case of a min max offer)

In terms of too complicated, maybe current appearance is default - and advanced setting allows for complicated?

Reporting wise - you'd want to make sure the only in the market it was eventually accepted that it counts towards, not all others it was subsequently offered in.

[Conza88]

Question - does the 'options' get saved at all?

I imagine for myself, making multiple buy BTC offers - I'd be putting them in the same markets e.g. Transferwise everywhere, local market etc. etc.

Would have to re-do every time? Or last one is default for next time?

[pazza83]

Question - does the 'options' get saved at all?

Yes, if this where to be implemented I would recommend having the ability to save payment payment method profiles. It would then make it easy to add the same overs multiple times.

[Conza88]

Fantastic. Can't support this enough. Liquidity wise - makes life a lot easier for traders / those selling BTC.
Their offers in ALL markets they want to be AT the SAME TIME... and ALL those SMALL markets, locally - seeing offers available... a whole lot easier, is next level.

I am not in EUR, but I sought out EUR offers - because of liquidity. I know sellers not in EUR, but sought out EUR because became known as having liquidity.

I know locals who join a small market, and lament NO offers etc. This solves all of these problems, and more folks sticking around - spruiking Bisq.

[Conza88]

May need to redo with the offer protection?

[pazza83]

what is the offer protection?

[Conza88]

what is the offer protection?

[angubite]

It’s great so see this discussed as I have been hoping for this option for quite a while. I am no developer, just a user who is greatly thankful for this network and all it has to offer. So I’d like to share some thoughts:

Regarding complexity of user experience: I think it is important to have a simple “default layout” similar to the current one but an additional toggle to expand to “advanced options”. This does increase complexity but I still see it as a win over the complexity, risk and cost of having to create multiple offers to tap into multiple markets. I also really like the toggle to choose between fixed an variable amount.

Regarding privacy: correct me if I am wrong but currently each payment account is treated by the network as an individual, not one user with multiple accounts. So if Alice completes multiple trades with Bob using a different payment method for each trade, It is not marked as the same user, right?
If multiple payment accounts are enabled in one offer should there be privacy concerns as these accounts are publicly linked to one user? Having executed just one trade Alice has Bobs name including the information which payment methods and currencies he is participating in. Obviously, this is an option each maker can choose to use or not but I guess the aim here is to encourage best practices and inform users of privacy implications resulting from there choices.

I’d love to see this proposal pushed forward and want to thank you all for your work!

[pazza83]

Hi @angubite thanks for all the feedback.

Regarding privacy: correct me if I am wrong but currently each payment account is treated by the network as an individual, not one user with multiple accounts. So if Alice completes multiple trades with Bob using a different payment method for each trade, It is not marked as the same user, right?

Each payment account is treated as a separate payment account. The payment accounts of a particular Bisq instance are in turn linked to an onion address. The onion address is not permanent however and can be changed by the user. However if they change the onion address all the payment accounts for that particular instance of Bisq would be linked by the new onion address.

Likewise a user could have multiple instances of Bisq, multiple accounts and multiple onion addresses for each Bisq instance. For example a user could have one instance for their fiat payment accounts and one instance for their altcoin accounts. You should not however run multiple instances on the same computer. If you do you should be aware of the risks of wallet corruption in doing so.

If multiple payment accounts are enabled in one offer should there be privacy concerns as these accounts are publicly linked to one user? Having executed just one trade Alice has Bobs name including the information which payment methods and currencies he is participating in. Obviously, this is an option each maker can choose to use or not but I guess the aim here is to encourage best practices and inform users of privacy implications resulting from there choices.

Yes there are privacy concerns to be considered. But currently if Bob makes multiple offers they would have the same privacy concerns. You can currently have as many payment methods set up in Bisq as you like and if you have live offers on Bisq these would be linked to you onion address. It is not ideal but the proposal above does not affect this.

[pazza83]

Closing as stalled. Maybe implementation would be less of a problem when offers are moved to a new protocol such as Misq

[Conza88]

I believe the privacy concerns are mostly moot... recent launch of auto-deleting trade info, which can be set by user.

Closing as stalled. Maybe implementation would be less of a problem when offers are moved to a new protocol such as Misq

IMO, Bisq 2 is WAY too far off. This change is so vital to continued growth of Bisq brand in general, I really do think it needs to be done before ANY work on Misq / Bisq 2.

[apemithrandir]

My interpretation of the core issue is that we want users to leverage their reserve more, by posting conditional offers and reduce their reserve requirements as a result.

At present if you post many offers you must reserve btc for each offer. The proposal here would allow users to create a special new order type linking a single reserve to multiple conditional offers at the time of offer creation.

My concerns over the present proposal would be the added complexity and potential reduced usability of the Create Offer page. Also the length of time and work required to implement the UI changes to the Create Offer page.

There will be trade-offs with any approach, but I would like to propose a slightly different approach.

• When creating an offer you can assign a group/tag to that offer
• You could reuse that group/tag when creating new offers
• You add more btc to the reserve only if the reserve of your new offer exceeds the maximum reserve of all existing offers under that group/tag
• Every offer under that group/tag is conditional on each other being live
• If you trade one the rest will cancel and excess reserve will be returned immediately
• Some allowances should be made to reduce the fee burden of these cancelled orders (though I'm unsure how to achieve this)

This approach will preserve the maximum flexibility of setting all these features per offer:

while reducing the need to over engineer and crowd the create offer page.

Downsides would be that power users would lack the ability to easily create bulk orders in the UI. Though I would contend that a true power user should be able to do this via the API.

[ghost]

Kudos to @apemithrandir for out of the blue coming up with a solution that simplifies the UI issue.

I prefer the way you originally described it in Matrix growth room chat with your "One Cancels Other (OCO)" option - it is the simplest and most effective solution in my opinion. If the advanced user enables that feature, when creating subsequent offers that match the fee & reserve requirements of an existing offer, it will share those reserves. This can be repeated for more offers. When one of those shared offers is taken, all offers in the shared group will be automatically removed. Does not require any change to offer entry UI (perhaps an indicator to show if it is OCO eligible), and as it is an advanced feature, the user would be educated enough to understand the effects of shared offers disappearing when one is taken.

[w0000000t]

Yes, cool idea, and the way @jmacxx describes it also allows for different offers in the same group to share just the BTC amount, while premium and disable price can be customized differently; basically, no improvement is needed over this model, and as a non-java-programmer I still think this could be feasible in Bisq1 without waiting for the next big version, am I wrong?

[pazza83]

Hi @apemithrandir thanks for sharing your idea. Might be worth creating a new proposal to get maximum visibility for your suggestion. See here for general info about creating a proposal: https://bisq.wiki/Proposals

Increasing liquidity by allowing multiple offers to share the maker's security deposit / allocated trade amount would be a good move forwards.

[Conza88]

Status: Closed?

[Conza88]

How to get this into Bisq 1...