Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escrow locking time period is too short #106

Closed
initCCG opened this issue Apr 24, 2022 · 3 comments
Closed

Escrow locking time period is too short #106

initCCG opened this issue Apr 24, 2022 · 3 comments

Comments

@initCCG
Copy link

initCCG commented Apr 24, 2022

Is your feature request related to a problem? Please describe.

3 hours is not enough time to react to a trade for most normal human beings. Healthy people sleep 6-8 hours a day. Many of life's events make normal people turn off or leave their phone for over 3 hours.

Describe the solution you'd like

Time for maker to react to a trade should be increased to at least 8 hours. 12 hours would be more practical.

Describe alternatives you've considered

At least expand notification options. Believe it or not, the target users most likely to use Robosats have left Telegram, and use more secure messengers, such as Signal, Matrix, Briar. Most others in the world also don't use Telegram. They are still stuck on FB Messenger, Viber, Line, Whatsapp, Weechat and other nonsense.

@Reckless-Satoshi
Copy link
Collaborator

Reckless-Satoshi commented Apr 24, 2022

Hey @initCCG

This is indeed a parameter that everyone feels it has to change. Yet, it is unclear there is any consensus. Many users want it to be shorter. Takers are also frustrated to wait 3 hours: they want speedy in-out (and they pay for it with higher fees). Originally, this parameter was only 30 minutes, mimicking lnp2pbot. We felt it was too short and 3 hours, as of now, feels close to the sweet spot. There are other technical reasons why it cannot grow longer (24+3+24 is already very long, CLTV becomes too long: difficult to route payments and higher chance of channel force closure).

Since it is hard to have consensus around this parameter. It is obvious this issue has to be addressed by building better tools around deactivating/reactivating an order and notifications. See #87 for planned feature to pause a public order.

However, as of now you can already deal with this limitation easily and it works for all users:

  1. If you need to go, simply cancel your order! You can create it again when you have time. Canceling public orders has no penalization and the maker bond is unlocked instantly.
  2. Create an order with a public expiration time, so it expires automatically when you have to go to bed.

As for notifications, it is extremely difficult to have any sort of efficient way to notify users without invading privacy. We have to wait for the standalone Android/Iphone app for effective mobile notifications.

I agree about the messaging apps, but that sounds more like a rant than a technical solution :D

Thanks a lot bringing up this topic!

@initCCG
Copy link
Author

initCCG commented Apr 24, 2022

@Reckless-Satoshi Thanks for explanations.
It's not fair for the makers to do all this work just to maintain liquidity at all times, but for the takers to expect to get their trade processed at their pace and on their schedule.
They are not trading against machines, and this is a global market with obvious time of day consequences. If they want machine response times instead of trading with normal people, there are already such services available, Changelly for example.

Forcing the makers to add another bedtime and morning task to their schedule is not a technical solution either, and sounds more like a rationalisation to prompt the makers to manually do a lot of machine busywork for free and assume a lot of loss risk, if they forget to do that busywork .
We already tested cancelling the trade, and the maker bond did not return.

So, just on the couple of tests we did to cancel a trade and having a trade expire while we were asleep, we already lost several dollars in sats as makers, before doing a single trade.
In our part of the world, that's a significant amount. So, for now, we'll have to leave this app for makers who have sats to risk wasting like that.

It's makers that create liquidity in any marketplace - not takers. Bisq is a great example of low liquidity and low use after years in operation that result from putting the taker and dev priorities ahead of those of the makers.

Robosats is the best such idea we've seen in a while though. Good luck with it!

@initCCG initCCG closed this as completed Apr 24, 2022
@Reckless-Satoshi
Copy link
Collaborator

Reckless-Satoshi commented Apr 24, 2022

Hey @initCCG,

Thanks a lot for all the suggestions from the side of a professional maker. The message has been gotten! We need better maker tools. I have been asking around for professional makers' feedback for long time and got nothing so far. So please, stick around. It is not fair to get feedback together with an ultimatum :)

I am thinking a good option might be to allow makers to customize the length of the locking escrow / submitting step. Probably, if it is made longer the total public length will have to be shorter. Then, takers can be notified in advance of what is the time they might have to wait potentially: up to them to select what order to take :)

We already tested cancelling the trade, and the maker bond did not return.

Please get in touch to debug this (send payment_hash or robot name + order id to robosats@protonmail.com). We haven't had any problem with unlocked bonds caused by RoboSats, but many have been reported: usually it's an accounting problem of the wallet (seems to happen often with Bluewallet and they are working on a fix).

The bonds' purpose is not to punish those who want to contribute, but those who try to cheat. So please, write to the same email to be refunded the lost bonds.

PD: Takers and Makers can indeed script most of their trading using the order API endpoint #75. I would suggest, if you are serious about being a maker in RoboSats, to take a look at it, there is a lot of evidence of automated trading already happening in RoboSats (auto taking orders, auto locking bonds, submitting invoices, ..., everything except chatting has been automated by users).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants