Trust-less liquidity pool

[creon]

i mean there will be wall collision otherwise.

Why will this be the case? Both servers would use the same price. The only problem with multiple pool servers on a single exchange and pair is that people could submit the same order request to both servers in order to get twice the reward. It would be in the responsibility of the pool operators so synchronize the credited orders in this case such that each order will only be counted once.

[mhps]

Both servers would use the same price.

Would they? Because the peg spreads are tight slight differences in prices (due to different feed, weight scheme, response time…) and distribution of prices of the wall could cause collisions, when one pool/LPC’s wall can be eaten by another’s.

[creon]

All servers get the price from the same three tickers: bitfinex, coinbase, bitstamp every 30 seconds. Clients get the price for their orders from the server (they only use the tickers to verify that the server’s price makes sense).

Multiple servers therefore would need to synchronize their ticker calls (this can be done via ntp, just as NuBots do it with multiple-custodians=true), or even create a shared price representation (e.g. both grep a feed and then agree on the average).

You are right that it involves many additional aspects and I would not want to try it in the very first run. But I think that the problem itself is managable with the corresponding development effort.

Right now the client blindly would buy / sell into a wall. I agree this is not really in the intention of the customer and if orders are present at the corresponding position which would nullify the provided liquidity, then the bot shouldn’t place the order. This is also an option in the NuBot.

[mhps]

I gave the cliet a try from git bash window on win7 with command python ./client.py 104.245.36.10:2019 . It worked. I was able to place orders through the bot. I do often get error msgs

xxx ERROR: unable to receive balance for unit nbt on exchange poloniex: Nonce must be greater than 1426395000000. You provided 1426395000000.
xxx INFO: adjusting nonce of exchange poloniex to 105
xxx ERROR: unable to receive balance for unit nbt on exchange po
loniex: Nonce must be greater than 1426395052000. You provided 1426395052000.
xxx INFO: adjusting nonce of exchange poloniex to 155
…

When I pressed ctrl-C my order wasn’t canceled (is this a feature?). It would be nice if there is a quick command to cancel or orders.

Over all, this is really neat!

[creon]

When I pressed ctrl-C my order wasn’t canceled (is this a feature?). It would be nice if there is a quick command to cancel or orders.

Yes it deletes all orders on shut down (at least it tries 10 times until it gives up). In your case the nonce was too small and it would find some good offset after a while.

[creon]

Hi everyone,

The tests with the payout system went sufficiently well, and therefore the payed beta started today at 4pm UTC, Sunday 15th of March. I decided to set some parameters which would differ in a real operation:

1. The minimum payout is 0.03 NBT + txfee
   (in a real operation this should be larger)
2. The server tries every hour to send payouts if the minimum payout was reached
   (in a real operation this will be a 12h or 24h window)

Run the client with the this server address (NOTE THAT THE PORT CHANGED FROM PREVIOUS RUNS):

./client.py 104.245.36.10:2020
Please use the most recent client!

The server pays 7.75% per month (0.25% per day) for each exchange and order side up to 200 NBT liquidity. Payouts will be sent from BP3AVaDNHfqavNDAxGS3Puq2BqWySfMpiw which I will provide with some more funds soon. You can see that it already processed some test payouts I made earlier.

I am planning to fund the beta for 7 days and shut the server down after that. Note that other circumstances may lead to an immediate stop of the experiment at any time - your client then should automatically cancel all orders without you to take action, but please make sure that this is the case (its beta).

You would greatly help me if you would post or PM me the following information:

• The last balance shown by your client before a payout
• The amount received on your address
• Roughly the liquidity that you are providing

IMPORTANT: Please DO NOT use any large amounts of NBT in this experiment. I am not responsible for any money lost because of participating in the beta run. Furthermore the target values are small, and the server won’t pay any interest to users who provide liquidity above those 200 NBT.

Also please make a new exchange account if you want to participate. Please do not use your regular trading account.

Thanks for your support!

UPDATE: I’m sorry I had to restart the operation and changed some parameters. In order to have more of the most recent version I changed the port to 2020! So the new server address is 104.245.36.10:2020

[mhps]

The minimum payout is 0.03 NBT + txfee

In the config file, the first two parameters would be a nbt address and ‘nbt’, right ?

[creon]

In the config file, the first two parameters would be a nbt address and ‘nbt’, right ?

nbt address then ‘btc’ (without ') … you are always providing NBT liquidity so this specifies the other currency

EDIT: does it work?

[creon]

I updated the original post a bit (was about time). Let me know if you have some additions to the FAQ section or other questions.

Ideally I would like to have the original idea post now as second post of this thread. Is this possible? Mods?

[cryptog]

Giving it a try now on ccedk with 22.62620758 nbt only on the sell side.
Is it enough to get a reward?

[creon]

Yes, it should trigger a payout per day. Unfortunately the server shows a very bad connection status at the moment which is why your efficiency is so extremely poor. The server is located in California NA, so maybe there are just too many Americans watching netflix right now, I don’t know.

I hope that the server performance will improve over the next hours.

[cryptog]

why your efficiency i

I see. What is efficiency?

[creon]

Your client sends 20 requests per minute and the server tries to validate them. If those requests don’t show up in time (as it is the case right now) it is not able to validate the liquidity and therefore gives no credit (this is similar to PoW mining when the shares won’t reach the server).

The server is not on more load than on recent days so I really assume (hope) it is a temporary problem on the hoster’s side.

[cryptog]

Tks for the info.

[creon]

OK the problem really appeared to be a scaling issue (sorry for blaming the American netflix watcher ) . I replaced a component of the HTTP server module that allows more API calls and suddenly all server responses go through as intended (its even more responsive as before).

All users have an efficiency of around 100% now!

Unfortunately I had to restart the server in order so all balances are reset to 0. I’ll grep the credits lost from the log files tomorrow when I got some sleep and will send them manually.

Of course I hope this will be the last interruption, but on the other hand I am doing this to figure those things out, so thank you for your patience.

[cryptog]

restarted the bot. 100% accepted now…

wondering now about the difference between nubot and creonbot…
of course it s much simpler to set up creonbot but in terms of buy/sell strategies, how does it differ?

creon you should consider seriously becoming a part of nubot dev team

[mhps]

xxx:29 WARNING: too many rejected requests on exchange poloniex, adjusting nonce to 51
xxx:29 ERROR: exception caught: ‘Poloniex’ object has no attribute ‘acquire_lock’

the line before it was like

xx INFO: poloniex - balance: 0.00002100 efficiency: 0.00% rejects: 20 missing: 0 units: {u’btc’: {u’ask’: [], u’last_error’: u’unable to validate request: Nonce must be greater than 1426514510000. You provided 1426501871000.’, u’bid’: [], u’rejects’: 20, u’missing’: 0}} - xxxxxxxx-xx…

[cryptog]

sorry. it is 100% rejected not accepted

[cryptog]

getting for example 2015/03/16-15:17:10 INFO: ccedk - balance: 0.00506870 efficiency: 100.00% rejects: 0 missing: 0 units: {u’btc’: {u’ask’: [], u’last_error’: u’’, u’bid’: [[3228945, 22.7322302]], u’rejects’: 0, u’missing’: 0}} - ANTYAP7CYZM311H3SHGL1G6LBV3KL9K1138T1UOI65JQ3N73CAJB611L13MNSPGA

[willy]

efficiency: 100.00%

Everything fine there.

xxx:29 ERROR: exception caught: ‘Poloniex’ object has no attribute ‘acquire_lock’

That error is new. @creon?
Nonce adjusts are needed and performed regularly, no need to worry if the bot manages to find a nonce in the end.
If not, especially on bitcoincoid, a new API key could be needed.