[bisq-network/bisq] Recurring offers to support dollar cost averaging (DCA) use cases (#5165)

[Chris Beams]

Great points, @MaxHillebrand, thanks.

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

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.

> Privacy / Fingerprinting recurring offers
> [...]
> A potential solution is to randomize the offer details within user input range [...]

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. `123.00` USD vs `123.45` USD.

> Buy the dip automation
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 particular offer when the market price drops X% below the _current_ market price", or it could be a more sophisticated variant that says "publish an offer with these details whenever the market price drops X% within Y time interval". This latter form would be more generally useful in terms of allowing users to "set it and forget it". It would ensure the user _always_ buys the dip, according to their definition of a "dip".



-- 
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/bisq/discussions/5165#discussioncomment-346701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210207/ad5460b8/attachment.htm>