Tier liquidity details in the nu client

[Michael Witrant]

Jordan would like the Nu client to display the details of the tier 1 and tier 2 liquidity (https://discuss.nubits.com/t/tier-2-liquidity-now-widely-used/1323).

Unfortunately we can't really provide that information in the Nu client without a mandatory upgrade. The liquidity info propagation through the network would be affected by the nodes who have not upgraded.

There was a plan already to add the liquidity identifier to the information propagated through the network. No decision was officially made to include that in the 0.6 mandatory upgrade, but I guess it's now decided we're going to do that and also add the tier information.

While we're updating this process we have the possibility to make these changes more flexible (like Jordan expected them to be). I'm not sure this would be useful and there are many ways to do that (from the most flexible and dangerous like propagating JSON to just adding some reserved fields in the structure).

What do you think? Do you expect the liquidity info to need frequent updates (more frequent than mandatory upgrades of the Nu client)?

For now the changes would be like this:

• we add a new parameter to the liquidityinfo RPC for the bot to provide the tier. For example:

liquidityinfo <currency> <buyamount> <sellamount> <grantaddress> [<indentifier>] [<tier>]

• 2 new data would be added to the liquidity info propagated through the network: the identifier (a string) and the tier (a byte)
• the nu client would report the identifier and the tier in the getliquidityinfo RPC and the GUI

Should we add anything else?

[Desrever Nu]

Thank you for creating an issue to discuss this change properly.

First of all I wanted to inform you that in the upcoming ( a few days ) version of nubot, the identifier is structured as following :

custodianPublicAddress_exchangeName_pair_tier 

As you can see, this variable alone is not normalised and contains 4 variables. (now that I think about it, custodianPublicAddress is redundant) .

So we are left with three useful pieces of data : tier, pair and market

With flexibility in mind, I suggest that we keep just one additional variable in the RPC (currently named identifier), rename it in something like "complementaryinfo" , and define how it should be structured as a String.

That way, the client would only need to know how to parse the data and adding/removing complementary information in the future will not demand client mandatory upgrade.

There also cons to this approach.

What is your opinion?

[Desrever Nu]

Here another useful piece of information to take into account :

Tier >2 liquidity will sit off exchange, in some hot/cold wallet. This means that, regardless of which client will report those tiers (may or may not be nubot), the information about "market" and "exchange" will become irrelevant.

[Michael Witrant]

That sounds good.

I'd keep the name "identifier" though because it's more than just complementary info. It's actually used as an identifier because the previous value is overwritten if you send the same ID twice.

Let's standardize the format of this identifier in this issue. To enable future changes the client will accept and propagate liquidity info even if the identifier format is not recognized. It will just not use the data (or only the data it was able to understand).

You're right the custodian address is redundant, so we should probably remove it.

I think another separator would be better because users can easily use _ in values. Something like :, , or |. This character would be only allowed as separator (we probably don't need escaping).

The tier field may be better at the beginning because that seems to be the most important value to the client right now (to display the total per tier). So the client could for now just split the identifier, use the first item and ignore the others (the complete identifier would still be reported by getliquidityinfo so custom tools could report extended information).

So maybe something like this: tier:pair:exchange?

Standardizing the pair and exchange names would probably be useful too.

[Desrever Nu]

So maybe something like this: tier:pair:exchange?

Deal.

let's make tier an integer value, single digit.

pair : Example: NBTBTC uppercase, six chars, the first three representing the order currency code, the last three representing the payment currency.

exchange : will build a csv vocabulary that can be shared.

Right now, this file can be used as reference ->

True. A first attempt to take into account is written inside this class : https://bitbucket.org/JordanLeePeershares/nubottrading/src/a009557f26cc79e11dea6c3a1067fe49fe092475/NuBot/src/com/nubits/nubot/global/Constant.java?at=develop

[Desrever Nu]

update1: the identifier field will also contain another field : an unique identifier for the bot session. There might be cases where he same custodians runs two instances of the bot on the same market/pair (maybe with a different API keys) .

update2: exchange codes are available in an externalised json file : https://bitbucket.org/JordanLeePeershares/nubottrading/src/333dfc5b9105456678bf188a5dc810a5c27dbd35/NuBot/res/exchanges.json?at=feature/179_exchangefile

[Desrever Nu]

Here is the changes in the upcoming 0.2.1 nubot version.

The liquidityinfo identifier will be formed by :

tier:pair:exchange:sessionid

sessionid being formatted as following : botVersion|startTimeStamp|randomID

Example :

2:BTCNBT:ccedk:0.1.5|1424193501841|d5ef77

[Michael Witrant]

@desrever what do you think would be a good size limit for the identifier? 255 bytes?

[Michael Witrant]

And would you agree to restrict to a limited character set? For example all the printable ASCII characters.

[Desrever Nu]

ACKd on the 255 bytes max. Currently the identifier it is a String formed by 40 chars.
Will nud handle larger identifiers gracefully, in case someone tries overflowing it manually?

Also, ACKd on restricting the charset to printable ASCII characters

2:BTCNBT:ccedk:0.1.5|1424193501841|d5ef77