ICBIT Derivatives Market (USD/BTC futures trading) - LIVE

[zero3112]

How come BUH3 the future for BTC trades at a rate much higher then the spot price of Bitcoin its self?

[1714322049]

1714322049

[Stephen Gornick]

How come BUH3 the future for BTC trades at a rate much higher then the spot price of Bitcoin its self?

The academic explanation:

Well, this situation is well known in "bigger" future markets too - contango or backwardation situation. And it's quite normal for a futures to be in either contango or backwardation most of the time.

 - http://www.investopedia.com/articles/07/contango_backwardation.asp

Another thread where this is discussed:

Why are bitcoins in december better than bitcoins today? (ICBIT)
 - http://bitcointalk.org/index.php?topic=110583.0

And Fireball posted how to take advantage of these situations:

Spot/Futures Arbitrage (with some bots source code)
 - http://bitcointalk.org/index.php?topic=131622.0

The situation likely exists due to ICBIT being one of the few methods where leverage exists.  One of the few other methods of obtaining leverage is to buy a call option at MPEx. for instance, however Bitcoin's volatility is so high that premiums for that are high as well.  There are other differences as well.  With options, you can hold those until expiration even if the exchange rate makes a huge move against you.  With a futures contract purchased using leverage, an investor could see forced margin selling as a result of an unfavorable move to the exchange rate.

[Fireball]

The closing price for BUH3 was exactly the same (to three places) two days in a row!

Today (Jan 12, 2012) was the second day in a row with no print for variation margin on BUH3 (meaning the same clearing price three days in a row), and now today had no print for variation margin on CLG3 either.

I then made a trade after the Jan 12 clearing time where I sold BUH3.  It printed a variation margin with last= my selling price.  But in doing the math to verify, it doesn't jive if the last clearing price on BUH3 was still  "last = 15.5750", and instead the Jan 12th clearing would have needed to have been an amount higher than that.

Fireball, whassup with that?

If clearing price turns out to be the same as the last day's, then variation margin is not transferred, and obviously there is no corresponding entry in the log. There is absolutely nothing wrong with the math.

[picobit]

How come BUH3 the future for BTC trades at a rate much higher then the spot price of Bitcoin its self?

The academic explanation:

Well, this situation is well known in "bigger" future markets too - contango or backwardation situation. And it's quite normal for a futures to be in either contango or backwardation most of the time.

A continued contango situation is normal, if there is a price of storage associated with whatever is being sold.  That is clearly not the case for bitcoin.

In this case, I think it is a situation where the markets are small, and the traders on ICBIT are more optimistic than the average (and have difficulties getting funding).  Kind of makes sense, if you truely believe that bitcoins are going up, then buying leveraged futures makes sense.  Of course, if you have enough money it makes even more sense buying bitcoins directly on the spot market, since a price movement up towards 15.5 will give you a gain in that situation, but no gain on ICBIT.

[Stephen Gornick]

There is absolutely nothing wrong with the math.

My apologies, you are correct.

I recomputed and the variation margin does indeed show correct.

Using the 15.879 selling price as the PriceClose, and the 15.575 (from the last variation margin print occurring a couple days earlier) as the PriceOpen and plunking those into the formula from:
 - https://icbit.se/BUH3

gives:
VM = (-(1 / 15.879 - 1 / 15.575) * 10) = 0.01229199 BTC per contract (amounts below one satoshi gets truncated).

It still would be nice for there to be shown the history of daily clearing prices.  (And also the ability to access the charts and order book without first authenticating, incidentally.)

[Fireball]

It still would be nice for there to be shown the history of daily clearing prices.  (And also the ability to access the charts and order book without first authenticating, incidentally.)

Indeed I heard many similar requests, however I want to make some tradeoff by making the frontpage way more informative and "live" than the currently existing one, however imposing some limitations (slower update rate, for example) not to overload the server with many unauthenticated and thus uncontrolled connections.

This is already in progress, so should be deployed relatively soon.

[picobit]

@Fireball:

Hi, is there a problem withdrawing BTC from your site right now (a background script not running, or something)?  I tried withdrawing a small amount 10 min ago, but nothing happened.  I got the green message that it would be processed soon, but to no avail.


PS: The login process seems to have been smoothened a bit.  Nice!

----
EDIT: Withdrawing 0.5 BTC later went through, so I assumed that I had done something wrong, and tried to withdraw the 9 BTC again.  No success.  Perhaps 9 BTC is above some limit and needs manual approval - I am entirely in favour of cold wallets, so that is OK with me, but it would be nice to get some feedback, e.g. a "pending" line in the log.

Now I probably have two withdrawal requests in queue - I assume that the second one will be stopped as it would bring be below the "initial margin".

[Fireball]

PS: The login process seems to have been smoothened a bit.  Nice!

Thanks! Still working on a similar update, which will make the experience even more smooth

----
EDIT: Withdrawing 0.5 BTC later went through, so I assumed that I had done something wrong, and tried to withdraw the 9 BTC again.  No success.  Perhaps 9 BTC is above some limit and needs manual approval - I am entirely in favour of cold wallets, so that is OK with me, but it would be nice to get some feedback, e.g. a "pending" line in the log.

Now I probably have two withdrawal requests in queue - I assume that the second one will be stopped as it would bring be below the "initial margin".

Yes, there was a delay, sorry about that - one more user was affected too. Now it's all good, and there are no unprocessed transactions in the system.

P.S. That happened because the hot wallet was set to contain too small amount of bitcoins. Security is a priority...

[picobit]

P.S. That happened because the hot wallet was set to contain too small amount of bitcoins. Security is a priority...

A hot wallet that does not run empty on a busy day is too large

[PAPASO]

hi



I cannot see any price in Orderbook (BUH3) today,can you tell me why?






papaso

[starik69]

Confirm this.
In chrome no prices, positions, orders.
In IE it says something about bad certificate and after ignoring it all appears.

[molecular]

Confirm this.
In chrome no prices, positions, orders.
In IE it says something about bad certificate and after ignoring it all appears.

Same here, no data at all, no orders, no balances, nothing. Only thing filled is the price chart. Last data point from Jan 20th 5:00

EDIT: in both chromium and firefox.

[Fireball]

Confirm this.
In chrome no prices, positions, orders.
In IE it says something about bad certificate and after ignoring it all appears.

Same here, no data at all, no orders, no balances, nothing. Only thing filled is the price chart. Last data point from Jan 20th 5:00

EDIT: in both chromium and firefox.

Going to be fixed in a bit!

[Fireball]

Done, works as expected now.

[molecular]

Done, works as expected now.

That was quick! Confirmed and thanks.

[picobit]

@Fireball:

You seem to be experiencing some clock skew on your server.  It is now only possible to withdraw money using Google Authenticator during the first half of the minutes.  In the second half, the one-time-password is judged to be invalid.

PS. Profitable to be long these days.    (But who knows what tomorrow brings)

[Fireball]

@Fireball:

You seem to be experiencing some clock skew on your server.  It is now only possible to withdraw money using Google Authenticator during the first half of the minutes.  In the second half, the one-time-password is judged to be invalid.

PS. Profitable to be long these days.    (But who knows what tomorrow brings)

I checked server's clock, there was a skew indeed, but it was only a 3-4 seconds difference (I set up NTP syncing to happen more often now).
You can watch the server's clock "live" in the header of the web trading room, to make sure it's allright.

[Ichthyo]

It would be a desirable improvement to produce more explicit feedback when actions are rejected.

On several instances, ICBIT rejects actions, but leaves to the user to guess the reason.

• sometimes, orders in one direction are rejected when they cross your own orders in the opposite direction. While this is a good feature to prevent erroneously priced orders, it is a real annoyance regarding market orders (since they seemingly are entered as limit orders with the maximum/minimum allowed price for that trading session). At least, ICBIT should give a verbal indication what is wrong, instead of just writing "Rejected". Moreover, this notice should be visible immediately -- currently it is often necessary to reload the page.
• Sometimes, additional offers are rejected when you have already an order in the same direction close by. Maybe there is a heuristics to prevent a single account to produce more than x % of the current Bid / Ask side? Anyway, ICBIT should at least indicate what is wrong, and do so immediately.
• When processing withdrawals, there seems to be an additional risk calculation. The required margin seems to be calculated different than what is displayed as available margin; my guess is that pending losses and maybe even the possibility of executing an offer is included somehow different then in the displayed margin. Anyway, again, ICBIT should
  • immediately indicate why the withdrawal would be rejected, and what amount can effectively be withdrawn.
  • immediately create an permanent entry in the withdrawal history -- maybe even just with "pending", or "requires manual approval"
  Right now, all that happens is a script generated text in the current page "your request has been queued". I have witnessed numerous times, that even hours after such a request, nothing appeared on blockchain, nor was there any visible notice indicating why the withdrawal was not performed. The latter is especially annoying, since sometimes you just want to use excess funds elsewhere temporarily, and you need to get them out within some predictable time.

While these improvements are certainly not necessary for the basic trading functionality, they would render the platform more responsive and tangible for the user.

[Fireball]

It would be a desirable improvement to produce more explicit feedback when actions are rejected.

On several instances, ICBIT rejects actions, but leaves to the user to guess the reason.

• sometimes, orders in one direction are rejected when they cross your own orders in the opposite direction. While this is a good feature to prevent erroneously priced orders, it is a real annoyance regarding market orders (since they seemingly are entered as limit orders with the maximum/minimum allowed price for that trading session). At least, ICBIT should give a verbal indication what is wrong, instead of just writing "Rejected". Moreover, this notice should be visible immediately -- currently it is often necessary to reload the page.
• Sometimes, additional offers are rejected when you have already an order in the same direction close by. Maybe there is a heuristics to prevent a single account to produce more than x % of the current Bid / Ask side? Anyway, ICBIT should at least indicate what is wrong, and do so immediately.
• When processing withdrawals, there seems to be an additional risk calculation. The required margin seems to be calculated different than what is displayed as available margin; my guess is that pending losses and maybe even the possibility of executing an offer is included somehow different then in the displayed margin. Anyway, again, ICBIT should
  • immediately indicate why the withdrawal would be rejected, and what amount can effectively be withdrawn.
  • immediately create an permanent entry in the withdrawal history -- maybe even just with "pending", or "requires manual approval"
  Right now, all that happens is a script generated text in the current page "your request has been queued". I have witnessed numerous times, that even hours after such a request, nothing appeared on blockchain, nor was there any visible notice indicating why the withdrawal was not performed. The latter is especially annoying, since sometimes you just want to use excess funds elsewhere temporarily, and you need to get them out within some predictable time.

While these improvements are certainly not necessary for the basic trading functionality, they would render the platform more responsive and tangible for the user.

This is already in-progress, as a very demanded feature. That is, the orders rejection description.

However, as for withdrawals, it's somehow different, and your last two statements are already there for a long time.
The first step of withdrawal validation happens after hitting the withdraw button and it just checks whether you entered correct data, and outputs friendly error message (e.g. "invalid bitcoin address", "invalid amount specified").
If it passes these checks, then it's added to the transactions queue ("Your payout request has been queued. Once it's processed, transaction amount will be deducted from your account.").
From this moment, you can see it in the Transaction table, at the bottom of the Funds table. To the right of it will be its status. Nothing for pending/unprocessed transactions, link to the corresponding transaction for a successfull payout, or rejection if there were not enough money.

Mainly, I find that the empty "Status" is confusing. I will make it default to Pending then.

Thanks for your suggestions!

[Ichthyo]

It would be a desirable improvement to produce more explicit feedback when actions are rejected.
On several instances, ICBIT rejects actions, but leaves to the user to guess the reason.
...
Right now, all that happens is a script generated text in the current page "your request has been queued". I have witnessed numerous times, that even hours after such a request, nothing appeared on blockchain, nor was there any visible notice indicating why the withdrawal was not performed. The latter is especially annoying, since sometimes you just want to use excess funds elsewhere temporarily, and you need to get them out within some predictable time.[/li][/list]

The first step of withdrawal validation happens after hitting the withdraw button and it just checks whether you entered correct data, and outputs friendly error message (e.g. "invalid bitcoin address", "invalid amount specified").
If it passes these checks, then it's added to the transactions queue ("Your payout request has been queued. Once it's processed, transaction amount will be deducted from your account.").
From this moment, you can see it in the Transaction table, at the bottom of the Funds table. To the right of it will be its status. Nothing for pending/unprocessed transactions, link to the corresponding transaction for a successfull payout, or rejection if there were not enough money.

so there might be a bug hidden somewhere.
Just to confirm, I've tried to initiate a withdrawal of 20 BTC.
There is indeed the message indicating that the request was generated and queued. But nothing else. No new entry in the transactions list, and no BTC transaction, even now, after about 1 hour. When I reload the "funds" tab, of course then the green message is gone, but still no entry in the Transactions list.

Actually I've never seen a new entry in the transactions list before also the real BTC transaction was propagated to the network. So maybe there is some problem just with some browsers, or just some acconts. I am using Firefox 17.0.1 on Ubuntu.