Closed apemithrandir closed 2 years ago
MwithM
commented
2 years ago OCO offers should be implemented sooner or later on Bisq 2 protocols with security deposits. I wonder if API is already contemplating this scenario. Another thing that should be implemented is to reduce min security deposits for pegcoins like USDT or L-BTC.
apemithrandir
commented
2 years ago @MwithM how does my proposal differ from Bisq 2 protocols with security deposits? Is there a page I can look at for comparison?
salokiam
commented
2 years ago Smart idea with the cancelling and there are not so many points in the code which need to be changed. That would probably provide some liquidity on the niche markets. Probably none on the main market(s).
w0000000t
commented
2 years ago As I said on matrix (but let's make this official on GH) I like this approach very much, as it doesn't need to overhaul the current UI for offer making, but rather recycles most of it, just adding the grouping field. The "grouping" concept is the name I came up with, as I know there is a service named Gixen that is used to "snipe" on ebay auctions, and you can set snipes for multiple items on ebay, grouping them (groups are numbered, 0, 1, 2...) so that as soon as one auction snipe wins an item in a group, all other snipes in the same group are removed.
I am a DIY programmer even if I don't use Java, so I can see how this would be way easier on the backend, as there would just be the need, on offer being taken, to recurse over the open offers, to disable/delete the ones with the same group of the one that's just been taken. On the UI front, it's even easier as there's a text field to be saved in the offer properties, and nothing more.
apemithrandir
commented
2 years ago Thanks for the kind comments @w0000000t and @salokiam.
I am not a proficient programmer myself. Who within the project would have the interest, skills and knowledge of the code base to implement such a proposal?
I also lack knowledge of priorities within the project, to know if this proposal would fit with any of the existing plans that are already underway. If anyone can comment on the planning aspect that would useful too.
MwithM
commented
2 years ago @MwithM how does my proposal differ from Bisq 2 protocols with security deposits? Is there a page I can look at for comparison?
Protocols with security deposits is what I call to what Bisq 1 is offering right now. As I don't think there are going to be any big changes in Bisq 1, I think that this proposal should be considered for Bisq 2.
Conza88
commented
2 years ago A big change is upgrading to taproot or adding lightning, surely.
This would be incredibly impactful to user experience and growth prospects imo. Churn reduction etc. Local community growth. Liquidity.
Very much worth it and Bisq 2 may be YEARS away.
I can't stress enough how much this should be as a top priority for Bisq 1.
Post this change (and maybe single on chain transaction) I'm happy to back Bisq 2. Anything before then is premature imo.
apemithrandir
commented
2 years ago @Conza88 I appreciate the vote of support. Though we need someone qualified to commit to doing the work, as well as some buy-in from the community that if the work was done it would be merged.
Because I believe in this proposal and it's potential, I am willing to offer up 1m sats (0.01 btc) bounty to motivate this work to be completed. Some qualifiers:
Obviously this bounty should not exclude anyone from also seeking compensation from Bisq for doing the work.
ghost
commented
2 years ago I support this proposal, would like to hear from @ripcurlx and @chimp1984
chimp1984
commented
2 years ago Thanks @apemithrandir for the interesting proposal. I think an easier model would be to allow multiple payment methods to one offer. But also that would come with quite some dev effort. Your suggestion would come with considerable dev effort IMO. As we have very limited dev resources I suggest to invest it better in Bisq 2 where many things get improved by default:
chimp1984
commented
2 years ago @apemithrandir Btw if you want to work on open conceptual issues for Bisq 2 you are very welcome. Best to join the Bisq 2 matrix channel.
w0000000t
commented
2 years ago Your suggestion would come with considerable dev effort IMO.
Could you explain even in a very short manner how you envision this "grouping" liquidity increase as a significant development effort? My knowledge is currently limited to the LAMP stack, so it's possible this skews my perception of the complexity of implementing this mechanism on top of the current Bisq with Java
apemithrandir
commented
2 years ago @apemithrandir Btw if you want to work on open conceptual issues for Bisq 2 you are very welcome. Best to join the Bisq 2 matrix channel.
Thanks for the feedback. As I stated I’m unfamiliar with the code base and rely on people such as yourself to comment on the ease of integration of the proposal.
I would be more than happy to join the Bisq 2 matrix channel and see if I can offer any help on conceptual issues. What is the channel link?
w0000000t
commented
2 years ago I would be more than happy to join the Bisq 2 matrix channel and see if I can offer any help on conceptual issues. What is the channel link?
Conza88
commented
2 years ago I think an easier model would be to allow multiple payment methods to one offer. But also that would come with quite some dev effort.
What can be done in Bisq 1 that would allow that, get it over the line? If I and a few others threw some more money at it?
I am not necessarily directly interested in OCO; but whatever can get the job done as end result:
I would have thought when one is taken; in that reserve/batch/group the others disappear, and the buyer/seller can they easily re-create if they wish. Or if they already have made other single offers (with other multiple payment methods etc.), they would remain until one from that batch/group/ is taken.
What would a possible bare minimum be possible?
pazza83
commented
2 years ago Closing as stalled.
This proposal is a follow on from:
201
288
Background
Bisq operates as a highly fragmented market in terms of liquidity. You have many currency pairs and within each currency pair you have many different payment methods. None of these offers are fungible or linked in any way. If a liquidity provider on Bisq wants to provide maximum liquidity, they will want to be able to post buy and sell offers, across all combinations of currency pairs and payment methods they have enabled in their account.
Currently if a liquidity provider wanted to do that on Bisq, they would be required to reserve their deposit amount (+fees) for each and every combination of currency and payment method in an additive fashion. This incentivises only putting offers on the most popular currency and payment methods, so you can trade quickly and re-deploy capital. If you put offers in less popular currency and payment methods, your capital will be tied up for extended periods, and unable to be re-deployed to provide liquidity in the more active markets.
I would like to propose a way to link offers via a "One Cancels Other (OCO)" option to reduce required Reserved BTC, and reduce the penalty for posting liquidity in less active markets.
Description
The initial version I would like to propose would be an advanced setting in the preferences page "Make all offers OCO":
If an advanced user enables this feature, then all subsequent offers would be linked such that, if one of them traded, all of the rest of them would automatically cancel. This would allow the sharing of fee & reserve requirements of these offers. Additional fees and reserves would only be required if the new offer exceeded the maximum fee and reserves of all the previous offers.
This should not require any major change to the UI and would be presented as an advanced feature. With this feature, we are assuming the user is educated enough to understand the effects of shared offers disappearing when one is taken.
Further Iterations
This first version is a blunt instrument. Further iterations should consider the ability to create offer groups, as opposed to forcing all offers to become OCO. The most basic group would be to group all buy offers together, and all sell offers together, separately. Then when you got taken on a buy offer, your sell offer would not immediately cancel (and vice versa).
The next iteration would be to introduce general grouping. This would assign a custom group label per offer in the offer creation page. Re-using that label on subsequent offers would link the offers together with each other, and share the fee and reserve requirements of these offers.
If you introduce custom labelling in the offer creation page, then you should remove the OCO setting in the preferences page, as this might add confusion to the process. The default behaviour should be an empty label which should result in "OCO off" behaviour.
Notes on Implementation
I am not familiar with the codebase of Bisq and have only recently started using the application, so I will have to depend on the established community members to comment on the implementation of this proposal. I would be more than happy to work with the team in any testing that might be required.
Notes on Altcoins
The above proposal was written from the perspective of Fiat/BTC markets, but the scope of it is general enough in my opinion to also apply to Altcoin markets. I lack any familiarity with the Altcoin markets though, so I would defer to other community members with experience in these markets to comment.