hi
I cannot see any price in Orderbook (BUH3) today,can you tell me why?
papaso
Topic: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE - page 28. (Read 97654 times)
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
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".
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...
@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".
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".
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.
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.)
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.
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.
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)
- https://bitcointalksearch.org/topic/why-are-bitcoins-in-december-better-than-bitcoins-today-icbit-110583
And Fireball posted how to take advantage of these situations:
Spot/Futures Arbitrage (with some bots source code)
- https://bitcointalksearch.org/topic/spotfutures-arbitrage-with-some-bots-source-code-131622
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.
How come BUH3 the future for BTC trades at a rate much higher then the spot price of Bitcoin its self?
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.
Fireball, whassup with that?
There was no entry in my log for Variation margin for BUH3 today (Jan 11, 2012).
I see the previous day's entry showed "last = 15.5750" and the current level is at about the same level so it is likely the clearing price today was the exact same as yesterday and thus, I'm presuming, that there was no need to add a log entry as there was no adjustment.
But there's no historic log of daily clearing prices that will show me today's clearing price to confirm that this is what happened.
Might it be better to simply add an entry in the log for Variation margin each day regardless of whether or not the amount was above zero? At least then nobody would be left wondering if clearing didn't happen on those days like today.
I see the previous day's entry showed "last = 15.5750" and the current level is at about the same level so it is likely the clearing price today was the exact same as yesterday and thus, I'm presuming, that there was no need to add a log entry as there was no adjustment.
But there's no historic log of daily clearing prices that will show me today's clearing price to confirm that this is what happened.
Might it be better to simply add an entry in the log for Variation margin each day regardless of whether or not the amount was above zero? At least then nobody would be left wondering if clearing didn't happen on those days like today.
I noticed this too. I guess the software leaves out log lines if the variation margin is zero, instead of leaving them out if the quantity is zero (we certainly don't want 0 variation margin reported on all the instruments we don't have
)The closing price for BUH3 was exactly the same (to three places) two days in a row!
There was no entry in my log for Variation margin for BUH3 today (Jan 11, 2012).
I see the previous day's entry showed "last = 15.5750" and the current level is at about the same level so it is likely the clearing price today was the exact same as yesterday and thus, I'm presuming, that there was no need to add a log entry as there was no adjustment.
But there's no historic log of daily clearing prices that will show me today's clearing price to confirm that this is what happened.
Might it be better to simply add an entry in the log for Variation margin each day regardless of whether or not the amount was above zero? At least then nobody would be left wondering if clearing didn't happen on those days like today.
I see the previous day's entry showed "last = 15.5750" and the current level is at about the same level so it is likely the clearing price today was the exact same as yesterday and thus, I'm presuming, that there was no need to add a log entry as there was no adjustment.
But there's no historic log of daily clearing prices that will show me today's clearing price to confirm that this is what happened.
Might it be better to simply add an entry in the log for Variation margin each day regardless of whether or not the amount was above zero? At least then nobody would be left wondering if clearing didn't happen on those days like today.
Thanks for your clear answers!
I have a question regarding the GDG3 futures. It says that settlement is based on the COMEX future for the month of settlement, that sounds both reasonable and well-defined. But a bitcoin price must be involved in converting this price to bitcoins. It is not stated anywhere, but I assume that it is the MtGox price on the day of settlement like for BUH3 (or rather, the price at "the exchange with the largest trading volume" just in case MtGox folds). It that a correct assumption? This would be the reasonable choice, but of course it could in theory also be the ICBIT exchange price, which would give a huge risk of manipulation due to the low volume.
Yes, saying it simple, it's same definition as the one used for BUZ2 / BUH3. MtGox's volume weighted average price at the moment of futures settlement.And a second question. I have the impression that you are using a market maker bot. Does that mean that there is a risk of ending up with a contract with noone at the other end, or will ICBIT be the counterpart in that case, or is the bot keeping things balanced?
I run the bot occasionally, and also other people seem to occasionally run bots too. I will make it more convinient to run bots pretty soon, because right now it's a bit technically uncomfortable (though possible).As for your question, no, there can't be "noone at the other end". If I run the market maker bot, I do run it on my own different account, with my own money.
Finally, if I get a margin call while having multiple kinds of futures, is there any algorithm that decides which ones are forcibly closed?
Those which give the negative variation margin by the current market state, or which produced biggest lost during latest market movement (which is actually the same, with the exception when it went through clearing).
I have a question regarding the GDG3 futures. It says that settlement is based on the COMEX future for the month of settlement, that sounds both reasonable and well-defined. But a bitcoin price must be involved in converting this price to bitcoins. It is not stated anywhere, but I assume that it is the MtGox price on the day of settlement like for BUH3 (or rather, the price at "the exchange with the largest trading volume" just in case MtGox folds). It that a correct assumption? This would be the reasonable choice, but of course it could in theory also be the ICBIT exchange price, which would give a huge risk of manipulation due to the low volume.
And a second question. I have the impression that you are using a market maker bot. Does that mean that there is a risk of ending up with a contract with noone at the other end, or will ICBIT be the counterpart in that case, or is the bot keeping things balanced?
Finally, if I get a margin call while having multiple kinds of futures, is there any algorithm that decides which ones are forcibly closed?
And a second question. I have the impression that you are using a market maker bot. Does that mean that there is a risk of ending up with a contract with noone at the other end, or will ICBIT be the counterpart in that case, or is the bot keeping things balanced?
Finally, if I get a margin call while having multiple kinds of futures, is there any algorithm that decides which ones are forcibly closed?
Hi Fireball,
There is still something wrong with the documentation of BTCUSD variation margin ( https://icbit.se/BUH3 ). On your web page, W/R is still -0.1 where it should be -10 USD in order to give the correct result. Should the equation read R/W instead (due to the prices being reciprocal)?. By the way, why confuse the issue by introducing the minimal price step and its cost, when it is clearly the contract size that enters into the calculation?
There is still something wrong with the documentation of BTCUSD variation margin ( https://icbit.se/BUH3 ). On your web page, W/R is still -0.1 where it should be -10 USD in order to give the correct result. Should the equation read R/W instead (due to the prices being reciprocal)?. By the way, why confuse the issue by introducing the minimal price step and its cost, when it is clearly the contract size that enters into the calculation?
Allright, I simplified the formula on the website to just specify contract size S equal to 10 USD. Price step and cost are more generic values used for accounting futures contracts, however in this specific case, for simplicity, we can just stick with the contract size S. Thank for you noticing it.
And bytheway, soon good updates are coming!
Hi Fireball,
There is still something wrong with the documentation of BTCUSD variation margin ( https://icbit.se/BUH3 ). On your web page, W/R is still -0.1 where it should be -10 USD in order to give the correct result. Should the equation read R/W instead (due to the prices being reciprocal)?. By the way, why confuse the issue by introducing the minimal price step and its cost, when it is clearly the contract size that enters into the calculation?
There is still something wrong with the documentation of BTCUSD variation margin ( https://icbit.se/BUH3 ). On your web page, W/R is still -0.1 where it should be -10 USD in order to give the correct result. Should the equation read R/W instead (due to the prices being reciprocal)?. By the way, why confuse the issue by introducing the minimal price step and its cost, when it is clearly the contract size that enters into the calculation?
Hi Fireball,
There seems to be something wrong with the equations giving the variation margin on your web page. The actual calculation is OK, it is just the web page that gives the wrong expression.
The variation margin should be the price difference times the size of the futures contract. As the actual contract is a futures contract for -10 USD, traded in BTC, but the price is listed as the price in USD/BTC, a reciprocal comes in, confusing matters a bit, and the equation becomes (on your web page):
Vm = (1/p2 - 1/p1) * W/R
Here 1/p is the "real" price (in BTC/USD), and W/R should be the contract size, i.e -10 USD, giving a variation margin in BTC. However, on the web pages https://icbit.se/BUZ2 and https://icbit.se/BUH3 you list W = 0.0001 USD and R = -0.001 USD, giving W/R = 0.1 (no unit). So both the magnitude and the unit is wrong. The example at the bottom of the page correctly uses W/R = -10 (but leaves out all units). And the actual variations margins calculated in your trading platform are correct as well, fortunately
I have not looked closer into the Gold and Oil options, but since the prices here are listed in BTC I am a bit surprised to the reciprocal of the price in the equations.
There seems to be something wrong with the equations giving the variation margin on your web page. The actual calculation is OK, it is just the web page that gives the wrong expression.
The variation margin should be the price difference times the size of the futures contract. As the actual contract is a futures contract for -10 USD, traded in BTC, but the price is listed as the price in USD/BTC, a reciprocal comes in, confusing matters a bit, and the equation becomes (on your web page):
Vm = (1/p2 - 1/p1) * W/R
Here 1/p is the "real" price (in BTC/USD), and W/R should be the contract size, i.e -10 USD, giving a variation margin in BTC. However, on the web pages https://icbit.se/BUZ2 and https://icbit.se/BUH3 you list W = 0.0001 USD and R = -0.001 USD, giving W/R = 0.1 (no unit). So both the magnitude and the unit is wrong. The example at the bottom of the page correctly uses W/R = -10 (but leaves out all units). And the actual variations margins calculated in your trading platform are correct as well, fortunately
I have not looked closer into the Gold and Oil options, but since the prices here are listed in BTC I am a bit surprised to the reciprocal of the price in the equations.
The BUH3 futures contract (BTC/USD), started some 10 days ago already has had over $100K USD worth of trades (which is 1/5 of total BUZ2 volume which was trading for months!).
Merry Christmas to all christians! :-)
Merry Christmas to all christians! :-)
There was a message on Twitter:
But that was more than two hours ago without any update since.
The service is online but the Orderbook for each instrument is blank.
Quote
Site will not be accessible (another maintenance) shortly for a period of up to 5 minutes.
- https://twitter.com/icbit_se/status/282577017466150912But that was more than two hours ago without any update since.
The service is online but the Orderbook for each instrument is blank.
Sorry it took too long, it's all back online now and working properly.
Jump to: