Topic: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE - page 39. (Read 97702 times)

as outlined before it is a depth "problem", more customers is what you need

It probably means someone short was just about to get dinged for the daily variation margin at the prevailing price of around $10.50, when right before the clearing 250 BUZ2 positions were sold, bringing the "last" trade prior to clearing all the way down to $10.10.

So instead of that party with the short position seeing a negative variation margin, a positive one resulted instead.

Of course, this was interesting because shortly after the clearing, trading resumed at the $10.57 level.  This makes some nice profits for whomever bought just minutes earlier below $10.50.

This occurs pretty regularly right before clearing time.  I keep forgetting to put in some lowball bids right before clearing so I can get me some of these BUZ2's at that daily discount.

What does that mean?

wow, another deduction turned into a profit within a single second. thanks for that, whoever you are!

Expanding the protection of two-factor authentication so that each withdrawal request requires a new OTP to be entered would help improve security for ICBIT.

Without that, there still is the risk that using ICBIT from a compromised system can result in unauthorized withdrawal:

A plea to exchanges ... lets do 2 factor right!
 - https://bitcointalksearch.org/topic/a-plea-to-exchanges-lets-do-2-factor-right-109424

Those fundamentals rules are established and implemented by major exchanges throughout the world, so introducing e.g. random clearing time would be a hack. What we need is a proper solution.

Proper solution is a liquid market, with many market making bots competing with each other. This way, it would not be possible to move market too much without simply losing money.

But, still, until the market becomes liquid (I'm working on that too, and will be providing reference market maker bot code for everyone to use for free), some of your suggestion makes sense: e.g. they influenced my previous two proposals.

If anyone else have any other ideas, let's discuss.

will be interesting to watch what happens this evening shortly before 21:00 on the oil futures
Right now the rate is below 8.30
And the whole ask side has been bought away again... 

Probably we'll need indeed a mix of measures, and what you propose sounds like a good approach. When the trading boundaries are tied more closely to the situation on the underlying market, this protects the opened positions against manipulations without actual market activity.


But we should also consider how the "current rate" is established in ICBIT.
It is an important fact of the platform's construction, that this "current rate" does have a very tangible monetary effect once a day, at a time known to everyone in advance. Since the platform provides leverage, a comparatively small move of that "current rate" at the right time can yield either a huge pile of additional trading power, or in the other case, can disable a market contributor completely. Since when your available margin goes negative, you can't contribute actively in the market anymore. You're forced then either to close some position with loss, or to inject additional liquidity, or just to sit there and watch the market pass by. This bears the danger of producing an self-reinforcing avalanche effect of distortion.

While I am in no way criticising the basic behaviour (I think it is adequate and a defining feature of this platform), this creates an especially strong incentive for trying to game the engine. And this is what we see here.

Some thoughts:

• can you please revisit the way the "current rate" is calculated when there is no offer at all at one side? Several days in row we had now the situation that someone has bought away the whole ask side. I get the impression that in this case the engine picks the average of the highest bid and the upper bound of the trading range to establish the "current rate". This yields a value way too high.
• also it seems that this "current rate" is sensitive to the order of execution, especially it sticks to the last deal done. If someone buys away all (or a large number) of offers, the "current rate" thus sticks to the last transaction, which is always the transaction most off-centre. This does in no way conceptually reflect the "current rate", which should be close to the centre of activity. Especially when someone buys away the bids/asks set by some market making bot, this can cause a gross distortion
• would it be helpful not to base the mark-to-market on the "current rate"? Why not doing a mark-to-market, using the weighted average of the last trading session?
• another proposal: why not picking a random unpredictable time point for this mark-to-market operation? That would mean just to use trading sessions with a variable, randomly picked duration.

I think there are good manipulations and objectionable manipulations. I tend to see a manipulation as acceptable, when it is combined with actual market movement (even just in the futures market) and when it is bears a substantial risk. On the other hand, a manipulation just exploiting some technicalities of the engine without real market activity is objectionable and should be prevented by technical means.

Yes, this is a major problem when the volume is very tiny.

I foresee two solutions, one may add to each other:
1. The boundaries will be set using weighted average USD/BTC rate multiplied by respective boundaries for that futures contract at CME exchange. This should provide a fair trading range for all.
2. Increasing liquidity by providing market making. This should actually help because more liquidity would make it more harder to steer the market away from real prices.

Thanks a lot for reporting this issue.

Absolutely. And it really should be a weighted average. And I think, the bids and asks should only be used when there was no trade all day long.
What IMHO is broken right now is that you're able to cause a tangible effect on people's balances without the need of any significant input and thus with only moderate risk. The moment the manipulator(s) are forced to do a significant amount of actual trading to cause any effect, I'd consider that issue as "fixed", as far as the platform is concerned.


My guess is rather these are different market contributors. The manipulator(s) don't care much most of the day. The buying-away of ask orders and the short-time placing of high bid orders seem to happen just right before the cut-off

The problem with the BTC/Oil and BTC/Gold markets are tiny volumes, that makes them easier to manipulate.  I guess there is some manipulation on the BTC/USD market too, and there Ichthyo's solution would undoubtedly work.  But on the other markets, if there are just a few trades every day it will be susceptible to manipulation.

I wonder if these products have a future.  There is a clear market for the BTC/USD futures, both for speculation and for hedging.  But speculating simultaneously on Oil and BTC prices may be a bit too much, and who needs to hedge the oil price in BTC??

It would seem that you're onto the right nature of a solution. I'm not sure that changing the range calculation alone achieves the desired result. Perhaps the clearing price should be set with the (volume) weighted avg, and combine that with a weight for proximity to clearing time (really, either before or after, as I see there's a converse behavior of pushing the clearing price in one direction before clearing, and immediately pushing the price in the opposite direction right after clearing).

If the trades right at that time moved the clearing price less than the trades mid-session, there'd be considerably less incentive to try to game it.

We've continuously ongoing problems with manipulation shortly before the cut-off at 20:00


What do you think of the following proposal?

Instead of using the "current range", which is sensitive to the order of execution and especially sensitive to what happened in the last seconds --
why not using a weighted average of the last day's actual trades? Only if there was zero trading activity, then the weighted average of the orders should be used. So, in any case, the next day's trading range would be centred at the last trading session's centre of activity.

• just placing some orders wouldn't have any effect anymore
• the incentive of last-minute trades would be reduced. At least a manipulator needs to move huge positions
• In case of a crash of the underlying market, the damping effect would be stronger. But since everyone would move to the border of the current trading range, the necessary (but damped) adjustment would still be possible.

Does this proposal make sense, do you see any further problems? Do you think this would ameliorate the issues?

Today I've observed what's going on.
So my theory what happened is as follows...

• the market isn't especially deep, but looks sort-of balanced
• Fireball (or someone else) is running a market making bot
• this bot had placed an order at the outer borders of the allowed range
• just few minutes before the adjustment cut-off at 20:00 UTC, a manipulator buys away the complete ask side
• since the last offer bought away is the one placed by the market making bot, the system picks the exact upper end of the range as "current rate" and centers the new range at that point
• thus the new range ends up largely outside of any existing offers during that day. Everyone holding positions receives a really huge mark-to-market adjustment

I think this mechanism is very destructive and absolutely not how it's intended to work.
If a manipulator succeds with such a scheme several days in row, he can basically create his own leveraged yield and squeeze all holders of counter positions out, and all of this with relatively low input and moderate risk.

Are the oil futures working as expected?

Yesterday everything was ok-ish, but now the situation there looks queer: the complete Ask side is gone and the displayed rate is at the upper bound of the range allowed for today, which is 8.6872 - 10.6176 -- any existing bids are completely out of this range. How is this "current rate" calculated? The Chart don't give me any clues here.

Does this mean that there actually was a deal done at 10.61 or is this just a fallback picked by the system?
A deal at above 10 looks strange, because this necessarily means that someone acually went long at that rate, which is completely off road. Current market rate should be at 85.80 / 11.05 = 7,76  -- well, futures markets can be in contango (or would this count as backwardation in this case, since we're actually more speculating on bictoin rate movements than on oil rate movements?).

Anyway, the current situation concerns me somewhat, since when there is no ask side, theoretically a single player could just skew the rate up until everyone else is driven into liquidation... 

Thanks a lot!  This helps tremendously during normal trading.
Of course if someone wants to sabotage the overview, they can still do it.  But I suspect that in most cases it will help a lot.

We sent a message to tcatm a couple of days ago, awaiting for his opinion. That would be nice, of course (bitcoincharts also can display market depth on it's own).

this is already a valuable improvement, very much apreciated!


...looking ahead to the maket depth graph.
Incidentally, wouldn't it be possible to publish the futures data through bitcoinchars? Or is that limited to classical BTC/currency exchanges?

Allright, I just added a way to change orderbook window size (it's same way how you change size of "your orders" window at the bottom, by clicking a small blue arrow pointing downwards). Instead of 5 entries in every direction you could see 11 now.

It's not a totally proper solution because it's possible to fill up those 11 entries (or any more) too, if one wants to.
The depth of market chart would provide a much better overview, when it's done.

For those who run their trading bots: order book message json object format will change today (to make it arbitrary sized into both sides and to simplify parsing on the client side), so don't forget to look at the new json object and adapt your code.