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

client: Move market making out of core #2320

Merged
merged 4 commits into from
May 7, 2023
Merged

Conversation

martonp
Copy link
Contributor

@martonp martonp commented Apr 21, 2023

 client: Remove Bot from Core

In preparation for moving the bot logic outside of core, all of
the previous bot logic is deleted. The UI is also removed as it
will no longer function without major modification.
 client: Put market making logic outside of core

This moves the market making logic outside of core. There is a new
`MarketMaker` type which calls into core. When running the `MarketMaker`,
one strategy can be defined for each dex market. Since the Gap strategy
was originally designed to have multiple bots running on a market, the
strategy will have to be modified, but this diff only deals with
refactoring the logic outside of core.

The RPCServer is updated with startMarketMaking and stopMarketMaking
commands. Market making can be started by providing a path to a config
file.

New Core methods are also added to support the MarketMaker: `ExchangeMarket`
and `SingleLotFees`.

@martonp
Copy link
Contributor Author

martonp commented Apr 22, 2023

I'm thinking to first build out all the features, including balance handling, profit/loss reporting and the three different strategy types, then restore the UI once everything is mostly finalized.

@chappjc
Copy link
Member

chappjc commented Apr 24, 2023

I'm thinking to first build out all the features, including balance handling, profit/loss reporting and the three different strategy types, then restore the UI once everything is mostly finalized.

Makes sense. I guess main would create something like a BotMgr instance that is given to webserver and rpcserver.

Maybe we don't need to rm mm.{ts,scss,htmpl} though since when it gets plugged back in the current page basically has the right controls and all? While I think the strongest use case for a bot is a cli app with config file/rpc controls, we want to continue offering the GUI controls. We wouldn't even want to do the next major release without it, even if all the advanced bot features aren't yet complete.

What are the main hurdles in retaining the existing UI (at least create/start/stop)? Looks like it would be the hypothetical BotMgr.

@martonp
Copy link
Contributor Author

martonp commented Apr 24, 2023

There doesn't need to be a complete overhaul to the UI, but there are significant changes that need to be made. Instead of starting and stopping individual bot programs, it would be one stop and start button for the entire system. The calls made to the webserver will also have to change. Also, there are a few more settings that will need to be added to this strategy before it's complete. I was just removing it so that there is no unusable code in the repo, and I didn't want to fix the UI until at least this one strategy is finalized. I can add it back though so that the PR for updating the UI is smaller though if that's what you're worried about.

@chappjc
Copy link
Member

chappjc commented Apr 24, 2023

I can add it back though so that the PR for updating the UI is smaller though if that's what you're worried about.

No, just that with git you might lose the ability to track line-by-line changes over time if it gets rm'd and created fresh later. If you think the end UI will be very different then it sounds like there's no point to that.

@chappjc
Copy link
Member

chappjc commented Apr 30, 2023

There doesn't need to be a complete overhaul to the UI, but there are significant changes that need to be made. .... I was just removing it so that there is no unusable code in the repo, and I didn't want to fix the UI until at least this one strategy is finalized. I can add it back though so that the PR for updating the UI is smaller though if that's what you're worried about.

As per my last comment, it's just that with git you might lose the ability to track line-by-line changes over time if it gets rm'd and created fresh later. At this point, I think we should leave the big frontend source codes, but have it inaccessible from the frontend. This bot project is going to introduce a lot of unusable code until this project is complete, as you say. The webserver mm page route could simply be inaccessible (e.g. redirect to /markets) until at least the new webserver route handlers are created and the basic conceptual changes (start/stop bot, not bots, update programs, etc.) have been adapted to.

Anyway, I say we move forward with the refactor of mm to a core consumer (this PR), but we should really get the UI elements back asap, even if some of the controls are inactive. You could mock it up as if everything is done, and I think that would help shed light on the end goal. If we want to release a 1.0 in the near term, which is something we want before starting major changes for mesh, we can't have the MM controls vanish.

@martonp
Copy link
Contributor Author

martonp commented May 1, 2023

OK I'll add it back and update the UI ASAP. I think it would be nice to have #2332 in before updating the UI though.

@chappjc
Copy link
Member

chappjc commented May 1, 2023

OK I'll add it back and update the UI ASAP. I think it would be nice to have #2332 in before updating the UI though.

I'm sure we can get these two in pretty quick. I scanned the balance PR and it make sense in concept.

Copy link
Member

@chappjc chappjc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs resolve, but LGTM. I'm very excited about this project. Can't wait to see it all come together.

client/core/core.go Show resolved Hide resolved
client/asset/btc/btc.go Outdated Show resolved Hide resolved
client/mm/config.go Show resolved Hide resolved
client/mm/mm.go Show resolved Hide resolved
@martonp martonp force-pushed the removeBotCore branch 2 times, most recently from 23606be to b89e3d9 Compare May 4, 2023 07:19
@martonp
Copy link
Contributor Author

martonp commented May 4, 2023

Fixed @JoeGruffins's review comments, added the UI code back, and the MarketMaking button links to the markets page now.

In preparation for moving the bot logic outside of core, all of
the previous bot logic is deleted. The UI is also removed as it
will no longer function without major modification.
This moves the market making logic outside of core. There is a new
`MarketMaker` type which calls into core. When running the `MarketMaker`,
one strategy can be defined for each dex market. Since the Gap strategy
was originally designed to have multiple bots running on a market, the
strategy will have to be modified, but this diff only deals with
refactoring the logic outside of core.

The RPCServer is updated with startMarketMaking and stopMarketMaking
commands. Market making can be started by providing a path to a config
file.

New Core methods are also added to support the MarketMaker: `ExchangeMarket`
and `SingleLotFees`.
Copy link
Member

@buck54321 buck54321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like where this is headed.

Comment on lines 1674 to 1675
const numInputs = 10
txSize := dexdcr.InitTxSizeBase + (numInputs * dexdcr.P2PKHInputSize)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you comment on the choice of 10 inputs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was kind of an arbitrary choice.. I just wanted to get a reasonably safe estimate without having to actually look inside the wallet. Do you think I should pick a higher number?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update to 12, same as what the bonds fee buffer uses.

const numInputs = 10
txSize := dexdcr.InitTxSizeBase + (numInputs * dexdcr.P2PKHInputSize)

var splitTxSize int
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just make txSize and splitTxSize uint64s, and skip the conversion when you sum below.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No migrations for TestBasisPrice, TestBreakEvenHalfSpread, or TestRebalance? They all seem to have analogues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm bringing those back in another PR I'm working on right now that updates the strategy a bit. Instead of just putting just one order on each side of the market there will be an array of orders at different distances from the midgap.

Comment on lines +230 to +234
parts := strings.Split(u.Host, ".")
if len(parts) < 2 {
return "", fmt.Errorf("not enough URL parts: %q", u.Host)
}
return parts[len(parts)-2] + "." + parts[len(parts)-1], nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We found this approach insufficient for handling IP addresses in eth/multirpc.go. I don't expect you to fix this here, just noting.

@chappjc chappjc merged commit de0d52c into decred:master May 7, 2023
@martonp martonp deleted the removeBotCore branch January 20, 2024 13:17
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

Successfully merging this pull request may close these issues.

4 participants