Indeed!

A very reassuring post... 

Generally speaking, stop orders are exceedingly risky!  I am sure you are aware of that, but newbies may loose a lot of money this way.

TL;DR:

The current price is 20$.  You put a stop-loss sell order at $16 to protect yourself against a crash.  Market crashes to 12$.

Your expectation:  You sold at 16 and can now buy back at 12.
Reality:  You probably sold at 5$ !!!



The full story:

When the price drops to 16$ and your stop-loss sell is triggered, your sell order is places in the queue of the trading engine, behind all the stop-loss sells triggered at 16.5$, 17$ etc.  Yes, there is such a queue, you normally don't notice, but in case of sudden heavy trading it is important.

Now this long queue of sell orders execute, burning away the bid side of the order book faster than anyone can submit new orders.  The automated triggering of stop-loss sells make this process very fast.  When your order reaches the head of the queue, the price has dropped to 5$

Moments later, people realise that there are cheap bitcoins available, and start buying back. The price rises to 12$, and the stop-loss sell has been very expensive.

Many variations are possible.  Not all end this badly, but many do.

One problem you are going to have to face is that there is no way to guarantee that a codes cleanup part runs.  You can e.g. try to catch any reasonable Unix signal and then clean up, but you cannot catch SIGKILL and SIGSTOP, the user can always do a "kill -9" on the Python process.

One way of doing it that I would consider is a separate "guardian process".  Armory starts bitcoind, gets its PID.  Armory then starts the guardian process, passing its own and bitcoind's PID.  Every second, the guardian process checks that Armory is still running, and kills bitcoind if not.  Every second Armory checks that the guardian is running, kills bitcoind and shuts down cleanly if not (*).  Every second Armory checks that bitcoind is running, and restarts it (and the guardian) if not.

(*) Restarting the guardian would be tempting, but it will only crash if something is seriously wrong.

They do indeed.  Thank you very much for fixing this!

Agreed.  I was asking because I am hoping that new series will appear. 

With around 2 weeks to go before settlement of GDG3 and CLG3 I am wondering if they will be replaced by new series, or if the volumes has been too low.

Unfortunately, neither the pending nor the rejected transactions appear in the transaction table.  I am 100% about the pending, and 95% sure about the rejected transactions not appearing - at least I have had transactions rejected (or at least never going through) in the past, and never showing up.   I guess there is a small bug here.

@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)

16.71

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

@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".

We all thought that this was correct.  But as I understand retep, he is trying to warn us that this is not correct, that there is a way to reliably double-spend without the help of miners.

That of course increase the risk of accepting zero-confirmation transactions, and for many people may move it from a small but acceptable risk, to a risk too great to run.

But there is of course a reason that all exchanges require at least 3 confirmations: Accepting zero-confirmation transactions will never be 100% safe.

And the continue as Armory does:

If you have understood this, you will have no problems entering your password a third time.  The the user "signs" that he understands with his password :-)

This worries me a little bit.  If I leave my computer while logged in (a stupid thing to do, I know) or if someone distract me on purpose, he can read off my password from that page.  I assume the mnemonic is created client-side, so it must be able to find the algorithm in the javascript, and inverse it.


What is the difference between writing down the mnemonic and just writing down the password?

I am not sure if there is a better way to do it - it is a balance between loosing coins through being hacked or loosing them by forgetting the password, some compromise has to be made.  But password recovery always makes me uneasy - if my password can be recovered by me, it can in principle be recovered by somebody else.

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.

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!

Another possibility would be to have the offline wallet in a virtual machine without internet access.  Of course a virus could still get access to the file in which the virtual machine harddisk is placed, and thus the "offline" wallet, but the virus would more or less need to be tailored to attack your personal configuration.  So if you keep thousands of bitcoins, you definitely want a dedicated offline machine, but for anything less I would guess that the virtual machine - or even the setup you suggested above - would for all practical purposes be secure.

I have the AppStore version of your app installed.  Should I go back to using the Cydia version (i.e. are new versions in AppStore being blocked)?

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.

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?