Trust-less liquidity pool

[Joe]

New keys set up. I’ll let you know when I receive a payout to confirm.

and thanks for the tip! Although honestly I feel like you deserve it more than myself.

[creon]

I’ll let you know when I receive a payout to confirm.

Well unfortunately all balances are reset to 0.0 due to the server restart, so your lost all credits below 0.03 NBT and also missed out in my “apology transaction” since your address wasn’t an NBT address … so see the tip as replacement and bounty for the bug find

[creon]

I think you misconfigures something… it says “invalid key pair”. Are you sure you placed the key in front of the secret in the users.dat?

[Joe]

I was very careful and just double checked. I remember when generating keys for poloniex it took an hour or two for them to “activate”. I upgraded to 1.15 as well to hopefully fix some issues.

[cryptog]

Got 0.0316, 0.16 and 0.14 NBT this morning.
I am not sure to how many orders submitted by my client to the server 0.0316 corresponds to.
But tks.
Also upgraded to 1.15.
Got socket error at the beginning but now it is running smoothly.
By the way

ince otherwise people could steal your credits if they know your public key.

My understanding is that you need to know the private key to sign the orders submitted to the server.
So the only way for someone to steal your credit would be to actually replace the payout address…Am I wrong?

[creon]

So the only way for someone to steal your credit would be to actually replace the payout address…Am I wrong?

Yes that was exactly what this was about. @Joe first registered with a Bitcoin address and wanted to change it to an NBT address, but I don’t allow him to register the same exchange public key with another payout address because of the reason you are describing.

The private key is not even touched by the user during registration.

0.16 and 0.14 NBT this morning

These were the apology transactions for restarting the server, which is why your balance should be around zero now. Don’t get used to it

[cryptog]

I don’t allow him to register the same exchange public key

Nice precaution indeed then.

[cryptog]

By the way I think that would be great to have some statistics like “you submitted x valid orders transactions…over the last past y seconds. Therefore you will get z reward that will be given by the pool.”

Also, that would be great to have a real time measurement tool which would display the orders submit rates per second like the hash rate per second.

A comparison that came up into my mind:

Bitcoin…mining…hash rate
NuBit…liquidity providing…order submits rate
NuShares…voting…Nu ownership percentage.

[creon]

By the way I think that would be great to have some statistics like “you submitted x valid orders transactions…over the last past y seconds. Therefore you will get z reward that will be given by the pool.”

x = 20 - missings - rejects
y = 60
z = balance

A larger time span y would be nice, I agree, the console output is currently more for debugging purpose. The “hash rate” basically corresponds to your liquidity (also shown in the last json object in the terminal) times your efficiency. So if you are providing 100 NBT liquidity at 80% performance and 10% interest rate, then you will get a reward of about 8 NBT.

EDIT: Ah with z I think you mean something like what the server dumps when it credits the coins!? This indeed would be nice as API call. I’ll do that tomorrow. Thanks!

[cryptog]

your liquidity

That would be great to see how the others perform as well for each exchange and get a pie chart of the contributors to the liquidity pool.
That would come later for sure if this design is sustainable

dumps when it credits the coins!

Yes for example.

[cryptog]

socket connection errors in a row right now.

[cryptog]

http://104.245.36.10:2020/ down

[creon]

The server restarted, I missed a maintenance email that announced that. Should be up again.

[creon]

OK I noticed that all your clients suspended all trading activity, which is good and intended considering the server outage, but they don’t want to start the trading bot again now that the server is back up and therefore you are not placing any orders.

This means that for now you need to restart the client to get credits again (note that you are also not exposing your money to the market). I’ll fix that later today.

[Ben]

Restarted.

[cryptog]

Will need to run the code on my vps from now on.
At home now and the code runs on a local machine at my office…

[mhps]

I remember when generating keys for poloniex it took an hour or two for them to “activate”.

It’s instant for me. You have to press “Update” button to see the new key afte r you have pressed “Create new” to make a new one.

[Joe]

Idk. I just generated a completely new key (again) and that one worked fine.

[cryptog]

Did not need to restart the client.
It connected fine during the night and has been supporting the peg since then.
There have been a lot of buy/sell orders since yesterday’s evening (30 transactions involving 20NBT or so in my case ) (bitcoin down 11% is probably the main reason).

However, since the beginning of the experiment, my fund has lost 3.5nbt.
I estimate the trading fee part to 1.5nbt. (37 transactions * 20 nbt * 0.2%) more or less.
I guess the downtrend volatility of btc explains the rest (2nbt)

But more importantly, the monthly interest rate is 7.75% which would mean in my case 1.5nbt or so a month for the reward.

After only a fews days of experimental operations, I am already in the red in terms of profits because only of the trading fee.

Which would imply, if I extrapolate a bit, that providing liquidity with a high trade volume (say 30 transactions per day) is not profitable at all, at that current monthly interest rate,

At 0.2% per trade (ccedk), you only need 38 transactions per month, involving the full amount of your fund to get in the red.
Which means 1.3 transaction per days…

I must have forgotten a parameter…Yes the spread.
What is the current spread for ccedk when I run client.py? And if I want to modify it could I do so while preserving the reward scheme contract?
In the positive case, having an additional argument in the command line would be great.

[creon]

I must have forgotten a parameter…Yes the spread.

You mean this spread?

verc/nu-pool/blob/master/python/trading.py

If I wouldn’t apply any spread, orders would eliminate each other immediately

So the trading fees are not the problem here. Some people might have successfully hedged against you - which could become a losing or a winning trade to them in mid term, as I observe it regularly in my custodianship on bitcoin.co.id.

But yes, its the risk you take and what you are getting paid for. If you provide liquidity at a certain interest rate, then you are betting that the market will cost you less than the interest. Now in a situation like today you might be right that 7.75% is not enough, while on a day where BTC goes flatline you can argue that people should be satisfied with 3%.

I am currently implementing something to take this into the users control: in future users can configure and submit a minimal interest rate they want to have for pegging against a unit on a particular exchange. This means clients are in competition against each other, since liquidity will as usual only be compensated up to the target limit. If the pool then offers let’s say up to 9%, then people can increase their minimal interest rate for the buy side liquidity in order to balance their risk.

So sorry for your loss (I guess many people lost money on today’s btc ride) - that’s how it can feel being a custodian. I just hope you still think the idea is worth following especially with the improved interest rate system described above.