[BTC-TC] Virtual Community Exchange [CLOSED]

[TsuyokuNaritai]

It seemed that the bot had advance knowledge (about my trades) and a faster trading speed (its trades were processed faster) than I had because of the wait times.

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

[Lytse]

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?

One of the questions was: "Is the wait time also enforced on the OAuth trade endpoint?"

I think both methods of trading should experience the same wait times.

[Rannasha]

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.

[Lytse]

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.

It's always bad to use outdated standards. But it probbably takes a lot of effort to redesign.

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.

So... There is an andvantage, good to know.

Thanks for the information.

[Rannasha]

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.

So... There is an andvantage, good to know.

Thanks for the information.

I'm not even sure if it's an advantage. The event-flow when submitting orders is as follows:

Manual / person:
Submit order ----> Result page --(wait or click)--> Reloaded asset-page

Bot:
Submit order ----> Result response

In both cases, the actual order is listed at the first arrow, directly after the submission has been sent. All a bot gets is a response that tells it whether the order was successfully submitted. A normal person gets the same response on the intermediate page that redirects back to the asset-page after a few seconds (or when the user clicks a link).

[Lytse]

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.

So... There is an andvantage, good to know.

Thanks for the information.

I'm not even sure if it's an advantage. The event-flow when submitting orders is as follows:

Manual / person:
Submit order ----> Result page --(wait or click)--> Reloaded asset-page

Bot:
Submit order ----> Result response

In both cases, the actual order is listed at the first arrow, directly after the submission has been sent. All a bot gets is a response that tells it whether the order was successfully submitted. A normal person gets the same response on the intermediate page that redirects back to the asset-page after a few seconds (or when the user clicks a link).

In my browser it is not possible to click....

There is an advantage when you get the information sooner, the diagram is as follows:

Manual / person:
Submit order ----> Result page ------>    (wait_time)  -----> Reloaded asset-page

Bot:
Submit order  ----> Result response
                      Submit request order book ---> order book

[Rannasha]

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.

So... There is an andvantage, good to know.

Thanks for the information.

I'm not even sure if it's an advantage. The event-flow when submitting orders is as follows:

Manual / person:
Submit order ----> Result page --(wait or click)--> Reloaded asset-page

Bot:
Submit order ----> Result response

In both cases, the actual order is listed at the first arrow, directly after the submission has been sent. All a bot gets is a response that tells it whether the order was successfully submitted. A normal person gets the same response on the intermediate page that redirects back to the asset-page after a few seconds (or when the user clicks a link).

In my browser it is not possible to click....

After submitting, there's a box that says "Redirect to /security/DMS.SELLING in 7 seconds..." (obviously different for different assets and the timer counts down). The "/security/DMS.SELLING" part of this is a direct link to the asset-page.

There is an advantage when you get the information sooner, the diagram is as follows:

Manual / person:
Submit order ----> Result page ------>    (wait_time)  -----> Reloaded asset-page

Bot:
Submit order  ----> Result response
                      Submit request order book ---> order book

This advantage doesn't come from the design of BTCT though. You could have the order book open in a different browser tab and after clicking the submit order, go to that tab and refresh it.

Bots will always be able to beat humans with parallelized requests and faster information processing. That's a generic feature and independent of BTCT.

[Lytse]

In my browser it is not possible to click....

After submitting, there's a box that says "Redirect to /security/DMS.SELLING in 7 seconds..." (obviously different for different assets and the timer counts down). The "/security/DMS.SELLING" part of this is a direct link to the asset-page.

I will try this next time I trade.

This advantage doesn't come from the design of BTCT though. You could have the order book open in a different browser tab and after clicking the submit order, go to that tab and refresh it.

Bots will always be able to beat humans with parallelized requests and faster information processing. That's a generic feature and independent of BTCT.

I agree, but I am wondering why someone creates a trading bot that blockes a fair price for others and trades towards a fixed price..... 

[Rannasha]

In my browser it is not possible to click....

After submitting, there's a box that says "Redirect to /security/DMS.SELLING in 7 seconds..." (obviously different for different assets and the timer counts down). The "/security/DMS.SELLING" part of this is a direct link to the asset-page.

I will try this next time I trade.

This advantage doesn't come from the design of BTCT though. You could have the order book open in a different browser tab and after clicking the submit order, go to that tab and refresh it.

Bots will always be able to beat humans with parallelized requests and faster information processing. That's a generic feature and independent of BTCT.

I agree, but I am wondering why someone creates a trading bot that blockes a fair price for others and trades towards a fixed price..... 

People create trading bots for the same reason that people trade manually: For fun and profits. Bots don't "block a fair price", because what is a fair price anyway? Whatever people are willing to buy or sell for is a fair price. If the algorithm in a bot thinks 22 is a good price, then it doesn't matter that you were only willing to pay 21.

The only issue I personally have with bots on BTCT is the (too) small price increment (or 'tick') in orders. I can outbid someone by 1 satoshi per share and have my order executed first despite making what is effectively the same offer. This is already annoying when people do it manually, but bots can automate the process. This is one of the reasons I'm currently writing my own bot ^^

[Lytse]

I agree, but I am wondering why someone creates a trading bot that blockes a fair price for others and trades towards a fixed price..... 

People create trading bots for the same reason that people trade manually: For fun and profits. Bots don't "block a fair price", because what is a fair price anyway? Whatever people are willing to buy or sell for is a fair price. If the algorithm in a bot thinks 22 is a good price, then it doesn't matter that you were only willing to pay 21.

The only issue I personally have with bots on BTCT is the (too) small price increment (or 'tick') in orders. I can outbid someone by 1 satoshi per share and have my order executed first despite making what is effectively the same offer. This is already annoying when people do it manually, but bots can automate the process. This is one of the reasons I'm currently writing my own bot ^^

Does it take a lot of time to write such a bot? I would guess learning the techniques and creating a strategy takes about week....

[dexX7]

Does it take a lot of time to write such a bot? I would guess learning the techniques and creating a strategy takes about week....

Depending on your background writing a bot is not necessary a time intensive task, but defining profitable rules is. If you're sloppy, it could just burn money.

Imagine the spread-bot mentioned above. It places a bid higher than the highest bid and an ask, lower than the lowest ask. Easy, isn't it? But what happens for example, if someone would place fake ask orders to move the bot so that bot's asks are "cheap", then buys the shares from the bot and then places fake bids, so the bot's bids are higher then his previous sold asks? I think you get the point..

Notes:

 - if an bot outbids me, I ignore it. It's ordersize is mostly insignificant and you lose a order-place-battle against the bot anyway.

 - if you spot an exploitable bot, punish his creator (never saw one like above though..)

 - if I place an order higher/lower and I notice a human outbids me, I try to play a fair game and place my order on his. If he moves again, he is stupid and I stop here. Orders are filled in such a way, that if he placed his order first and I place my order on the same price, his order will be filled first nonetheless.

[Rannasha]

I agree, but I am wondering why someone creates a trading bot that blockes a fair price for others and trades towards a fixed price.....  

People create trading bots for the same reason that people trade manually: For fun and profits. Bots don't "block a fair price", because what is a fair price anyway? Whatever people are willing to buy or sell for is a fair price. If the algorithm in a bot thinks 22 is a good price, then it doesn't matter that you were only willing to pay 21.

The only issue I personally have with bots on BTCT is the (too) small price increment (or 'tick') in orders. I can outbid someone by 1 satoshi per share and have my order executed first despite making what is effectively the same offer. This is already annoying when people do it manually, but bots can automate the process. This is one of the reasons I'm currently writing my own bot ^^

Does it take a lot of time to write such a bot? I would guess learning the techniques and creating a strategy takes about week....

Depends on your approach. With a week full-time, any decent programmer should be able to conjure up a decent bot (depending on the language used and required functionality you can do it in less time). Personally, I'm first focusing on making a complete library for all BTCT API calls, to make available for others to use. For just a bot you need a lot less functionality. Between that thoroughness and my need to divide time between my daughter, preparing my PhD thesis for printing and hobbies besides BTC-stuff, it is a very slow process

[AstroBoy]

Can a moderator for BTC-TC please review Activemining and get it listed?  It is waiting on one last vote for approval.

Thank you very much!

(fyi, I have no involvement in this company other than owning a couple shares on bitfunder)

[Lohoris]

Please keep scams on BitFunder.

+1

[TsuyokuNaritai]

Please keep scams on BitFunder.

+1

+2

[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.

[dexX7]

I will be rolling out a change tonight that will limit any bid or ask order to a maximum of 4 significant digits.

I'm curious how they'll adapt. The behavior won't change at all, but the number of steps will get smaller till they reach the limit of their range. I.e. only 100 steps for current bid: 0.8000, current ask: 0.8200, lowest acceptable ask: 0.8100 -> 0.8199, 0.8198 ... 0.8100.

Nevertheless:
I'd be happy, if you would announce major changes like this with a leadtime of 24+ hours and more visible in the future.

[pascal257]

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

Correct me if I'm wrong, but should the last 2 also be rounded?

Also, what about the stocks with very low prices like B.YAMBC, BTC-GOLD etc. 0.0003 or 0.0004 is a huge difference there. Maximum number of digits should be depending on stock price and not fixed.
Nevermind (fixed quote), so the 4 significant digits are counted after the first non-zero digit

I'd be happy, if you would announce major changes like this with a leadtime of 24+ hours and more visible in the future.

+1

BTW, does this also affect LTC-Global?

[burnside]

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

Correct me if I'm wrong, but should the last 2 also be rounded?

Also, what about the stocks with very low prices like B.YAMBC, BTC-GOLD etc. 0.0003 or 0.0004 is a huge difference there. Maximum number of digits should be depending on stock price and not fixed.
Nevermind (fixed quote), so the 4 significant digits are counted after the first non-zero digit

I'd be happy, if you would announce major changes like this with a leadtime of 24+ hours and more visible in the future.

+1

BTW, does this also affect LTC-Global?

It will affect LTC-Global too, yup.

You're both right, for this one I'll wait until tomorrow (monday) ~2000 UTC to make the change.

Cheers.

[parseval]

You're both right, for this one I'll wait until tomorrow (monday) ~2000 UTC to make the change.

Cheers.

If we want to limit botting, I think a few other measures could (but not necessarily) be put in place:

• Longer cache on order book API.  This will not affect regular users but will require additional work by bot owners to grab up-to-the-moment data for their bots.  However, this just pushes them off to webscraping the orderbook.  Making the orderbook require authentication helps to identify the bots, and rate limit pageviews (kind of how CloudFlare detects a ratelimit violation when they help protect against DoS).
  
• Rate limiting the OAuth API order creation (or any order creation without 2FA)
• Charging a very minor fee for order creation and cancellation...  minimal enough to not affect normal users, but significant enough to add cost to running a bot 24/7 with constant order updates.  Something like 0.00001 maybe.  Perhaps allow the first 20 order updates per day to be free, to not impact the average user at all.

Really, these are just inconveniences for the bot owners, but they require some work and/or expense to overcome.  More barriers lead to fewer bots, and provide a fun challenge to the people attempting to create a profitable bot.  It is, however, a cat and mouse game..   as people build smarter bots, combatting them becomes more complex.  At some point the cost/benefit isn't worthwhile, and this cuts into dev time spent on new features or bugfixes.