Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 93. (Read 316652 times)

What about this one:
https://forum.litecoin.net/index.php/topic,551.msg29947.html#msg29947

I just don't like bots, not saying it's 100% rational 

Yes - that's about the only sane way of doing it.  I'm not convinced it's a real problem myself - but I'd actually benefit from it so certainly don't object (only bots and people in low-income countries can afford to sit there constantly updating orders).

I disagree with some of this.  It DOES add liquidity because, even if we consider his bid to be the same as yours, by placing his bid he's increased liquidity at that price-point.  Problem with arbitrary limits is they add more serious problems - not the least of which is that valid orders can get rejected if someone else makes the same valid order at the same time.

Increasing minimum increment will either make a difference or it won't.

If it's too small to make a difference (i.e. they have to bid .03351 instead of .033501) then it's pointless.
But at the other extreme where it makes too big a difference (e.g. they have to bid .0345) then it distorts the market - as you can place a bid which allows profitable arbitrage and at the same time blocks others narrowing the margin.

On an aside it's a total waste of time anyway as it wouldn't stop anything.  I'd better explain why - as it isn't entirely obvious.

Any restriction on Bid increments could only be applied to the TOP bid - not to bids elsewhere in the book.

So you have you bid at .0335 and I want to bid .033501 but can't - as I have to bid more.

Fine my bot bids for 1 unit at .034, places my real order at .033501 (now legal as .0335 isn't top bid) then cancels my .034 order.  The system can't start cancelling existing bids if they would break the rules if new - or I could UNDERbid you by .000001 and force YOUR order to be cancelled.

Reducing the precision allowed on bids is what burnside tried - but that has its own problems.  Not the least of which is that if BTC rises anything with an underlieing USD element is going to need those extra digits.  Every time difficulty rises by a factor of 10 all mining bonds SHOULD have their value shifted 1 place to the right, needing 1 more digit.

The best hope for it to stop is actually for MORE bots to join - and let them keep outbidding one another until the spread closes to nothing.  Then just give them a nudge in the right direction with a temporary bid and let them trade with one another at a spread below the exchange's fees.

Also it's worth looking at what they respond to.  Some only respond to overbids worth more than X - and can be fooled into not adjusting price just by staggering your own bids in chunks just under X.  Also once you know X and know the size of their bid you can work out the potential cost of trying to force them into a bid you'd willingly fill.  All of which reminds me I really need to get my own GLBSE bot converted - though with BTC-TC's caching it won't be practical to strip cash from bots as efficiently as you could on GLBSE (a bot to raid other bots would need to read market data from uncached web-pages rather than cached API).

Yeah, the scaling decimal limits per security would solve this.  For instance, imagine the following table:

highest bid	decimals allowed
>1000	0
>100	1
>10	2
>1	3
>0.1	4
>0.01	5
>0.001	6
>0.0001	7
all else	8

We'd clearly display in the interface the max decimals allowed on each individual security page.

I agree, though of course until this is fixed, I'll take advantage of that...

However I'm strongly against banning bots: it makes no sense to do that, it wouldn't help at all (as burnside already explained).

I don't have problems with people (or bots) outbidding me, my point was more that they really aren't outbidding me at all. The bid increments are so tiny that they're far below any reasonable margin that you would consider in your price/profit calculations.

As an example, I place a bid order for 0.0335 BTC per share, which is the top bid by a non-trival margin (say the best before was 0.033 or so). I then get outbid by a bid of 0.033501, which is 0.003% above my bid. For all intents and purposes, it is the same bid. With volumes being in the dozens at most typically, the extra cost incurred by the person placing the second bid are negligible (one-hundreth of a dollar-cent per share), yet it does ensure that the other bidder gains priority when the bid is filled. This scenario has happened several times today while trading DMS.SELLING, at slightly different values, but the order of magnitude is correct.

This kind of bidding behavior doesn't help with price discovery, it doesn't narrow the bid-ask spread and it doesn't provide the market with more liquidity. It's, in my eyes, exploiting a feature of the trading platform to get your order fulfilled before others with the same order and such an advantage is big in markets where trades happen infrequently.

On the other hand, making a bot does sound like fun. I might just dive into that in the future. If you can't beat em, join em

You CAN fill your own orders if you don't mind paying the 0.4%.  (0.2% on the buy and the sell)  So if you do the appropriate math to make sure it's still profitable, it should be fairly easy to manipulate the bots.

From a purely technical perspective, it would be impossible to ban the bots.  A crafty programmer can get around any sort of detection I could do.


There is already minimum granularity, or you'd be seeing 8 decimal places in the orders.    The problem is that the granularity doesn't scale.  I'd love to be able to setup per-issue scaling granularity eventually so that an issue like ASICMINER-PT that is ~2.8 BTC would have less allowable decimal places than say S.DICE-PT.  We'd display on the order interface the maximum decimals so everyone could see it.  It's low on the priority list though.  The backend decoupling of bitcoind and other minor bugs are sucking up all my dev time.

Cheers.

It's a spread bot. I noticed it, too. Maybe it's exploitable.

Say it's bid: 2.50, ask: 2.75. He will place his bets on 2.50001 (and 2.74999). When you place your order, the bot adjusts, so let's say you place a bid at 2.60, the bot will adjust and place his bid at 2.600001. Maybe one could move him that way on purpose. Increase your bet, wait till he adjusts, replace your bid etc. and if your finished, you sell without spread.

I try to just ignore it though, as he will adjust anyway.

Edit: I see, Deprived had the same idea.

A lot of the time it's bots doing that.  There are a few bots that are just trading the spread with small volumes.

Annoying though it can be, I disagree with you.  If you want top bid or lowest ask then put a price that they won't outbid/undercut.  Alternatively you can force them to a price where you're happy to fill their order then move your own order.  Once you figure out their ranges it isn't hard to outmanouver them - for example on Bid side the most active bot won't outbid anything that's within 20% of the lowest Ask - so you can either bid at 19.9% below lowest ask or put a 1 unit ask yourself to reduce that range.  On very illiquid securities with large spreads you can even force the bots into selling to you then buying back at a higher price - and repeat until the owner notices.

Reason I disagree is simply that the process of outbidding - even at tiny increments - is a discovery process.  It's working out who won't go higher (or lower).  If you have a problem because of it, it means you aren't bidding/asking near the edge of your range.  If that's the case for both of you then reducing the minimum won't stop it happening - it'll just reduce the number of iterations before you get to the edge (the point where one of you won't change their order any more).  Either of you can already speed up that process - by using larger increments themselves.

0.1% may sound tiny - but that's half the trading fee.  i.e. it's half the cost that needs to be covered to make an arbitrage opportunity break-even or profitable.  If you were to raise the limit to 1% then you'd end up in a situation where someone could bid 1.1% below the arb point and, despite there being a 0.9% profitable range left noone else could outbid them without risking loss.

Because of that, if limits were to be imposed they'd need to be based on a percentage of SPREAD not PRICE.  So where the spread was small minimum overbids would be fine - where spread was large a more significant increment would be demanded.  But that makes it hard to understand.  And any such limit is a real pain on any active security - as if two or more people are trying to adjust prices at the same time, some of them may have orders rejected even though they met the criteria based on the information they had when they were entering their order.

In short I'd say No.  If another trader's actions are annoying then either:

1.  Live with it - the market IS (in part) for making profit from other traders.  On most trades someone is losing money (IPO sales aside) - a bit of butt-hurt is irrelevant compared to that.
2.  Do the same thing but better.
3.  Exploit it.
4.  Prevent it by being more aggressive in your own orders - force them to make hard decisions rather than just letting them keep outbidding in tiny increments.

Agreed!

Ban bots and part of the problem is solved.
PS! Bots do NOT help liquidity!

One thing I would like to see on BTCT is some sort of minimum granularity of prices. Right now, what happens all the time is that someone undercuts (or overbids) your ask or bid order by something silly like 0.01% or even less. So while you have functionally equivalent orders, the other one gets executed first since it's better by a negligible margin. Which means that with volumes being relatively low, you have to constantly babysit your order to ensure that it's at the right spot in the order book if there's one of those jokers going around constantly outbidding you by 1 uBTC.

In the low volume trades that occur on BTCT, these tiny fractions of a % have no meaning, but they serve to frustrate those trying to keep a competitive bid/ask in the books. A minimum granularity of in the price would help a great deal in overcoming this issue as it would force users that want to have the top order in the book to actually beat the current best price by a non-trivial (though still small) amount.

My withdrawal does not have a fee, so it takes time again to add it to the block.

Definitely nothing intentional.  It should take it into account now.

Cheers.

Maybe php recognizes DST?  That site you linked has a note on it:

If it's wildly off, let me know, I'll spend more time on it.

Cheers.

That one is pretty heavily cached, it only refreshes every 10 minutes or so.  So a 10 minute interval is probably ideal.

Cheers.

Server having problems? Can't get it to load.

Edit:

It's working now.

I have it on ten minutes for my chart site, and haven't had any complaints.  Though, now I am working on reading from the bot in #bitcoin-assets as a realtime data source for something quicker that won't bombard the site.  http://www.coinflow.co