Multi-Currency/Multi-Payment Offers in Bisq

apemithrandir commented 1 year ago

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

I am back again. There has been increased discussion on the Growth channel about this feature and I would like to propose it again. Here is my previous proposal: https://github.com/bisq-network/proposals/issues/370 Here is @wiz's original proposal: https://github.com/bisq-network/proposals/issues/201 Here is @pazza83's related proposal: https://github.com/bisq-network/proposals/issues/288

Background

Short Version If I am a maker on Bisq the biggest restriction to me posting multiple offers is the escrow requirement for each offer. Supposing I have access to 3 different currencies and 2 different payment methods for each currency. then if I wanted to create a buy offer for each of these I would have to escrow a minimum of 15% deposit + fees for each of the 6 offers. If I am a seller this is even more restrictive as I will have to escrow a minimum of 115% deposit + fees for each of the 6 offers.

I would like to re-propose @pazza83's solution to this problem whereby you would create a special multi-payment account offer. See the other proposals for more background and discussion.

Description

@pazza83's proposal has the bulk of the details so I would refer people to: https://github.com/bisq-network/proposals/issues/288 I will make a few points of clarity in addition:

There should be a single link of on-chain transactions.
This implies each offer has the same deposit % and bitcoin amount to trade.
These offers will thus share the on-chain escrow amount.
When one is taken all others will disappear.

Technical

@chimp1984 was graceful enough to provide @pazza83's proposal with some useful technical feedback: https://github.com/bisq-network/proposals/issues/288#issuecomment-748426475

Neither myself or @pazza83 are qualified to implement this proposal, and this proposal will require more feedback from technically minded individuals.

Why Propose this Again?

I am proposing this again because most of the community agrees this would be an excellent feature to implement in Bisq in order to help bootstrap liquidity in smaller markets.

@wiz proposed this (or similar) idea over 1000 days ago, it was closed as approved but no project started. @pazza83 built on @wiz's proposal over 750 days ago, but this proposal was closed as stalled suggesting that Bisq 2.0 (or Misq as it was referred to then) might offer this improvement. Now we are close to getting a first beta version of Bisq 2.0 but this feature will not be available yet. It may be another 2 years until such features exist in Bisq 2.0, given our current developer resources.

I propose this for Bisq 1.0 again (rather than wait for Bisq 2.0) so that it can get approved and have a Development Budget allocation (as per here and here). If nobody within Bisq is willing to dedicate the time to this feature then I would like feedback from experienced contributors on how much work in Dev Days they might estimate this to take, possibly including the requirement of a new Dev to learn the codebase.

The community can then create a type of Job advertisement with the approximate DAO budget allocation plus our bounty Sats, together with details on approximate amount of work required. The community would go to market to advertise this and try and find a qualified developer(s) to join and take up the issue.

Even if this feature doesn't get implemented, I think having the budget allocation and bounty together with an advertisement will be useful to get eyes on Bisq and let qualified people know that there are paying jobs to be had working with the Bisq DAO.

Conza88 commented 1 year ago

On point. 💯👍

I have ranted endlessly about this — it removes opportunity cost for sellers, emphatically provides the ability for local markets to bootstrap long term.

Will help go to market and spread the signal.

pazza83 commented 1 year ago

Hi @apemithrandir

Thanks for revisiting this proposal.

It would be great to get this, or something like it, included in Bisq. Not sure if any of the @bisq-network/dev can comment on current feasibility?

HenrikJannsen commented 1 year ago

I fully understand and support the idea behind it, but I fear its code-wise quite a large and also risky change. I have not spent more time to look deeper into it, so maybe I am wrong, but thats my intuition about it.

apemithrandir commented 1 year ago

@HenrikJannsen thanks for the response. I would love if you were able to take some time to look closer at the proposal. Ideally what I would want is to know approximately how much work it might be and hopefully get it approved for DAO budgetting. Then take the DAO budgetting, approx. Workload and any bounties to Twitter and advertise the task to a broader community. I know as well even with this in place we are not guaranteed to progress but it would also have the added benefit of advertising Bisq to prospective developers at a time when tech companies are doing massive layoffs.

HenrikJannsen commented 1 year ago

I doubt that a new dev would be able to do that change, it touches many areas. Maybe @jmacxx could have a look for an estimation, he would be anyway probably the only dev who would be available and capable to do that.

apemithrandir commented 1 year ago

@HenrikJannsen I would trust your insights wrt to that. If @jmacxx could take a look it would be much appreciated. A DAO budget approval is my initial goal. Many community members would hopefully commit bounty Sats to supplement the DAO budget and entice implementation.

ghost commented 1 year ago

Hi @apemithrandir,

This is a 2-part estimate. Total for both: $20000.

OCO #370 I think the OCO proposal is viable in Bisq1, given that it does not require significant GUI work. It requires some refactoring of how reserved addresses are managed, one benefit is it may lead to fixing existing bugs. Estimate: 5 weeks dev+test : $5000. Caveat: "[...] having 1000 offers in the network we will see degradation of network reliability...". (chimp1984 comment.) Hence part 2, below.
Pazza's proposal #288 To overcome the network limitations, multiple offers can be specified in poweruser-created templates which are stored in the P2P network similar to how account signing info is stored. Then actual offers can be opened using the template, such that 1 real offer gets expanded to many virtual offers client-side based on the template. The virtual offers do not need to broadcast around the network, only the real ones, thus saving bandwidth. When an offer is taken, the maker is informed which virtual offer it was. This is a lot of work, even though it builds on the OCO work. It involves a lot of GUI, new P2P storage, network messages, sophisticated validation of trade limits when opening offers.
Suffice to say it could be more than 3x the size of the OCO estimate. So, $15000.

pazza83 commented 1 year ago

My vote for this would be to implement both.

I am certain once this was active it would lead to more offers being taken and would quickly result in more trade fees generated than the cost to implement.

pjakma commented 1 year ago

This would be very valuable to traders to implement.

apemithrandir commented 1 year ago

@jmacxx thanks very much for putting together that estimate. What does the procedure for getting DAO approval look like? Is this a task that would interest you to implement? If we get DAO approval I will pledge 1m Sats for part 1 and an additional 3m Sats for part 2, with a 1 year deadline attached to my bounty from the date of DAO approval.

ghost commented 1 year ago

@apemithrandir,

What does the procedure for getting DAO approval look like?

The proposals maintainer will decide after some time whether enough support has been achieved here.

@bisq-network/bisq-devs @bisq-network/dao could weigh in on whether this is a good idea for Bisq1, or too risky.

Is this a task that would interest you to implement?

Yes, I like a good development challenge and this certainly would fit! Being able to scale Bisq over 1000 offers would be a huge win IMO.

If it gets approval I hope @Pazza83 can assist with project coordination (i.e. keeping it on track, providing feedback etc).

I will pledge...

Your pledges send a strong signal for this feature. Perhaps pledges can be donated to the Bisq DAO at some point.

pazza83 commented 1 year ago

Happy to help in whatever way it can. I think it would be a big improvement for Bisq

HenrikJannsen commented 1 year ago

Thanks @jmacxx for your estimation and summary.

Here are my 5 cents...

Create a new P2P network object called `MultiOffer`

It would be a subtype of Offer and contains the list of OfferPayloads:

message MultiOffer {
    string id = 1;
    repeated OfferPayload offer_payloads = 2;
}

message Offer {
    enum State {
        PB_ERROR = 0;
        UNKNOWN = 1;
        OFFER_FEE_PAID = 2;
        AVAILABLE = 3;
        NOT_AVAILABLE = 4;
        REMOVED = 5;
        MAKER_OFFLINE = 6;
    }

    oneof message {
        OfferPayload offer_payload = 1;
        BsqSwapOfferPayload bsq_swap_offer_payload = 2;
        MultiOffer multi_offer = 3;
    }
}

That way the changes on the P2P network level are minimal and the collection of offers will be wrapped in one message. Still the message will be multiple times larger than normal offers but as we use the refresh message which only contains the hash of the payload, the extra load to the network is limited only to the adding of the new message. We still should put a limit for the max. numbers of offers in the list and maybe consider a higher offer fee to reduce ddos attack risks (there will be still extra load to the UI handling more offers, e.g. a malicious maker could spam the network with 1000s of offers with losing only a small fee (0.0005 BTC if using min. amounts).

Offer is used only in Trade and OpenOffer. The application code need to deal then with the special MultiOffer type to expand the offers as needed and provide some mapping objects.

UI

On the UI side I would recommend to keep changes as limited as possible because the create-offer screen is very complex and fragile. A larger change would probably justify a complete rewrite but that carries high risk as well and is a huge effort. But I guess it could be done by using a new option checkbox which then allows repeated create offer screens maybe with pre-filled text from the previous edited offer. Once done, then the funding screen can be shown using the highest amount of all the offers for fees and deposits. Not 100% sure if thats the best approach but would be my first try. It might not be that user-friendly as @pazza laid it out but as it is mostly for pro-traders I think usability can be sacrified a bit in favor of reduced effort and risks. Also it might be difficult to support enabling/disabling of offers which are part of the multi-offer. If it turns out its not easy to do, we could alternatively edit a multi-offer and allow in the edit UI to delete single offers in that group.

Acount signing

The account signing limitations are something to consider as well. I guess we need to handle it per payment method. E.g. if the trader has no limits for SEPA but is not signed yet for Revolut, the max. amounts for Revolut are according to the limits and lower than SEPA.

Reserved for trade funds/fees

I would suggest to not change anyting in that area and just use the highest amount offer as base for the required locked up funds and fees. If a lower amount offer will be taken there is anyway already support for a change output (same as with min/max amount offers).

Maybe @pazza83 and @apemithrandir can provide feedback if they consider some extra/higher maker fee as justified. It would serve as ddos protection and to ensure the feature is used in an efficient manner. If traders would over-use it it could also have negative experience to takers. E.g. If a maker has a huge amount of offers, each time a taker takes an offer all others get blocked which could lead to the stitaution that when there are multiple take-offer attempts at roughly the same time only one will succeed. Another issue is that lots of offers gets removed after the offer is taken. Due the network delay other takers might click take offer and lose time until they find out the offer is already removed. So I think there might be some potential for negative user experience if the feature is over-used. To limit that we can use both a limit of max offers in a multi-offer object as well as additional fees. Can you provide feedback what from your point would be a healthy number of offers and if some extra fee would be acceptable, and if so what would be the amount?

Deployment

For deployment we need a new capability entry for the new message type. I am not sure if that is sufficient as the p2p network data are packed into the BundledMessages and not sure if the capability checks are fully supporting that case. If not I think we need to use an activation data and pre-deploy it while still not being activated and use a forced update before activation date.

As there will be many open design questions which might only become fully visible during development, I would suggest a prototype branch and if that has solved all core aspects to apply the changes to a new new clean PR.

There will be for sure more things to consider, but that was what comes to my mind thinking a bit about it...

pazza83 commented 1 year ago

Thanks @HenrikJannsen

A limit for max offer would work well. No one needs to be creating thousands of offers at once. Not sure about number for a limit but initially I think around 20 would be sufficient.

With regards a higher fee, whilst I am not against it on principle, I do not think the fee will be the barrier to spam. Most offers of around 0.01 BTC the amount most frequently traded on Bisq will have the largest proportion of the offer cost made from the miner rather than the trade fee. This would still be the case is doubling or trebling the maker cost. I also think the additional number trade revenue generated for Bisq with multi offers will increase the total amount of trades completed so fees for multi offers should only be higher if the network burden for handling them is higher (eg increased requirement for more nodes).

Agree with the points regarding UI. Happy to work with @jmacxx to mock something up that will work for traders and keep complexity as low as possible for implementation.

Agree about only allowing editing rather than individual offer enabling / disabling in the multi offers. Otherwise a user could just continue to add offers to the multi offer.

Agree that any in included offer a selected account signing limit should limit the highest offer available to make.

Maybe @pazza83 and @apemithrandir can provide feedback if they consider some extra/higher maker fee as justified.

Yes, but not for DDOS, more for if network costs are higher.

Can you provide feedback what from your point would be a healthy number of offers.

I think even 20 most pro traders will have less than 20 payment methods to choose from. If they have more it would be likely they are just creating multi trades using the same payment method but different accounts (more spammy).

Maybe the limit could be max 1 payment accounts per payment method but up to 20 payment accounts in total.

Eg ok to have; SEPA, SEPA Instant, Revolut, Wise, Faster Payments, National Bank not ok to have; SEPA 1, SEPA 2, SEPA 3... etc

If some extra fee would be acceptable, and if so what would be the amount?

Yes, would the number of offers be proportional to the network costs of propagating them to the network?

If a maker has a huge amount of offers, each time a taker takes an offer all others get blocked which could lead to the situation that when there are multiple take-offer attempts at roughly the same time only one will succeed.

I think reducing the max offers to 20 will limit this. But yes, it would be good to see failed trades not increase as a result. Maybe the estimated cost of this could also be included in any increased maker fee.

apemithrandir commented 1 year ago

I agree with @pazza83 on limiting to ~20 offers. If possible I would like to avoid a higher fee since once people become comfortable with the feature I could imagine even the casual user making a 2-4 offer type as default, eg EUR: Sepa+SepaInstant+Revolut+Wise. @Conza88 may have some opinions on this.

Conza88 commented 1 year ago

@Conza88 may have some opinions on this.

Yes, to put it mildly. 😄 Definitely appreciate the fine tooth combing and well thought out considerations in order to make this a reality (achieve said goals).

@jmacxx 's proposal and doing both: 👌 .

Am I right that then @HenrikJannsen's suggestion of multi-offer object, completely changes that/different route? Or just gives more detail?

We still should put a limit for the max. numbers of offers in the list and maybe consider a higher offer fee to reduce ddos attack risks (there will be still extra load to the UI handling more offers, e.g. a malicious maker could spam the network with 1000s of offers with losing only a small fee (0.0005 BTC if using min. amounts).

Why?

Is this just based on your proposal, or @jmacxx 's?

Given this makes it sound like the above is a non-issue:

To overcome the network limitations, multiple offers can be specified in poweruser-created templates which are stored in the P2P network similar to how account signing info is stored. Then actual offers can be opened using the template, such that 1 real offer gets expanded to many virtual offers client-side based on the template. The virtual offers do not need to broadcast around the network, only the real ones, thus saving bandwidth. When an offer is taken, the maker is informed which virtual offer it was.

If the above Jmacxx is the approach, how can old mate ddos spam the network? What is the risk with all those offers providing possibly liquidity to the network?

If it is the one same guy, could just block onion address - yes? If someone thought the offers were 'spam'?

It would serve as ddos protection and to ensure the feature is used in an efficient manner. If traders would over-use it it could also have negative experience to takers. E.g. If a maker has a huge amount of offers, each time a taker takes an offer all others get blocked which could lead to the stitaution that when there are multiple take-offer attempts at roughly the same time only one will succeed.

Well is there a way to for instance you have X in security deposit, or certain amount secured in reserve and the marker seller has all their offers out there --- and say they have 1 Bitcoin to sell... their offers can keep getting accepted until that limit is reached? I don't know whether this is the ideal - but absolutely I think it'd be preferable to CAPPING the number of max currencies/payment methods.

I don't think anyone is going to 'go select them all' but I certainly want the option e.g. SWIFT and don't care what currency, I should be able to offer that globally - and everyone sees in local market that option.

Another issue is that lots of offers gets removed after the offer is taken. Due the network delay other takers might click take offer and lose time until they find out the offer is already removed. So I think there might be some potential for negative user experience if the feature is over-used.

Local markets basically don't exist... I think this likelihood currently is very rare/non-existent. The offers taken would then disappear the others before being noticed/impacted. No liquidity and thus LEAVING BISQ FOREVER is a worse experience surely?! That omg, I tried to take an offer and someone got to it before I did... damn... I'll have to click this OTHER OFFER IN MY LOCAL MARKET BECAUSE IT ACTUALLY EXISTS NOW vs. not prior to this change.

Benefits clearly outweigh the negatives.

In general - lower fee's is important for additional benefits of using Bisq vs. CEX. Obviously single on chain transaction helps there (why supported previously). If as per Jmacxx's comment, no network increase - shouldn't be a reason for higher fees at all.

I don't like the idea of a quota limits... the idea of capping it at 20... I think this neuters the point of removing opportunity cost, and impacts the ability to boot-strap local markets globally... so it'll be what, top 20 markets getting an idea, and the rest won't...

Surely there are other ways to mitigate/remove ddos risk? Capping the limit of offers; if there isn't a burden on the network (Jmacxx comments) should be the last resort; certainly not the first.

apemithrandir commented 1 year ago

@Conza88 Some limit makes sense, since with a hacked API you couod code up a 1 million payment offer and god knows how that would propagate through the messaging system.

apemithrandir commented 1 year ago

@HenrikJannsen @jmacxx what are the next steps to seek DAO approval?

pazza83 commented 1 year ago

@HenrikJannsen @jmacxx what are the next steps to seek DAO approval?

Here is a link to to proposal process: https://bisq.wiki/Proposals

I will announce this proposal in my proposal report later this month.

After that will review the response to it. So far it is looking positive and likely to be approved.

Conza88 commented 1 year ago

@Conza88 Some limit makes sense, since with a hacked API you couod code up a 1 million payment offer and god knows how that would propagate through the messaging system.

Understandable. Perhaps the limit is 180 then? 😆

"There are currently some 180 fiat currencies in the world today. The value of fiat currencies is driven by the forces of supply and demand. Central banks like the Federal Reserve set monetary policy to control the supply, gauging how much money is needed in the economy and printing accordingly."

It goes without saying anything is better than nothing, but I want to avoid needlessly artificially limiting the potential.

E.g. SWIFT enables trading fiat globally. I want to see an offer in the Fiji local market/currency because there's no opportunity cost to not do so for sellers internationally. Bringing liquidity to these local markets helps them then organically bootstrap.

Capping it at 20, in my mind is essentially: 🖕 to the other 160. It knee caps the real potential of the initiative.

apemithrandir commented 1 year ago

@Conza88 Good to see I have negotiated you from infinity to 180. Also not to put you on the spot but are you willing to offer any bounty Sats to help incentivise the work (conditional on DAO approval of course)?

Conza88 commented 1 year ago

@Conza88 Good to see I have negotiated you from infinity to 180. Also not to put you on the spot but are you willing to offer any bounty Sats to help incentivise the work (conditional on DAO approval of course)?

😂 Conditioned upon the informed parameters above being fulfilled, sure.

pazza83 commented 1 year ago

180 is a lot :)

Just looking at the markets section on Bisq now.

There are currently approximately 400 fiat offers.

180 for a single offer would be almost half this! If someone would make a few 180 offers it would quickly spam the network.

Also not sure if anyone actually has access to 180 currencies with any payment apart from SWIFT, and the way SWIFT is implemented means that a user from almost any currency can take a SWFIT offer.

@Conza88 what did you have in mind for a real world scenario of someone making 180 offers at once for all different currencies?

apemithrandir commented 1 year ago

@HenrikJannsen @jmacxx what are the next steps to seek DAO approval?

Here is a link to to proposal process: https://bisq.wiki/Proposals

I will announce this proposal in my proposal report later this month.

After that will review the response to it. So far it is looking positive and likely to be approved.

Great! Make sure to link your proposal report when you get it done.

WRT to this comment your latest comment: My hope would be that this feature would lead to 100s if not 1000s of more legitimate offers being created on Bisq (even with a "low" per offer limit). Do we know what the network limitations are like? Is there any way to benchmark it? Or is it a function of Tor (un)reliability?

pazza83 commented 1 year ago

Great! Make sure to link your proposal report when you get it done.

Here is the link to the report: https://github.com/bisq-network/roles/issues/30#issuecomment-1421339224

Would be great for those interested to give a thumbs up / thumbs down and any feedback.

pazza83 commented 1 year ago

WRT to this comment your latest comment: My hope would be that this feature would lead to 100s if not 1000s of more legitimate offers being created on Bisq (even with a "low" per offer limit).

I think allowing 20 payment methods per trade will enable this.

I assume pareto principle will be roughly true for Bisq. 80% of offers come from 20% of users. Allowing these 'power users' the tools to substantially increase the number of offers by 20 times without any increase in security deposit / trade amount requirements will see the number of offers increasing substantially.

As far as goals, I would like to see Bisq hit 2,500 offers within 6 months of this being implemented. Currently it is around 600 offers at any one time.

I also think that with the new offers comes more takers and hopefully this will be a self fulfilling increase in trade amounts.

Do we know what the network limitations are like? Is there any way to benchmark it? Or is it a function of Tor (un)reliability?

This would be best answered by @jmacxx or @HenrikJannsen

apemithrandir commented 1 year ago

I know @Conza88 is an extremist but i agree that 20 is sufficient for a first take. It should be parameterized and if we get feedback that users want more than 20 we can make that change. With DDOS attacks in TOR (and now I2P as well) we can't rule out malicious actors spamming the network.

Conza88 commented 1 year ago

180 for a single offer would be almost half this! If someone would make a few 180 offers it would quickly spam the network.

Except it wouldn't be spam; it'd be legitimate offers of liquidity...

There are currently approximately 400 fiat offers.

So 50 offers per fiat one; 20,000 offers across all payment methods/fiat... if the original way of storing outlined by @jmacxx is in place though - stored locally like account info, where is the cost to the network / issue?

If it is - 'sorry, your offer was taken'... its a better problem to have, than 'there is nothing here in this market, so I will leave... and never come back' - surely? Because that is the reality right now, and that is what this is ultimately solving.

Also not sure if anyone actually has access to 180 currencies with any payment apart from SWIFT, and the way SWIFT is implemented means that a user from almost any currency can take a SWFIT offer.

Do they appear locally in that local market though?

@Conza88 what did you have in mind for a real world scenario of someone making 180 offers at once for all different currencies?

Thought it unlikely; but that's not good enough reason to impose a hard cap limit imo. It was a seller not caring who takes it, whatever the fiat is - getting the equivalent for bitcoin... knowing they're helping bootstrap whatever local market there is e.g. Fiji getting love, Zimbabwe etc.

I know @Conza88 is an extremist but i agree that 20 is sufficient for a first take. It should be parameterized and if we get feedback that users want more than 20 we can make that change. With DDOS attacks in TOR (and now I2P as well) we can't rule out malicious actors spamming the network.

I will accept 50 for a first take.

apemithrandir commented 1 year ago

180 for a single offer would be almost half this! If someone would make a few 180 offers it would quickly spam the network.

Except it wouldn't be spam; it'd be legitimate offers of liquidity...

There are currently approximately 400 fiat offers.

So 50 offers per fiat one; 20,000 offers across all payment methods/fiat... if the original way of storing outlined by @jmacxx is in place though - stored locally like account info, where is the cost to the network / issue?

If it is - 'sorry, your offer was taken'... its a better problem to have, than 'there is nothing here in this market, so I will leave... and never come back' - surely? Because that is the reality right now, and that is what this is ultimately solving.

Also not sure if anyone actually has access to 180 currencies with any payment apart from SWIFT, and the way SWIFT is implemented means that a user from almost any currency can take a SWFIT offer.

Do they appear locally in that local market though?

@Conza88 what did you have in mind for a real world scenario of someone making 180 offers at once for all different currencies?

Thought it unlikely; but that's not good enough reason to impose a hard cap limit imo. It was a seller not caring who takes it, whatever the fiat is - getting the equivalent for bitcoin... knowing they're helping bootstrap whatever local market there is e.g. Fiji getting love, Zimbabwe etc.

I know @Conza88 is an extremist but i agree that 20 is sufficient for a first take. It should be parameterized and if we get feedback that users want more than 20 we can make that change. With DDOS attacks in TOR (and now I2P as well) we can't rule out malicious actors spamming the network.

I will accept 50 for a first take.

Negotiated from infinity to 180 to 50. Not bad.

apemithrandir commented 1 year ago

@pazza83 @jmacxx Is this proposal gonna get approved this cycle? Anything I can do to help?

pazza83 commented 1 year ago

I will plan to update the status of the proposal at the start of cycle 45, about 1 weeks time.

Looking like it will be approved as comments / thumbs ups etc are in favor of the proposal.

pazza83 commented 1 year ago

Marking this proposal as approved but will leave it open for the moment for any discussion to continue

apemithrandir commented 1 year ago

@jmacxx just gave myself and @pazza83 a demo of a beta version of the new OCO feature. Worked really well with limited changes to the UI. User creates an offer as per usual. Then from the open offers page you right click on that offer and you can clone it. Then from the cloned offer you can edit the payment type, % deviation and currency pair! Seamless interaction. All offers become live when enabled across different payment types and/or currency pairs, sharing the same maker tx id and reserve! Will still take some time to get it through code review and DAO approval but great steps in the right direction to improve liquidity on Bisq!

pazza83 commented 1 year ago

Yes, the demo of the OCO feature was fantastic. Will be a great addition for both makers and takers.

Makers get to use their security deposit for multiple offers and takers get the advantage of lots more offers to choose from.

Really excited about how this will increase trade volume when implemented,

Conza88 commented 1 year ago

Question - what's the situation with "sorry the offer is taken"?

E.g. I have no idea how quickly it gets updated currently, vs. any difference for this?

Now: E.g. an offer might get taken and it takes 10seconds to sync and remove from being offered in payment methods/fiat currency area.

What happens when someone takes on the interim? Error message? Or takes it but failed trade?

How's that look with the new oco?

From: pazza @.> Sent: Saturday, March 4, 2023 2:31:54 AM To: bisq-network/proposals @.> Cc: Conza @.>; Mention @.> Subject: Re: [bisq-network/proposals] Multi-Currency/Multi-Payment Offers in Bisq (Issue #402)

Yes, the demo of the OCO feature was fantastic. Will be a great addition for both makers and takers.

Makers get to use their security deposit for multiple offers and takers get the advantage of lots more offers to choose from.

Really excited about how this will increase trade volume when implemented,

— Reply to this email directly, view it on GitHubhttps://github.com/bisq-network/proposals/issues/402#issuecomment-1453704825, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMMLWYUNWFLK6OD33GKUC3LW2IFGVANCNFSM6AAAAAAT26MAWI. You are receiving this because you were mentioned.Message ID: @.***>

apemithrandir commented 1 year ago

Question - what's the situation with "sorry the offer is taken"? E.g. I have no idea how quickly it gets updated currently, vs. any difference for this? Now: E.g. an offer might get taken and it takes 10seconds to sync and remove from being offered in payment methods/fiat currency area. What happens when someone takes on the interim? Error message? Or takes it but failed trade? How's that look with the new oco?

These issues are hard to reveal in the basic tests shown thus far but @jmacxx might be able to comment from a code perspective. For the most part Bisq is unchanged and just sees extra offers and cancels cloned offers that share the maker tx id. I hope it doesn't result in more failed trades but I suspect there would always be a race condition there.

The look is good if you like what Bisq looks like already. The UI is mostly unchanged aside from a right-click menu on the open offers page.

pazza83 commented 1 year ago

Yes, I think what would happen is the same as when one trade tries to get taken by two people at once.

I think one taker would get the trade, and the other would get the trade timing out with the message after a while saying the trade is no longer available.

ghost commented 1 year ago

https://user-images.githubusercontent.com/47253594/223172632-2eaaffe1-8c01-42a2-917a-b67423a46bb4.mp4

pjakma commented 1 year ago

Question - what's the situation with "sorry the offer is taken"? E.g. I have no idea how quickly it gets updated currently, vs. any difference for this? Now: E.g. an offer might get taken and it takes 10seconds to sync and remove from being offered in payment methods/fiat currency area. What happens when someone takes on the interim? Error message? Or takes it but failed trade? How's that look with the new oco?

These issues are hard to reveal in the basic tests shown thus far but @jmacxx might be able to comment from a code perspective. For the most part Bisq is unchanged and just sees extra offers and cancels cloned offers that share the maker tx id. I hope it doesn't result in more failed trades but I suspect there would always be a race condition there.

The look is good if you like what Bisq looks like already. The UI is mostly unchanged aside from a right-click menu on the open offers page.

Sounds like this "race" is no different to the existing case where 2 takers could take an offer at about same time? One gets it, and the other can not - what happens for them? Does the same happen in this cloned offer case?

This is great work by the way. This is going to be a huge multiplier of liquidity for Bisq, if it can be integrated. Thank you very much.

HenrikJannsen commented 1 year ago

Another option for implementing this feature would be to create a new payment method for wrapping multiple payment methods inside. That way its still one offer and there are no changes on the network layer required. The UI would take the sub-payment methods and apply the filtering and display. We support already multiple currencies for certain payment methods, so that part should not add much on the UI side. For showing the multiple payment methods we would need some new graphical representation in the offerbook table. When the user filters or searches it gets applied to all sub methods.

Pro: It would reduce a lot implementation complexity and risks.

Con: It would not allow to use different prices and only percentage based price.

apemithrandir commented 1 year ago

Another option for implementing this feature would be to create a new payment method for wrapping multiple payment methods inside. That way its still one offer and there are no changes on the network layer required. The UI would take the sub-payment methods and apply the filtering and display. We support already multiple currencies for certain payment methods, so that part should not add much on the UI side. For showing the multiple payment methods we would need some new graphical representation in the offerbook table. When the user filters or searches it gets applied to all sub methods.

Pro: It would reduce a lot implementation complexity and risks.

Con: It would not allow to use different prices and only percentage based price.

When you say it would not allow to use difference prices, does that mean you couldn't do multiple currencies? I think that the payment types that support multiple currencies are not that popular and the main idea for using this idea to expand usage is that people would pair an offer in a liquid fiat/BTC market with one in a less liquid fiat/BTC market. The likelihood of the payment types matching would be low.

HenrikJannsen commented 1 year ago

When you say it would not allow to use difference prices, does that mean you couldn't do multiple currencies?

With % based price we can support multiple currencies. The fiat amount would be calculated just in time based on the %.

Actually I just looked into the multi-currency accounts and they do not support multiple currencies in the offer only in the create offer screen the user can select one of the currencies, but the offer does not carry multiple currencies. We store the counter currency code in the offer, for that we would need to create a proxy entry for multi currencies. Not sure about further impacts without getting deeper into the code...

I think that the payment types that support multiple currencies are not that popular and the main idea for using this idea to expand usage is that people would pair an offer in a liquid fiat/BTC market with one in a less liquid fiat/BTC market. The likelihood of the payment types matching would be low.

I did not mean to limit it so such payment methods, just mentioned it that we already support multiple currencies (but was wrong with that as its only at create offer time).

Process from user perspective would be:

Create new offer. Select multiple-payment methods as payment method.
With multi-payment method selected UI shows combobox with all normal payment methods. User selects one and click add. Combobox is de-selected and selected one removed. User can select another one. The selected ones are listed below in a list view.
Rest of create offer UI is same, but fixed price is deactiavted with tooltip that only % based offers are supported with multi-payment methods mode.

Technical:

We use a comma separated list of paymentMethodIds when multiple-payment method is used for the paymentMethodId field.
counterCurrencyCode in OfferPayloadBase is set to comma separated list of currency codes of all payment methods.
If MPM is used UI creates multiple Offers in offerbook, one for each payment method. On UI side it looks like multiple offers, but network wise its only one offer. As all have the same offerId when removing one offer all offers get removed.

Effort:

Little effort on the low level domain side (offer)
Most effort is on the UI side and offerbook handling.

Limitation:

Same % based price for all PMs
No fixed price supported (if really needed there would be ways to support that by adding the list of prices in the extramap)
Same payment method cannot be added twice (for multi-currency PMs might be a drawback)

Risks:

No risks on the network layer as it does not create higher network load
Little risk with deployment of new offer variant with new payment method type. Technically its like adding a new payment method, but some constaints need to be checked.
Risks on UI side implementation both create offer view and offer book view.

To be sure that this concept would work, would require a deeper dive into the code base or a prototype implemention. But from my perspective I don't see any hurdle so far (which does not mean there are none).

As mentioned above the downside is that the price cannot be changed and no fixed price can be used, which I understand might be a nice feature. But realistically we have to weight in the costs/risks and benefit. It is not only the cost for implementing the feature its also future costs by increasted complexity. Bisq is already highly complex, adding more complexity adds more burden for any future work. The offer domain is the core of the app and it goes to nearly all layers, so changes here have to be considered very well.

I am actually not sure if the other approach to pack multiple offers into a new offertype would have less complexity/impact and gives more flexibility/feature support (e.g. diff. prices). Would require a test implementation of both variations to see whats easier and less risky.

pazza83 commented 1 year ago

@HenrikJannsen

I think one of the downsides to this offer is not being able to adjust percentages per offer.

For example if I was to place an offer for my 'home' currency I would be willing to change 1% less than if I place an offer with a foreign currency as I would incur forex fees.

Also I would likely be willing to charge 1% less for offers that could be in payment methods completed in one day (eg Revolut) vs offers that could take up to 6 days (eg SEPA).

The change of having different currencies and different trade windows is very likely with multiple offers. Therefore limiting the percentage would limit the number of offers one could offer in it.

Offer group 1; home country with immediate payment methods
Offer group 2; home country with larger trade window payment methods
Offer group 3; foreign currency with immediate payment methods
Offer group 4; foreign currency with larger trade window payment methods

Also altcoins are likely to lower offer markup percentages than fiat.

Having all the offer groups above combined in one group would be achievable if the percentages per offer could be assigned to each payment method. Not sure what way this could be achieved but think a feature with multiple payment method AND multiple offer percentages is a lot more useful than a multiple payment method with only access to different payment methods with the same percentage.

The other potential issues would be how signing / account age / payment limits work on the multiple payment methods. And likely it would be good to edit the multiple payment method to include / exclude a specific payment method. Editing payment methods is not something currently available, and creating a new payment method might impact the signing / account age / payment limits etc.

HenrikJannsen commented 1 year ago

Ok, I understand. Beside those concerns I think the previous model to wrap offers in a new offer type would be more clean anyway from code changes and offers more flexibility. Regarding limits: I think a hard requirement is that the trade amount is the same for all as that defines the security deposit and that amount will be limited by the lowest limit of the choosen payment methods.

Conza88 commented 1 year ago

https://github.com/bisq-network/proposals/issues/402#issuecomment-1456438998

That is slick. Big kudos.

My question though - e.g. revolut, I can copy that e.g. AUD, and it makes 5 clones. I then edit them, and change the payment method/or currency to e.g. NZD, or EUR... fine.

But is there anyway to save doing that every time? Or at least a longer term solution and this is phase 1?

Currently - if I make 5 offers, manually updating them... and then one gets taken, and they all go... and I have to manually do those 5 once again from scratch... just indicating from a customer exp. perspective, it'll get old real quick... and this won't have the impact on liquidity we hope/expect it to.

If I want to offer to buy Bitcoin in every fiat currency, every local market that exists... anyway to do that? In future?

Perhaps adding to the drop down options of OCO 1, or 5 - is pre-defined offers that are saved? If so, 🌔 .

MwithM commented 1 year ago

You can copy an offer, but I don't know if it will work for this offers.

apemithrandir commented 1 year ago

#402 (comment)

That is slick. Big kudos.

My question though - e.g. revolut, I can copy that e.g. AUD, and it makes 5 clones. I then edit them, and change the payment method/or currency to e.g. NZD, or EUR... fine.

But is there anyway to save doing that every time? Or at least a longer term solution and this is phase 1?

Currently - if I make 5 offers, manually updating them... and then one gets taken, and they all go... and I have to manually do those 5 once again from scratch... just indicating from a customer exp. perspective, it'll get old real quick... and this won't have the impact on liquidity we hope/expect it to.

If I want to offer to buy Bitcoin in every fiat currency, every local market that exists... anyway to do that? In future?

Perhaps adding to the drop down options of OCO 1, or 5 - is pre-defined offers that are saved? If so, moon .

So long as the offers are sharing the deposit transaction, any trade will require the offers to clear and new deposit transaction to be made. So there isn't a permanent way to keep the OCO offers that didn't trade live.

I think having saved templates would help with easy of use in getting the offers back up there but you would always need another deposit transaction to get it going again (assuming that you had no other live offers you could clone).

pazza83 commented 1 year ago

But is there anyway to save doing that every time? Or at least a longer term solution and this is phase 1?

No, I think this would be implemented in phase 2. How it would be implemented would be influenced by how traders where using OCO and what their feedback was to improve the usability of it.

apemithrandir commented 1 year ago

Just giving this thread a gentle bump. Are we any closer to getting this into a Bisq version? @jmacxx

ghost commented 1 year ago

I have completed the first round of code review changes @apemithrandir. Also, I've been testing this feature on mainnet for 3+ months, no significant issues encountered.

bisq-network / proposals