-
Notifications
You must be signed in to change notification settings - Fork 100
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
Conversation
martonp
commented
Apr 21, 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 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 |
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 |
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. |
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. |
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. |
There was a problem hiding this 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.
23606be
to
b89e3d9
Compare
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`.
There was a problem hiding this 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.
client/asset/dcr/dcr.go
Outdated
const numInputs = 10 | ||
txSize := dexdcr.InitTxSizeBase + (numInputs * dexdcr.P2PKHInputSize) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
client/asset/dcr/dcr.go
Outdated
const numInputs = 10 | ||
txSize := dexdcr.InitTxSizeBase + (numInputs * dexdcr.P2PKHInputSize) | ||
|
||
var splitTxSize int |
There was a problem hiding this comment.
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
uint64
s, and skip the conversion when you sum below.
client/core/bot_test.go
Outdated
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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.