Bitcoinica: How it works

[cypherdoc]

It wouldn't be that hard, true, but it would be very risky. The difficulty lies not in the execution, but in the fact that none of us here has the capital required in order to do it - or else we wouldn't be complaining about it in public.

hey, speak for yourself 

[1713942090]

1713942090

[1713942090]

1713942090

[1713942090]

1713942090

[1713942090]

1713942090

[1713942090]

1713942090

[cypherdoc]

i guess i polluted this thread to the pt where Zhou has left 

[cypherdoc]

do you think he'll still let me setup an acct?

[mjcmurfy]

I wondered that myself after all the criticism I slung at him a few weeks back. Not bloody likely! Heh.

I'm almost convinced that he has blocked my IP range somehow. I can't access bitcoinica from my home ISP connection anymore, just get server not found errors. I have to go through a proxy to find out bitcoinica's daily volumes!

Just to be clear, I'm being facetious again. I'm not accusing zhou. But it is pretty weird.

[ineededausername]

I wondered that myself after all the criticism I slung at him a few weeks back. Not bloody likely! Heh.

I'm almost convinced that he has blocked my IP range somehow. I can't access bitcoinica from my home ISP connection anymore, just get server not found errors. I have to go through a proxy to find out bitcoinica's daily volumes!

Just to be clear, I'm being facetious again. I'm not accusing zhou. But it is pretty weird.

Hmmm interesting... didn't know zhou was blocking people from accessing Bitcoinica...

[mjcmurfy]

I wondered that myself after all the criticism I slung at him a few weeks back. Not bloody likely! Heh.

I'm almost convinced that he has blocked my IP range somehow. I can't access bitcoinica from my home ISP connection anymore, just get server not found errors. I have to go through a proxy to find out bitcoinica's daily volumes!

Just to be clear, I'm being facetious again. I'm not accusing zhou. But it is pretty weird.

Hmmm interesting... didn't know zhou was blocking people from accessing Bitcoinica...

LOL. Yep, very suspicious. Maybe you should withdraw all your bitcoins and send them to me for safekeeping!
And before I forget, did you hear that panerai is supposedly a hermaphrodite? Tell EVERYone.  

[zhoutong]

do you think he'll still let me setup an acct?

Sure, you can try that.

But in order for your to sell your 100 BTC to Bitcoinica at a profitable price (at least $4.4), you have to meet the following criteria:

- Have a few sizable bids over $4.4
- Maintain them for at least 8 seconds (two 50 BTC blocks)
- Not being eaten by major market players

Since the launch day, there were a lot of people speculating about the possibility of a financial attack, but so far only one guy has done it successfully (due to a bug in the algorithm in the early days).

You can try anything you want. But please be aware of the potential risk.

[zhoutong]

I wondered that myself after all the criticism I slung at him a few weeks back. Not bloody likely! Heh.

I'm almost convinced that he has blocked my IP range somehow. I can't access bitcoinica from my home ISP connection anymore, just get server not found errors. I have to go through a proxy to find out bitcoinica's daily volumes!

Just to be clear, I'm being facetious again. I'm not accusing zhou. But it is pretty weird.

I'm not sure what happened, but several people reported this to me. (I never block anyone from accessing Bitcoinica.)

You can use Google DNS 8.8.8.8 / 8.8.4.4 to get domain resolution correct. It's your ISP DNS problem.

I guess it's because of our Anycast DNS not working properly, and I will try to fix that.

[zhoutong]

Update on the OP's suggestion

Now whenever Bitcoinica is out of reserves (either USD or BTC), everyone can expect:

- Free to close any previous positions regardless of direction and order type (until the critical quantity, which should almost never happen).
- Not able to establish new positions (or increase existing positions) in certain direction until the reserve has been re-established (by others' deposit, or opposite trading).
- The price will show like *4.70594 (with the asterisk) to indicate trading restrictions.
- All pending orders are shown as "No reserve" and they will be "Active" again once the reserve has been re-established.

It's highly recommended to place limit orders when trading restrictions are imposed, so that there won't be surprise execution prices after the removal of restrictions.

Now you can safely place stop loss orders because any trade restrictions will have no effect on these orders!

[Mushoz]

Just tested it! Working great! Thanks for implementing this 

[Mushoz]

We have virtually no risk.

The market doesn't slip every 5 seconds. And during most of the violent moves previously, we received no or only a few orders. The high volume was always generated after the violent moves.

Now thankfully, Zhoutong, you seem to have the risks of slippage covered as explained above this quote, but your reasoning in this quote is flawed. Never _ever_ think something is not going to happen because it hasn't happened before. Always expect the worst and then some. This applies to anything, not just slippage risks. If you haven't made simulations in which there was heavy trading _during_ price movements, you should!

Even though I don't have any practical experience to prove this (because it never happened before), I do have theoretical consideration.

The main problem of any system with guaranteed liquidity is adverse selection. We are exposed to the systematic risk of customers trading only when they have opportunities to take advantage of price differences.

A similar example is exchange quotation. TradeHill gives users 5 seconds to confirm a Instant trade quotation. But since there's no cost to get a quotation, theoretically there's one possibility: a user gets a quote every 5 seconds, and confirm only when there's huge slippage.

What I have done here is to delay all order execution by 1-4 seconds. This makes sure that when you click Buy/Sell button exactly during the slippage, the actual execution will happen after the major price move.

And this is still considered as "guaranteed liquidity" because we update prices globally, not just for individual pending orders.

Mushoz:  can u translate this?

It means he is protecting himself against slippage due to random moves by using spreads, but the biggest risk is people trying to exploit slippage. Let's say the price is at 4$ on Mtgox and suddenly a spikes causes it to go down to 3.60. Someone wanting to exploit slippage could quickly sell at Bitcoinica, where the prices wouldn't have been updated yet. That's what the 1-4 second order execution delay is for. It allows the price on Bitcoinica to catch up to the market price, so that people aren't able to exploit slippage.

what if the spike comes at exactly 4 sec after the customer pushes his button?  what if a series of ramps occur?

i know, i know; he says he only executes 50 BTC at a time but in his explanation above he says 50, 100, sometimes 150 BTC.  which is it?

If the spike comes exactly 4 seconds after order placement, we can be sure that the customer was not intending to exploit the spike because no one actually knew.

So it can be 0, or 50.

100 and 150 are possibilities when multiple customers place order at the same time, and it's extremely rare.

what if i'm the one who pushes the button on Bitcoinica, counts off 4 sec, and pushes the button on mtgox creating the spike?

Then you would have lost a lot of money creating a sizable spike, would you not?

not if at a given pt in time both gox and bitcoinica have respective asks say @ $4 and $4.10 due to low activity in the market.  example:

i have accts at both gox and bitcoinica.  i push the buy button at bitcoinica to buy say 100 btc, count off 4 sec to secure the buy @ $4.10, then push the mtgox buy button to buy whatever it takes to create a spike to $4.5 before bitcoinica has a chance to hedge @ $4.  once bitcoinica adjusts its bid to say $4.4 i then sell those same 100 btc on bitcoinica for $4.4

In that case, with perfect execution you will profit 30 cents per BTC times 100BTC, which will net you 30$. The USD required to create such a spike is _far_ more and it is far too risky to try and profit 30$. It would only be possible if the depth was very shallow, weren't it for the fact in that case the spread is a lot bigger to compensate for the shallowness of the orderbook.

[cypherdoc]

In that case, with perfect execution you will profit 30 cents per BTC times 100BTC, which will net you 30$. The USD required to create such a spike is _far_ more and it is far too risky to try and profit 30$. It would only be possible if the depth was very shallow, weren't it for the fact in that case the spread is a lot bigger to compensate for the shallowness of the orderbook.

the numbers were made up.  my pt was to demonstrate that just b/c you delay the customers buy order by 4 sec doesn't solve the slippage problem as a motivated attacker with a decent size acct at both places could still game the system knowing that the 4 sec rule was in place.

[Mushoz]

In that case, with perfect execution you will profit 30 cents per BTC times 100BTC, which will net you 30$. The USD required to create such a spike is _far_ more and it is far too risky to try and profit 30$. It would only be possible if the depth was very shallow, weren't it for the fact in that case the spread is a lot bigger to compensate for the shallowness of the orderbook.

the numbers were made up.  my pt was to demonstrate that just b/c you delay the customers buy order by 4 sec doesn't solve the slippage problem as a motivated attacker with a decent size acct at both places could still game the system knowing that the 4 sec rule was in place.

That's what the 50BTC blocks are for. You aren't going to turn in that profit over more than 2-3 perhaps 4 blocks. The profits will pale in comparison to the funds needed to create that spike in the first place.

[cypherdoc]

In that case, with perfect execution you will profit 30 cents per BTC times 100BTC, which will net you 30$. The USD required to create such a spike is _far_ more and it is far too risky to try and profit 30$. It would only be possible if the depth was very shallow, weren't it for the fact in that case the spread is a lot bigger to compensate for the shallowness of the orderbook.

the numbers were made up.  my pt was to demonstrate that just b/c you delay the customers buy order by 4 sec doesn't solve the slippage problem as a motivated attacker with a decent size acct at both places could still game the system knowing that the 4 sec rule was in place.

That's what the 50BTC blocks are for. You aren't going to turn in that profit over more than 2-3 perhaps 4 blocks. The profits will pale in comparison to the funds needed to create that spike in the first place.

not in an uptrending market like this.

[sgbett]

plz explain ... now 11mins... i see no restriction on the sell side why so long to execute....

[cypherdoc]

plz explain ... now 11mins... i see no restriction on the sell side why so long to execute....

i thought it was supposed to be 4 sec?

[sgbett]

I am used to it taking 5 or 10 secs, and for bigger orders to take a while to go through as they get chipped away at in blocks of 50, but this is doing my head in. The quoted price was above my order price for at least 15 mins. Its now gone below again.

I'm also starting to wonder, given the 'USD Shortage' whether that means I'l be able to get USD's out, because if this flakiness continues I am pulling everything.

[Mushoz]

A bug in the algorithm could be preventing orders on both sides? Hmm this is not good. Zhoutong, could you have a look please if everything is working as it should? There's no * next to the sell price, yet some people seem to be unable to sell...

[zhoutong]

Update

Just now our clock server went down when I was pushing updates when the message queue was just emptied. It turned out to take a much longer time than usual. So all price ticking and order matching were paused.

I apologize for the issue.

Now everything is working fine!

[sgbett]

Order completed ...

112445   BTCUSD   Limit   -50.0   $4.6500   18 minutes ago   Executed @ 4.6674

thx xx