[Passed] NuPond operation on Bter's NBT/CNY pair

[Cybnate]

Sorry. I am late. [1381ae23c3686167e8fc86ed185fe2539106a5d9] verified and voted.

So am I. Will be added to my datafeed in next hour or so.

[Nagalim]

Exchange fees eating money is a general problem for liquidity providing.

Two points here.

1. Bter has said they will lower the trading fee to .1%. This will mean providers will indeed profit off the spread.
2. Bter has said they may provide liquidity. If the exchange is participating, exchange fees are not our enemy, they keep bter happy such that they may provide even more liquidity if all goes well.

But if your funds get shifted 4 times from NBT to CNY and back per month, you pay an exchange fee of 420.2%=1.6% which is higher than the expected rewards per month.

This is not the case unless your spread is 0%. My spread tolerance is 2.5%, so if you use the numbers in my bot you will end up with a 0.2% spread, perfectly offsetting the standard fee. As I said, if Bter lowers the fee then providers have even more to gain here.

[peerchemist]

Voting since you have posted.

Btw, is it complicated to get Fiat (CYN) to Bter from Europe? How do you do it?

[Nagalim]

Fiat (CYN) to Bter

Bter has a pretty good CNY market. You can send almost any of the major cryptos there to sell them (try to get a good price). Also, they accept btc-e codes I think. It’s hard for me to tell, because their CNY deposit page is in chinese. @wengone can you help do a rough translation of the bter CNY deposit page into english? It’s for btc-e codes right?

[Nagalim]

Big NBT buy (450 NBT, basically all our sell side liquidity). We’re now number 19 for volume on Bter’s CNY charts. So hooray! I hope whoever’s liquidity that was ( @masterOfDisaster? ) will put the CNY on buy side so we can boast a heavy buy side on bter.

[masterOfDisaster]

Woops!
Nice
Put the CNY on buy side!
…I need to take a break.

[tomjoad]

Are NSR holders asleep?

Evidently I was, apologies to @Nagalim for missing this. I am voting for this now.

[Nagalim]

Ideally, the bot should put that order up itself so you don’t have to even know it happened. Did you have to restart the bot to get it to work? I hope we work out bugs like that eventually so you never have to manually touch the bot after the initial setup.

Does anyone know how/when the NBT/CNY pair will show up on coinmarketcap? $450 volume would put us at number 3 just under Bittrex in terms of daily NBT volume and contribute 20% to the total daily volume for NBT. And it was all above $1/NBT.

I don’t think this one buy is properly indicative of the future, but if it is, hoorah.

[masterOfDisaster]

Did you have to restart the bot to get it to work?

The bot was at

2015/05/20-21:11:11 INFO: bter - balance: 0.08162923 rate: 0.01% ppm: 0.00000491 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 24.5000 x 0.01% - ask: 46.2473 x 0.01% - APIKEY

That’s why I restarted it and got

2015/05/20-21:11:53 INFO: starting PyBot for cny on bter
2015/05/20-21:11:53 DEBUG: starting liquidity operation with sampling 96
2015/05/20-21:11:54 INFO: successfully deleted all orders for cny on bter
2015/05/20-21:11:54 INFO: waiting 5.78 seconds to synchronize with other trading bots for cny on bter
2015/05/20-21:12:02 INFO: successfully placed bid cny order of 454.6660 nbt at 6.18994530 on bter
2015/05/20-21:12:03 INFO: successfully placed ask cny order of 46.2480 nbt at 6.21475470 on bter
2015/05/20-21:12:53 INFO: bter - balance: 0.08164261 rate: 0.01% ppm: 0.00003479 efficiency: 100.00% rejects: 0 missings: 0 - cny - bid: 454.6660 x 0.01% - ask: 46.2480 x 0.01% - APIKEY

Should I have waited some time and would the bot have adjusted that without being restarted?

[woolly_sammoth]

I would have hoped the bot would pick up the new balance and place the orders accordingly. The loop the bot uses is about a minute so it may take a while depending on when the balance shows up in the api call.

[Cybnate]

Just noticed that a significant percentage of the votes is going to 1381ae23c3686167e8fc86ed185fe2539106a5d9 which is only the hash of this custodial grant:

Custodial Address: B8K2wj2i7JTSgSo73P74qvBETy4kpfp6UX
Amount Requested: 300 NBT

Please make sure you add this custodial grant request as such in the client instead as a motion hash.

[Nagalim]

Thank you shareholders.

[masterOfDisaster]

Thank you for your confidence in the Nu network!

[masterOfDisaster]

When I had a look at http://nupond.net/status

{"credits": 12753, "users": 4, "validations": 306079, "liquidity": [50.979166666666664, 29.911250000000006], "sampling": 24}

I was wondering and had a look at my bot. It had removed all orders and started to place 1.00 NBT orders - it was already at 34 NBT at bid side and 36 NBT at buy side.
I stopped the bot (canceling orders took some time) and after starting it again it was running fine.
This 1 NBT order thing is really annoying…

[Nagalim]

This 1 NBT order thing is really annoying…

I have been so frusterated with this bug for the last week, it’s seriously demoralizing. My buy side support wanes not because I don’t have willing custodians or a listening grant server, but because my custodians can’t keep their orders on the exchange!

I have been looking into this bug every night and I was hoping to come up with a temporary solution before posting about it, but no such luck. My current attempt at a solution is to restart the entire client when it goes into the bugged mode. By the way, the “1 nubit at a time” bug is not the only manifestation of the bugged mode, and a client restart always fixes it until it drops into that mode again.

@woolly_sammoth @willy @Cybnate

[masterOfDisaster]

By the way, the “1 nubit at a time” bug is not the only manifestation of the bugged mode, and a client restart always fixes it until it drops into that mode again.

I can confirm that based on my experience so far.

[woolly_sammoth]

Hi All,

The 1NBT does seem to be triggered by a certain set of circumstances in which the calculation which determines if the client should place more funds on order goes into some sort of loop.
I have read and re-read the peice of code that seems to be at fault and can’t find any obvious problems in the logic. I’d like to understand morefully what the set of cicumstances are. My latest build on github contains some simple logging outputs to see what all the variables involved are set to when the problem code is triggered.
@Nagalim, could you copy those log lines from my client into yours so that, when this happens again, we can try and track through what is going on with some real data?

I’ve not ever seen the behaviour myself but would be very interested to try and understand what is going on and fix it.

[Nagalim]

If you want to see the behavior more, turn down the ‘deviation’ maximum. That is why my pool experiences this problem more than the others: I am trying to keep a tighter peg. When I do my testing, I use a deviation of like 0.03% and I see the problem fairly often. It has to do with how much the ticker price is changing.

[mhps]

Alll this time I thought the 1NBT orders was a feature to somehow discourage attack on pegs of illiquid pairs.

[Nagalim]

Selling on the bter peg is not an attack! It is one of the best ways to get CNY onto bter, as NBT is fast confirming, nonvolatile, and we keep the peg tight. The more people realize that, I think we will see more liquidity offered there.

Just need to get rid of these darn bugs first.

The parametric orderbook may mitigate legitimate concerns you have about what occurs in a peg-break scenario. I’m not sure if it’s being planned to roll out on tllp’s though. Creon once came up with a layered payment system where different spreads would be paid a different premium, such that people can run the parametric orderbook and get paid varying amounts based on the parameters and how much risk they’re taking.