JoinMarket-Org/joinmarket-clientserver

Fee and minimum size setting in market maker offer not deleted after stopping service and applying changes

Opened this issue · 6 comments

If one creates a market order "Earn" in Jam and accidentally hits the "Start Earning!" button before changing the default offer options (0.03% relative fee / minimum 100.000 sats) it is clear that the offer is spread in the network. However hitting the "Stop" button should fully delete the order and fee / minimum size settings.

The actual behaviour is that even though an offer, that was started accidentally with default fees, was stopped within less than a minute, and a new offer with higher minimum amount value was started, there was a coinjoin accepted with the previous minimum size setting.

Steps to reproduce the problem:

Set the fee rate and minimum amount to default values e.g. 0.03% relative / minimum 100.000 sats
Hit the "Start" button to start your offer
Wait until Jam has finalised the offer and showing the counterparty ID
Stop the current offer
Change the fee rate to other values e.g. 0.01% relative / minimum 5.000.000 sats
Check the earnings report if you have taken orders with sat values < 5.000.000 sats
Specifications

Version: 0.1.6.
Platform: Umbrel
Browser: Safari 17.0

This is issue of Jam, not JM itself, you should open it at https://github.com/joinmarket-webui/jam.

theborakompanioni asked me to post it here and not in Jam.

This is issue of Jam, not JM itself, you should open it at https://github.com/joinmarket-webui/jam.

Hey @kristapsk! I am not sure if this is related to Jam - I cannot think of any reason why, as Jam just feeds the API and displays returned values. I have heard of this behaviour once before, so it should be extremely rare.. and as such, it is not easily reproduced. My humble guess is the problem is located in the backend.

Jam does the following (auth headers removed):

  • Start the maker
curl 'http://localhost:3000/api/v1/wallet/Satoshi.jmdat/maker/start' -X POST --data-raw '{"ordertype":"sw0absoffer","minsize":"100000","cjfee_a":"100","cjfee_r":"0","txfee":"0"}'
  • Stop the maker
curl 'http://localhost:3000/api/v1/wallet/Satoshi.jmdat/maker/stop'
  • Start the maker again with different values
curl 'http://localhost:3000/api/v1/wallet/Satoshi.jmdat/maker/start' -X POST --data-raw '{"ordertype":"sw0absoffer","minsize":"42424242","cjfee_a":"0","cjfee_r":"4242","txfee":"0"}'

In addition to that, Jam displays whatever the backend responds with in offer_list to the user:

curl 'http://localhost:3000/api/v1/session'

Example response:

{
  "session": true, 
  "maker_running": true,
  "coinjoin_in_process": false, 
  "schedule": null,
  "wallet_name": "Satoshi.jmdat", 
  "offer_list": [{"oid": 0, "ordertype": "sw0absoffer", "minsize": 424242, "maxsize": 123429489, "txfee": 0, "cjfee": "4242"}], 
  "nickname": "J5BnUNGL5ksf4PdY",
  "rescanning": false
}

As long as maker_running is true, a user cannot execute the request to start the maker.

Set the fee rate and minimum amount to default values e.g. 0.03% relative / minimum 100.000 sats
Hit the "Start" button to start your offer
Wait until Jam has finalised the offer and showing the counterparty ID
Stop the current offer
Change the fee rate to other values e.g. 0.01% relative / minimum 5.000.000 sats
Check the earnings report if you have taken orders with sat values < 5.000.000 sats

Are you sure you didn't change between absolute and relative offers and only changed fees?

This code looks suspicious to me:

for key, val in config_json.items():
if(key == 'cjfee_r' or key == 'ordertype'):
pass
else:
try:
config_json[key] = int(config_json[key])
except ValueError:
raise InvalidRequestFormat()

Yes, I am 100% sure that I didn't select absolute fees. I reboot my node and after reboot the default is always relative fees. Then accidentally I hit the "Earn" button before changing the fees to my own standards. I also never used absolute fees before.

One user reported the same behaviour with using absolute fees exclusively.

Also, just for completeness, Jam send always both values cjfee_r and cjfee_a in the request body, with one of them being 0 depending if it an "absolute" or "relative" offer.