setprice should not set prices < 0.00000001

[cipig]

setprice lets me set such an order

  "base": "ECA",
  "biddepth": 0,
  "bids": [
    {
      "coin": "BCH",
      "address": "bitcoincash:qrplwyx7kueqkrh6dmd3fclta6u32hafp5tnpkchx2",
      "price": "0.000000009039137390883907738663003893876987209597317817315894746149593630855456136318614390237846435893438883",
      "maxvolume": "0.5",
      "min_volume": "0.0001",
      "pubkey": "031bb83b58ec130e28e0a6d5d2acf2eb01b0d3f1670e021d47d31db8a858219da8",
      "age": 1619356690,
      "zcredits": 0,
      "uuid": "a33b06cb-ae72-4ab7-ae01-c8aadb5799e3",
      "is_mine": true,
      "base_max_volume": "55315012.74715182",
      "base_min_volume": "11063.002549430364",
      "rel_max_volume": "0.5",
      "rel_min_volume": "0.0001",
      "base_max_volume_aggr": "55315012.74715182",
      "rel_max_volume_aggr": "0.5"
    }
  ],

with price < 0.00000001, but taker gives error when he tries to fill the order [{"error":"rpc:253] lp_ordermatch:2729] lp_ordermatch:2807] Price is too low, minimum is 0.00000001"}]

additional question: could we also allow prices with more than 8 decimals? for low price/high price pairs...

[artemii235]

It looks like you set the price for the reversed pair initially. If you try to directly supply 0.000000009... you will get {"error":"rpc:253] lp_ordermatch:3277] Price 0.000000009... is too low, required: 0.00000001"}. Looks like we need to check that both price and 1 / price are above the threshold.

The only question: what reasonable price threshold should we set instead of 0.00000001? Or should we maybe remove this threshold at all as some cheap assets can have a 0.000000000000001 BTC price (or maybe even lower)?

[cipig]

i was also thinking about removing the threshold entirely... it will allow sub 1 sat prices and there is actually need for that for coins like this https://www.coingecko.com/en/coins/electra... atm i need to disable BTC pair for such coins

[artemii235]

@tonymorony Pointed that GUIs might be potentially broken by getting extremely low prices on the orderbook from MM2. @Milerius @yurii-khi Are you ready for the 0.000000000000000000000000001 price in your code? :slightly_smiling_face:

[cipig]

does not have to be so many decimals, 10-12 are more than enough, i guess... don't think BTC price will go to $50M anytime soon :-)

[artemii235]

@cipig What if we have a token that costs just 1 Wei of ETH? It is 10^-18 :slightly_smiling_face:

[cipig]

haven't seen it with my own eyes yet, but possible, sure btw, this is how ECA/BTC looks on a CEX... in this case they have 11 decimals

[yurii-khi]

We have this statement inside our formatting helper:

if (value > 0 && value <= 0.00000001) {
    return '0.00000001';
}

So we're not able to properly represent prices like ECA/BTC in the example above atm.

[artemii235]

@yurii-khi @tonymorony @Milerius Can you arrange a solution for displaying and setting the < 0.00000001 prices in GUIs, please? We won't make any changes in the API until we are sure that it will be properly handled/not break anything.

[Milerius]

@tonymorony Pointed that GUIs might be potentially broken by getting extremely low prices on the orderbook from MM2. @Milerius @yurii-khi Are you ready for the 0.000000000000000000000000001 price in your code?

This will require lot of works, would be nice if orderbook can earn a decimals/precision field in this case, so we can set dynamically the precision in our GUI - will take a bit of time to be honest but atleast we can do a smooth transition. For the moment hardcoded 8 as precision everywhere, can go up to 50 digits in my code in the future.

[artemii235]

would be nice if orderbook can earn a decimals/precision field in this case

Even if we add decimals/precision there will be additional fields in the orderbook response, something like price_rounded/volume_rounded, and users will need to be aware this is not a precise number. Also as cipi already mentioned 0.000000009... price - if someone sets e.g. 4 decimals doesn't it get rounded too much? There is a way too big difference between 0.0001 and 0.000000009.

[tonymorony]

Sorry for the delay with the response, created issues in GUIs repos with ways of such prices displaying proposals:

https://github.com/KomodoPlatform/AtomicDEX-mobile/issues/1226 https://github.com/KomodoPlatform/atomicDEX-Desktop/issues/955

my opinion on rounding/price limiting in interfaces (if summarise - don't think it's good to round/limit price and sacrifice precision/limit denomination possibilties/variations): https://github.com/tonymorony/dexstats_sqlite_py/issues/7#issuecomment-847241701

[damascene]

Any progress on this issue, I was trying to setup a test trade for honk token but the lowest price I could set is 10x higher than market: https://exchange.bitcoin.com/honk-to-bch