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.
Restarted.
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…
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.
Idk. I just generated a completely new key (again) and that one worked fine.
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.
You mean this spread?
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.
Here is the deal:
So what you can do is to make the trading bot more sensitive by drastically reducing the maximal deviation in the line above. Then you can increase the spread to up to 0.5%. The bot will then reset the orders even on tiny variations (which may lead to missings) but this will ensure that the price deviation on server side will always be 0.5%.
Feel free to play around with the spread. If you set it too high, then you will see 0% performance with 20 rejects and in the last_error field you will see a message telling you that your price deviates too much.
But in my understanding, the pool manager sets the interest rate.
So you cannot say I want 9% if the pool manager will only give you 7%. Could you clarify a bit?
Tks. I will give it a try.
By the way, http://104.245.36.10:2020/ is down currently.
It starts to become nasty that it always crashes over night. I’m doing some research on that today. It is up again.
Correct, so the pool operator can still define a maximum interest rate (that’s what the 9% in my example was). Let’s further say the target value is 100 NBT.
Now we both connect to the server with 75 NBT, but you would also do it for 7% while I strictly only do the job for 9%.
If we now both place our orders at the same price, the server will first consider your funds to fill the 100 NBT target and then mine (because of the interest rate) and will pay 7% * 75 NBT to you and 9% * 25 NBT to me.
Does this make sense? I am planning to create some illustrations on the system later, just couldn’t find the time so far.
So you define an absolute total reward independent from the interest rate, waiting for the first mover to eat it up.
That fosters competition.
It makes total sense.
I have probably missed something, but how can you have fixed size payments to participants denominated as interest rate?
Should that not be determined by conditions on market and dependant on actual volume?
I think I don’t understand the question. The server validates request every 3 seconds. For each of these requests it credits the interest rate times the provided liquidity at this point (where the interest rate is broken down to interest per 3 seconds). So it is not fixed size in this sense, if this was what you were asking.
Low volume itself is not tackled by the system (I am also not sure how to encourage volume without doing immoral things). Unbalanced liquidity is first attacked by having a specific target value for both sides of the market, so if the buy side liquidity is full then the server will not compensate any funds above this target.
The other force to counteract unbalanced liquidity is the variable interest rate approach described above, such that user can propose a minimal interest rate they are willing to get. The market then (hopefully) will automatically rebalance since the interest rate for the underperforming side will increase.
All above thoughts rely on the assumption that there are enough pool participants in order to create this competition.
updated to the latest verion. Got error
> python ./client.py 104.245.36.10:2020 Traceback (most recent call last): File "./client.py", line 140, in <module> cost = { 'bid' : exchangeinfo[name][unit]['bid']['rate'], 'ask' : exchangeinfo[name][unit]['ask']['rate'] }
bad move 
I didn’t branch correctly and then pushed into master after a while, I’m a git noob. If you want I’ll look up the commit for you where it should still work with the old server.
EDIT: here it is: 34155c9855f4ded330c266de609c71777417df48
git checkout 34155c9855f4ded330c266de609c71777417df48
I am in the final testing phase of the new server / client system and will install it tomorrow if everything goes well. Then you will be able to connect with the new client (although I will change the port to avoid more incompatible connection attempts).
Never mind. Take your time.
Successfully testing on Win7-64bit with Python and NuPool 0.15.
100% efficiency, 0 rejects. Seeing my ‘reward balance’ going up every minute. Neat. Already earned 0.0001 NBT after 10 minutes.
The python download and the funds transfer took me the most time 
It is really simple to install, although I can imagine that some users shy away from completing the user.dat. A simple gui would make it more user-friendly.
Looking forward to further developments.
Hello Nu community,
The one week of the initial beta phase is over. Up to 17 keys were connected at some days and the frequent server crashes might have discouraged some, but in total I am very happy with the general performance and in particular about the feedback I got. I will probably also prepare some visual data when I find to the time.
Many issues were reported and partly fixed on the fly, however, some problem required deeper changes. Today I would like to start a second beta run, which uses an improved client / server architecture and many new features.
This is the major feature which comes with this release and which I would like to test during the beta run. For every key in the users.dat you need to specify two additional numbers which correspond to the minimal interest rate you are willing to get for your liquidity in percent, for the buy and ask side respectively.
So each line in the users.dat now looks like this
payout-nubits-address btc exchange api-key api-secret bid-interest ask-interest
Example:
BQRKF4X8gFLyHGVeym8tuff57PcJczYPVg btc poloniex 85BQTQG1-N3D3PFKX-YUNIHIO1-WQCWTRER 1234abc 0.8 1.2
In the example I am asking for 0.8% on the buy liquidity that I am providing, and 1.2% on the sell liquidity
Please connect your client to the new server (note that I changed the port again to 2022):
./client.py 104.245.36.10:2022
During the second phase of the beta I am paying up to 5% per day for a target liquidity up to 20.0 NBT for each side of the market. The reason for the small target values is to see as much competition as possible, because the variable interest rate rule only goes into action if the liquidity provided is above the target value.
This section is only for the people who are interested - you don’t have to take any action to improve the interest you get. The server will always pay you the maximal possible interest rate. My goal is to ensure these two points:
This is ensured on server side by sorting all orders by their minimal interest and then to pick the next higher interest seen in the order list for each user.
UPDATE: In order to ensure (1) a different server behavior had to be implemented. The server now calculates the total amount of coins above the target and compensates them as described above (up to the limit). The remaining liquidity is paid with the pool’s maximum interest. See the updated examples below to see how the effect of this change.
Let’s consider some examples to clarify what this means. Here the server now provides 5% maximal interest up to a target limit of 20 NBT, as used in the second beta run.
Two users, Alice and Bob, are providing liquidity in our example and Alice asks for a minimal interest rate of 2% and Bob asks for a minimal interest rate of 3%. We further assume a single market side on one market (e.g. sell side on Poloniex).
Alice and Bob both provide 10 NBT
Payout: Both will get 5% * 10 NBT
Reason: Their combined liquidity is 20.0 NBT which is within the target.
Alice provides 10 NBT and Bob provides 15 NBT
Payout: Alice will get 5 NBT * 3% + 5 NBT * 5% and Bob will get 5 NBT * 0% + 10 NBT * 5%
Reason: The total amount is above the target and clients are in competition for the 5 NBT which was provided in addition to the target value. Bob is not willing to provide NBT for less than 3%, but Alice is, so the system will grant these 5 NBT to Alice at the best possible interest rate for Alice (3% - epsilon = 3%). The remaining target will be filled with remaining 5 NBT of Alice first, end then finally with 10 NBT of Bob’s liquidity at the pool’s maximal interest rate.
2.1 Alice decreases her minimal interest rate to 1%
Payout: The same, since she will still get Bob’s 3%.
2.2 Bob decreases his minimal interest rate to 2.5%
Payout: Alice’s payout interest rate on her 5 NBT will reduce to 2.5%.
2.3 Alice increases her funds by 5 NBT (i.e. from 10 NBT to 15 NBT)
Payout: Alice will get 10 NBT * 3% + 5 NBT * 5%, Bob will get 5 NBT * 5%
Reason: The amount of liquidity above the target increased from 5 to 10 NBT. Alice still has the best offer, so her 10 NBT will be compensated first.
2.4 Willy joins the pool as third participant with 4% minimal interest
Payout: 10 Bob’s payout interest rate reduces to 4%, willy won’t get any payout
2.5 Joe joins the pool as third participant with 1% minimal interest and 15 NBT
Payout: Joe will get 2% * 15 NBT, Alice will get 3% * 5 NBT, Bob will get nothing
Important: Clients will remove orders which give 0% interest. So from now on you might find some funds on your exchange account which are not in orders. If you are not planning to decrease your minimal interest rate, then you should remove some of those funds from the exchange in order to reduce your risk.
I hope these examples help to understand the basic idea and I further hope that there isn’t some major flaw in the concept I do not see. So would be nice if our economy experts would give it a thought.
Oh you will like what @woolly_sammoth is currently finalizing. It will be a high class platform independent GUI which brings a lot of fun into the whole process, and of course makes it also very easy to configure.
EDIT: One more thing for the shareholders: The interest rate will be passed over to the final liquidity fee. Every minute (where the pool credits payouts), the server updates this page: http://104.245.36.10:2022/exchanges
I know its horrible to read for humans, but it allows to verify at any point in time which interest rates the server payed to the customers. In order to check if the server tricks the data, you can run a simple bot that places small orders, sends them to the server and checks the payout obtained. I am very open for discussions about the problem of proving interest rates to the shareholders - this solution is the best I got so far but I am willing to spend serious development effort to make this verifiable for the shareholders if the current method is not sufficient.
This is disappointing.
Here if Alice increases her minimal interest rate to 4%, she will get in fact 10NBT * 5% which is more than 10 NBT * 3%.
That is contradictory to
or should I interpret payout as the maximal absolute reward?
EDIT: typo.