feat(orderbook): expirable maker orders

[onur-ozkan]

Implements expirable maker orders which can be easily used with timeout_in_minutes arg in setprice RPC. It's an optional field and doesn't cause a breaking-change.

Changes on the 1.5.0 timed-map release: Orkavian/timed-map#12
Documentation issue: GLEECBTC/komodo-docs-mdx#537
Closes #2479

[shamardy]

@onur-ozkan test_expirable_order fails in CI and locally.

[onur-ozkan]

Should be fixed now, thanks.

[shamardy]

@cipig please take a look at this Pr and see if it matches what you needed

[shamardy]

First review iteration from my side. I also have a question, what happens on restart, do we check expirations of saved orders before rebroadcasting them?

[shamardy]

Why minutes not seconds?

[onur-ozkan]

I think using seconds would be unnecessary and can be bad for the network stability (imagine people sending orders with ~5-10 seconds of expiration time).

[shamardy]

Makes sense, will wait for @cipig input since he requested this

[shamardy]

imagine people sending orders with ~5-10 seconds of expiration time

On the other hand, if or when we can support this, it won't be bad as it will mirror the CEX experience a lot.

[shamardy]

And they can cancel it in whatever seconds they like manually or using scripts

[onur-ozkan]

It wouldn't be harmful on CEX platforms because spamming very short-lived orders doesn't affect other nodes. But on a P2P network I think orders should live for at least 30 seconds or so. For example orders that last only 5 seconds just put pressure on the network, especially since it can take up to 5 seconds for peers to fully sync. Instead doing manual validations on the expiration time, I decided to make it minute and I tought it's quite reasonable to say "orders must have at least 1 minute expiration time" to users.

Also, when taking so many users into account, with seconds, this feature alone can put quite a lot of pressure on the network, with minutes, it should be way less compare to seconds.

[shamardy]

I understand and agree. I was just arguing the opposite case, I plan to leave it at minutes unless @cipig objects and wants something like 30 seconds.

[shamardy]

Cancelling in seconds doesn't have to have an immediate p2p message propagated but if it's matched before it's cancelled on remote nodes, the maker node will not proceed with the order when it's not available locally. And takers choose between the best response from multiple makers anyway so it won't cause problems. But that's for another PR or issue if needed.

[cipig]

Makes sense, will wait for @cipig input since he requested this

Minutes is perfectly fine. I added it in my bot with a 20 minute timeout (cipig/mmtools@5ee5dbe). It needs anyway 5-15 minutes to update all orders, depending on number of coins. If the bot dies for whatever reason, orders are cancelled like this:

22 14:32:03, mm2_main::lp_ordermatch:3591] INFO Order 'afb833e8-7d6a-42da-9151-4f8f096efb57' is expired, cancelling
22 14:32:05, mm2_main::lp_ordermatch:3591] INFO Order 'f1cc74c7-b0f0-40d7-a4a6-036ea66a39e2' is expired, cancelling
22 14:32:07, mm2_main::lp_ordermatch:3591] INFO Order 'fc996c71-0d19-4e7c-bc35-636afdd88d22' is expired, cancelling
22 14:32:09, mm2_main::lp_ordermatch:3591] INFO Order '28088d79-694b-4b84-965b-1c97b0827729' is expired, cancelling

That's exactly what i wanted, as a safety measure for my own bad programming :-)
Thanks a lot.

[cipig]

one last question: if not too much work, can we add more infos to the INFO Order 'e589e874-cac1-4680-9203-e4177a9f24cb' is expired, cancelling output? I see it popping up sometimes and would like to know which pair that is. I have set "save_in_history":false in my setprice, for performance reasons, so i don't have a history of orders to check.

[smk762]

documented in GLEECBTC/komodo-docs-mdx@523b1e9#diff-ade3a10935fdaea595a9b06daac7716dea73286530eb0502c91cc65ad8b54c8dR319