Post
Topic
Board Securities
Re: [BTC-TC] Virtual Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc.
by
parseval
on 22/07/2013, 11:54:17 UTC
  • 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.

Hell no! Please.. This kills would every chart application. Sad

I have no bot running, but I'm using external chart tools and I'm working on my own betting interface with success. And if you stop data fetching, people will use different methods. My solution would be to parse the IRC feed. And this would esentially suck as there are no trade ids included and I can only guess the mapping, when updating with "real data" ...

This shouldn't affect my charting application...  I've already got a bot up to parse the IRC feeds, in addition to pulling from the API.  I grab the latest trades from the API for ltc-global and btctc, and use the IRC bots for Bitfunder, Havelock, and MPEx.  This shouldn't really impact charting applications, unless you're hammering the orders API endpoint every 30 seconds to get an up to date orderbook for some kind of cumulative depth graph (I'm not sure what the cache rate is on this order book currently).

But like I said, these are just speculative ideas on how to counteract the bot influences.. I don't necessarily think they all need to be implemented, I'm just brainstorming.  You're right that a dedicated botter would find a way around these measures and get their data some other way.  It really all depends on whether bots are really seen as a detriment or not, and whether the cost of inconveniencing the bot operators is worth the effort.. there's a point of diminishing returns where there's only so much you can do.