[BTC-TC] Virtual Community Exchange [CLOSED]

[freedomno1]

Was about to ask why I was getting so many invalid inputs but reading through not alone so will wait on the update
Also about the bots do what the german's do
http://www.eurexchange.com/blob/exchange-en/3150-410008/410090/4/data/HFT-BAI-presentation.pdf

[1714023184]

1714023184

[1714023184]

1714023184

[1714023184]

1714023184

[dexX7]

Was about to ask why I was getting so many invalid inputs but reading through not alone so will wait on the update
Also about the bots do what the german's do
http://www.eurexchange.com/blob/exchange-en/3150-410008/410090/4/data/HFT-BAI-presentation.pdf

Interesting read. Some keywords to dig: quote stuffing, momentum ignition, layering and spoofing

Not necessary bound to bots though.

[pascal257]

Well I don't want to hate or anything, but exceeding 100k BTC per month in transaction volume should enable burnside to upgrade the hardware and maybe employ someone for support.

[lewicki]

There have been 3 securities sitting at a 4/0 approval rating for a week now. Are there any behind the scenes discussions on these securities, or are they just languishing?

[twentyseventy]

Is the exchange down? Not seeing any activity for the last 7 hours?

[David Chen]

Well I don't want to hate or anything, but exceeding 100k BTC per month in transaction volume should enable burnside to upgrade the hardware and maybe employ someone for support.

+1

[jshinra]

Is the exchange down? Not seeing any activity for the last 7 hours?

I've been trying to set up some trades but keep getting "Invalid Ask Input."

[ArcticWolf]

What happened that made it seem as if the bot had advance knowledge about your trades?

The point is that the frontend of BTCT waits before it reloads the page. Why is this "wait time" programmed in the front end when it is not needed?

Because of the trade bots have an advantage.

The wait-period is a standard, though perhaps somewhat outdated, method for a website to show a successful request message. Show a short message, then automatically return to the previous page. Not showing a message and instantly reloading the previous page is, in my opinion, bad design and can leave users confused.

A better, more modern solution is to use AJAX-methods for submitting orders and make a popup box appear on the page when an order is submitted and the contents of the page are updated without actually reloading the page.

As for the bot-advantage, I believe the order is processed when you reach the message-page, so there is no delay in actually having the order listed, just a short delay in seeing the new orderbook.

I agree that the ajax response would be nice.  To do it though you have to ajaxify not just the response, but also the reload of the underlying page.  I was concerned that I'd miss something trying to reload just certain pieces of the underlying page, so I chose to do something that reloads the entire page.

Say we do a simple buy transaction.  The parts of the page that need to reload are:

- the header (balance display)
- the ticker table showing recent trade stats
- the volume graph
- the market depth graph
- the table of your current orders
- the order book
- the trade history (trade tab)
- the outstanding share count (details tab)


Regarding the bots...

ANNOUNCING... A potentially breaking change, depending on how your bot is written.

I will be rolling out a change tonight that will limit any bid or ask order to a maximum of 4 significant digits.  What does this mean?  Here are some examples:

Bid           Becomes

10123.5    10120.0
1012.35    1012.00
101.235    101.200
10.1235    10.1200
1.01235    1.01200
0.101235    0.101200
0.0101235    0.0101200

I hope that makes sense.  It will thus require any order placed to be a semi-reasonable increment above or below existing orders.  Bots should no longer be able to outbid you by using insignificant digits.  Important note!  The system already rounds down on bids and up on asks but this change will make this behavior that much more apparent.  If you place a bid or ask and it shows up for more or less than you were expecting, it's the rounding and it is intentional.

I expect to roll out this change in 6-8 hours.

Cheers.

Something to do with this change being implemented maybe?

[Rannasha]

Trading seems to be going on normally again at BTCT

[burnside]

What happened that made it seem as if the bot had advance knowledge about your trades?

The point is that the frontend of BTCT waits before it reloads the page. Why is this "wait time" programmed in the front end when it is not needed?

Because of the trade bots have an advantage.

The wait-period is a standard, though perhaps somewhat outdated, method for a website to show a successful request message. Show a short message, then automatically return to the previous page. Not showing a message and instantly reloading the previous page is, in my opinion, bad design and can leave users confused.

A better, more modern solution is to use AJAX-methods for submitting orders and make a popup box appear on the page when an order is submitted and the contents of the page are updated without actually reloading the page.

As for the bot-advantage, I believe the order is processed when you reach the message-page, so there is no delay in actually having the order listed, just a short delay in seeing the new orderbook.

I agree that the ajax response would be nice.  To do it though you have to ajaxify not just the response, but also the reload of the underlying page.  I was concerned that I'd miss something trying to reload just certain pieces of the underlying page, so I chose to do something that reloads the entire page.

Say we do a simple buy transaction.  The parts of the page that need to reload are:

- the header (balance display)
- the ticker table showing recent trade stats
- the volume graph
- the market depth graph
- the table of your current orders
- the order book
- the trade history (trade tab)
- the outstanding share count (details tab)


Regarding the bots...

ANNOUNCING... A potentially breaking change, depending on how your bot is written.

I will be rolling out a change tonight that will limit any bid or ask order to a maximum of 4 significant digits.  What does this mean?  Here are some examples:

Bid           Becomes

10123.5    10120.0
1012.35    1012.00
101.235    101.200
10.1235    10.1200
1.01235    1.01200
0.101235    0.101200
0.0101235    0.0101200

I hope that makes sense.  It will thus require any order placed to be a semi-reasonable increment above or below existing orders.  Bots should no longer be able to outbid you by using insignificant digits.  Important note!  The system already rounds down on bids and up on asks but this change will make this behavior that much more apparent.  If you place a bid or ask and it shows up for more or less than you were expecting, it's the rounding and it is intentional.

I expect to roll out this change in 6-8 hours.

Cheers.

Something to do with this change being implemented maybe?

Trading is back.  I was working on the release above.  I apologize for how long it took.  Should have been super simple but when I rolled my dev code into prod it wasn't working and tracking down the issue took a while.  I'm getting too old for the middle of the night roll-outs.  

Note that filling some orders now is going to be kind of tricky.  Ex:

order book ask: 0.11111
you bid: 0.11111
system rounds to 4 significant digits: 0.1111
0.1111 < 0.11111 so an order gets placed instead.
You'd have to bid 0.1112 to fill the order.

I'm currently working on this issue.


Cheers.

[Peter Lambert]

should lower priced assets (like s.mpoe-pt) allow more than 6 digits past the decimal so that they can have 4 significant digits?

0.00087654 should be rounded to 0.0008765 to have four sig figs, but is being rounded to 0.000877 to have only 6 decimal places?

[burnside]

should lower priced assets (like s.mpoe-pt) allow more than 6 digits past the decimal so that they can have 4 significant digits?

0.00087654 should be rounded to 0.0008765 to have four sig figs, but is being rounded to 0.000877 to have only 6 decimal places?

That's a display bug I'll have to fix.  Thank you for pointing it out!

[pascal257]

should lower priced assets (like s.mpoe-pt) allow more than 6 digits past the decimal so that they can have 4 significant digits?

0.00087654 should be rounded to 0.0008765 to have four sig figs, but is being rounded to 0.000877 to have only 6 decimal places?

That's a display bug I'll have to fix.  Thank you for pointing it out!

I suppose this would also require an API change, or is it rounded correctly with the new version?

[Rannasha]

(It took quite a bit of testing just to develop the algorithm even.)

(from the other topic, that is now locked)

I'm curious what algorithm you used, since it seems to me that the rounding of the input can be done in a single-line statement:

Code:

$res = pow(10, floor(log($p, 10))) * ceil(1000 * $p / pow(10, floor(log($p, 10)))) / 1000;

(replace ceil() by floor() for bids. I suppose you could make it more readable by splitting it in more lines)

[burnside]

(It took quite a bit of testing just to develop the algorithm even.)

(from the other topic, that is now locked)

I'm curious what algorithm you used, since it seems to me that the rounding of the input can be done in a single-line statement:

Code:

$res = pow(10, floor(log($p, 10))) * ceil(1000 * $p / pow(10, floor(log($p, 10)))) / 1000;

(replace ceil() by floor() for bids. I suppose you could make it more readable by splitting it in more lines)

It's the following:  (as you mentioned, floor/ceil per bid/ask)

Code:

$amount = bcdiv(floor(bcmul($amount,sigDigitMultiplier($amount))),sigDigitMultiplier($amount));

Where sigDigitMultiplier is roughly: (has some input validation around it, which is what was breaking it...)

Code:

return pow(10,ceil(0 - log10($amount)) + getsetting("sigdigits") - 1);

Let me know if you see any big holes in that... or obvious ways to reduce it down. 

[ThickAsThieves]

Might be worth adding a 7d figure to the Dividend Yield Estimates, to get a clearer picture of the current state of things on assets that have declined in shareprice value, yet have a history of higher divs.

[burnside]

Might be worth adding a 7d figure to the Dividend Yield Estimates, to get a clearer picture of the current state of things on assets that have declined in shareprice value, yet have a history of higher divs.

It should already be 8 digits where applicable.  Ex: https://btct.co/security/GSDPT

[ThickAsThieves]

Might be worth adding a 7d figure to the Dividend Yield Estimates, to get a clearer picture of the current state of things on assets that have declined in shareprice value, yet have a history of higher divs.

It should already be 8 digits where applicable.  Ex: https://btct.co/security/GSDPT

I think you might've misread my post

[pascal257]

It should already be 8 digits where applicable.  Ex: https://btct.co/security/GSDPT

Thats also available through the API? Whats the maximum digitcount for LTC-Global? Still 4 or did it also increase?

[burnside]

Might be worth adding a 7d figure to the Dividend Yield Estimates, to get a clearer picture of the current state of things on assets that have declined in shareprice value, yet have a history of higher divs.

It should already be 8 digits where applicable.  Ex: https://btct.co/security/GSDPT

I think you might've misread my post

Indeed.  I thought you meant 7 digits, not 7 day.    (been too focused on digits!)

Edit: Expanding on this.  It already uses the 7d value of the security for the calculations, thus the calculations you see should reflect price drops fairly quickly, though not quickly enough for some, and not slowly enough for others I'm sure.  Adding a 7d yield for most issues would (best case) only take into account the most recent weekly div and (worst case) show zero yield 3/4 of the month on issues that only have monthly divs.  The only ones it really works for are those with daily divs, and most of those are stable enough that a 30d is a better picture anyway.

Am I missing anything?

It should already be 8 digits where applicable.  Ex: https://btct.co/security/GSDPT

Thats also available through the API? Whats the maximum digitcount for LTC-Global? Still 4 or did it also increase?

LTC-GLOBAL has the same code as BTC-TC for the most part.

I don't think the div yield numbers are available via API.  They're kind of an interpreted value that you're better off calculating yourself using your own preferred inputs if you can.  (And I suspect you can if you're up to using the API.)

Cheers.