Replies: 5 comments 4 replies
-
|
100% Concept ACK! A much requested and useful feature! ChallengesPrivacy / Fingerprinting recurring offers
Notice that when the offer details are exactly the same, then there can be some fingerprinting and clustering of recurring offers of one users [at least for offerbook watchers]. For example, if exactly A potential solution is to randomize the offer details within user input range, to something more vague like:
[yeah, range user input sucks, so maybe make it optional] Non-automated fiat bank paymentsOne of the nice use cases of custodial DCA, is that the fiat bank transfer can be automated as recurring send to the same receiver [the exchange bank account]. This means BOTH the fiat transaction AND the bitcoin purchase are automated. I understand how Bisq can automate the bitcoin purchase, but how can we automate the fiat bank transaction to multiple different counter parties? It seems to me that the user still has to become active for every trade, at least to get the trading-partners bank information and beg the bank for permission to do the transaction. On the other hand, Bisq CAN automate fiat transactions when fiat certificates [like Tether] are managed within the Bisq wallet. So a potential workaround to the problem:
Downsides to this approach is the upfront capital liquidity in fiat bank shitcoins. If the user does not have much fiat in the bank account, but he is receiving incoming cash flow regularly, from which he wants to make his bitcoin savings, then he still has to manually make the bank transfer recurringly. Future directionBuy the dip automationAdd a new recurring offer condition:
|
Beta Was this translation helpful? Give feedback.
-
|
Great points, @MaxHillebrand, thanks.
Right, glad you brought this up. My thought when writing this up is that nothing would change on this front. Offer publication would become automated, but trade settlement, i.e. paying the seller, would continue to require interaction just as it does today. Success with this approach relies heavily on the assumption that users are set up for notifications with the Bisq mobile app, and I'm not sure how widely-adopted that is today. We would probably want to promote the mobile app more heavily as part of this effort.
Indeed, and we already do something similar to this in the way we round fiat values to avoid very specific and thus more traceable amounts, e.g.
Sure, and while we might market it as Bisq's "BTFD feature", it would be technically distinguished as a "relative limit offer" as contrasted with the "absolute limit offer" I proposed above. A relative limit offer would say "publish (or re-enable) this offer when the market price drops by X%" whereas an absolute limit offer would say "publish (or re-enable) this offer when the market price falls below X USD". One complication of the relative limit offer is how to specify what the percentage drop should be relative to. It could be relative to the market price at time of offer creation, i.e. "publish this offer whenever the market price drops X% below P market price", or it could be a more sophisticated variant that says "publish this offer whenever the market price drops X% within T time interval". This latter form would be more useful as it would allow users to "set it and forget it", ensure they always buy the dip, regardless the current market price. |
Beta Was this translation helpful? Give feedback.
-
Yes, this is kinda security feature but UX bug... The cool thing about the custodial DCA is that you can literally It seems that this is not trivial, and probably not even desired, to automate the fiat bank transfer for Bisq trades... But notice that then Bisq DCA's have this [quite substantial] UX downside compared to custodial DCA's. Again, automated transfer of fiat certificates might improve that UX a lot, however the security downside might still be unfavorable. Yes, I think "publish this offer whenever the market price drops X% This is what I meant above "publish this offer whenever the market price drops X% |
Beta Was this translation helpful? Give feedback.
-
|
Actually, re-reading my last comment, there is effectively no difference between an absolute limit offer that says "publish this offer when the market price drops below X USD" and a relative limit offer that says "publish this offer when the market price drops X% below P market price." They're two ways of specifying exactly the same thing, and the former is the simpler way to do it. So the recurring relative limit offer representing a true "BTFD policy" would be the one that says "publish this offer whenever the market price drops by X% within T time interval". We're getting way ahead of ourselves here with regard to the original intent of this discussion, but it's fun to consider this stuff. |
Beta Was this translation helpful? Give feedback.
-
|
Yes! |
Beta Was this translation helpful? Give feedback.
-
|
Hah! I just now realized that v1.5.5 shipped with "trigger price" functionality that implements a primitive form of limit offers similar to what's described above.
See #5001 for details. |
Beta Was this translation helpful? Give feedback.
-
|
What's that essentially change to your proposal now? Slight amendments to presentation? |
Beta Was this translation helpful? Give feedback.
-
|
Great idea. From a traders perspective I would be happy to sell to clients that enter into a contract to buy BTC at a specified percentage over the market rate each month for a given number of months. For example a user agrees to purchase 0.01 BTC on the 1st every month in EUR price determined in Bisq at 00.00 1st each month at Central European Time (CET). Offer could still use the security deposit of 0.006 BTC. Maybe trade fees could be a multiple of the number of months the length of contract for both buyer and seller. Trade could sit in open offers for the specified number of months. |
Beta Was this translation helpful? Give feedback.
-
|
Good idea! Notice there are now two different ideas here:
I think @cbeams was initially talking about the former. |
Beta Was this translation helpful? Give feedback.
-
One of the things that makes it hard to recommend Bisq to newcomers is that there's no way to set up recurring, e.g. monthly bitcoin buys. This an area where centralized exchanges excel, and a number of newer services like Swan Bitcoin and River Financial are specializing in this so-called dollar cost averaging or DCA approach. Though it would be challenging for several reasons, I don't see any fundamental reason why Bisq couldn't support this use case as well.
The basic idea
Allow users to specify a recurring buy offer. They would indicate how often they want the offer to recur, and the amount of bitcoin they'd like to purchase, expressed in fiat, e.g. USD. For example:
Assuming the offer gets taken, a new offer with the same details will be created on the 1st of the following month. If the offer does not get taken, no new offer will be created, and the old one will stick around until it gets taken. Policies could become configurable here, but we could start with something simple like this.
This could be implemented at the UI level in a minimal way with an option in the existing
Create Offerscreen to "make this offer recurring" and, if enabled, allow the user to enter their desired interval.Challenges
Fee management
A naive approach to implementing this feature would sometimes result in users paying very high fees during a mempool spike. We would need to implement a policy to defer offer creation until the fee rate falls under a user-specified threshold. This feature would be very useful even outside of the context of recurring offers. In the
Create Offerscreen, we would see this implemented as something like an option to "Publish this offer when the fee rate is less than or equal to ___ sat/byte". (This could also be implemented as a global "Max transaction fee" setting inSettings > General Preferencesnext to the existing "Withdrawal transaction fee" setting.)Future directions
Limit offers
Once we have the ability to defer offer publication as described above, we wouldn't be far off from more general support for limit offers. It's basically the same functionality, but instead of making offer publication conditional on the fee rate falling under a certain limit, this option would make offer publication conditional on the market price falling under a certain limit (and would disable the offer when the price rises back above that limit).
Recurring orders
Today, Bisq deals only in offers to buy or sell, distinct from the idea of orders, because there is no centralized matching engine. However, if we implement recurring offers as described above, it wouldn't be a big leap to extend that to a more general recurring order that allows the user to say "I want to buy X USD worth of BTC on the first of every month. I'll take an existing offer to sell if one satisfies my requirements, otherwise I’ll create my own offer to buy." In this way, the user is "ordering" their Bisq node to buy a certain amount of bitcoin, whether than means taking or making an offer.
Thoughts please
I'm sure there will be many other nuances to consider, but I in general I think DCA support would be very compelling. Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions