I am a bit sceptical (to say the least) about this proposal.  It seems that little is gained by members to offset the economic risk they are taking, unless they are able to change the rules in such a way to favorize themselves - which would of course chase everybody else away.

I really think you should consider allowing bids to be placed below the current trading range, and asks above.  That will allow us to build an "opposing side" of the order book in case of large price changes.  That will both dampen the swings, and provide a market when someone is margin called.

And +1 to the pseudocode suggestion

You don't need to post a request for this.  Etotheipi is working on a new wallet format that will include encryption of the public keys too.

Typing it is not as bad as it seems, I have tried it!  And actually, there is some redundancy in the paper backup, so you can get one letter wrong on each line, and Armory can still read it.

Just theoretically, it may be that the block chain has just grown so much that one of the arrays in Armory is now over 2 GB.  Such an object cannot be addresses in a 32-bit executable, and if that is the case all 32-bit versions of Armory have just stopped working.  That would be pretty bad, so let us hope I am wrong.

I think the limitations on the daily varation is a good idea, as it reduces volatility and reduces the sensitivity to "spikes" in the spot price.  The setup with 10% variation per clearing, and two clearings per day also seems like a reasonable compromise.  

However, I think the inability to place asks above the current maximum and bids below the current minimum is a bad thing, and should be allowed within an additional 10% or so.  I have three reasons.

1) If the spot market moves a lot, the price at ICBIT may hit the end of the allowed range.  In that case it becomes impossible to build an opposing side of the order book, and when the clearing happens the price moves rapidly as the relevant side of the order book is almost empty, except for a few ancient order left behind.

2) When the price thus moves suddenly, margin calls may happen.  But since the relevant side of the order book is empty, forces sell/buy cannot happen, and the "worst case scenario" will be invoked.  If we could pre-fill the relevant part of the order book before the clearing, we could act as counterparts to the forced liquidations.  The person being margin called would get a better price, and less people would see forced liquidations.  This is where it becomes important that there is still a limitation on the orders we can place, for example of another 10%.  That prevents me from placing buy orders at absurd prices like 0.1$ and hoping to profit unreasonably from someone to getting margin called.

3) Some of us are not able to sit in front of the browser 24/7, and may want to place orders relevant for the next trading session which are outside the range of the current one.

EDIT: Accidentally placing orders outside the trading range would be annoying, and it is nice that the interface prevents it.  So and additional step should be required to place such an order.  I suggest a check-box on the trading interface "Allow orders outside the trading range".  Even when checked, ask orders should only be allowed above the range, and buy orders below, and only within 10% as described above.

The problem is partly that Bitcoin is so volatile, that the exchange operator has to choose between exposing his customers to this kind of counterparty risk, only offering very small leverage, or take a huge risk himself.  Icbit tries to strike a compromise between the first two.

But I agree, it makes icbit unsuitable for hedging, and more risky for arbitrage (but then the arbitrage gain is much larger than elsewhere, but that does of course not help the hedgers)

You can see the procedure described on the web page under Margin Calls (worst case scenario).  I don't think it ever happened from I started to use ICBIT last summer until the bitcoin price ran amok this spring.  But since then volatility has been crazy, and it appears to happen regularly, despite the reduced leverage.

OK.  Is the loss also evenly distributed, i.e. it is better that everybody loose 1% of their positions rather than a randomly picked 10% loose 10%?  From your post, I assume it is.  I just got the opposite impression from chat and posts here, but that was of course just an impression.

Follow-up to my own post:

It appears that icbit keeps track of who is in each end of all the contracts.  This means that if I go broke, the poor guy who was unfortunately enough to trade with me on the exchange will take all the loss.  This random distribution of the risk in big lumps is in my opinion unfortunate, it would be better if the liquidations were distributed as evenly as possible among the people holding the opposite position.

This is probably really what happened.

Unlike futures market in the "real world", where the operator knows your identity and can come after you, your losses are limited to the amount you deposit on your margin account.  On an ordinary futures exchange, there is in principle no upper limit to your losses, as the exchange operator can drag you to court to get what you owe him.  The downside of this limitation of your loss it the introduction of counter-party risk: If your counter-party's loss is limited by his available funds, so is your profit.  And yes, this introduces a risk to arbitrageurs.  On the other hand, the profit is also above the normal in arbitrage.

We cannot have it both ways, and in a quasi-anonymous bitcoin setting this counterparty risk is probably unavailable, unless the fees are so high that the exchange can afford to assume that risk - but that would probably scare us all away.

You cannot spam the network with larger amounts either.  You have to pay a fee if the sum times the time since it was last moved is less than 1 BTC * 1 day (or something close to that).  So bouncing 1 BTC back and forth will cost fees, too.

Yes, it would be nice if "test transactions" were free, but there is no way the network can distinguish between your test transaction and my twenty million spam transactions intended to destroy the network.  The only way to stop me is to force both of us to pay a fee.  That fee was insignificant until the bitcoin price blew up - and I guess at some point it will be reduced.

See also this description of offline wallets: https://bitcoinarmory.com/using-offline-wallets-in-armory/

I was thinking along the lines of something simpler, like the standard deviation of the price divided by the mean, averaged over the last month.  Or something like that.

It is pretty hypothetical, but if somehow malware was sneaked into the USB distribution, then in principle that malware could write your private keys to the normal harddisk and then another part of the malware could harvest it when booted in online mode.  In principle, the same could of course be done over a USB stick.  Both attacks would of course require tailor-made malware to steal just your bitcoins.  Quite frankly, if anybody worries about this scenario, I think they need help from a psychiatrist rather than from a computer scientist 

Personally, I have an offline wallet in a virtual machine.  That is somewhat less secure than your suggestion of using a live DVD, since in principle the keyboard can be logged on the "real" machine, and the filesystem of my virtual computer can also be read from the "real" machine.  But then, anyone spending time writing specific malware to steal my bitcoins will end up being disappointed  

(but I also have real offline wallets ...)

plus500.com is now offering a CFD on the BTC/USD price, but they have the severe handicap of not handling deposits/withdrawals in bitcoin but in USD 

Perhaps you can work out how they prevent the manipulation problem, and then do the same.  (Or perhaps they have not solved the problem and will close that instrument soon.)

+1

I would really like to see the PIN and the fee policy being honored. 

Good.  We are still in turbulent waters after the last crash, so it is normal that margin requirements are still high - as long as it is a temporary measure, and not the "new normal".

Maybe you should have a "volatility index" and use the volatility during the last month or two to determine the maximal leverage :-)

Such a maker/taker fee is similar to what Intersango has been doing - the fee three times higher if you take an offer in the order book instead of making a new one.  Bitfloor went even further and made the fee for market makers negative.

I must say I don't like the clearing fee of BUK3, even though it is small.  I hope that will not be a pattern for future use.

And a final comment:  The leverage is getting a bit low.  I know that is part of a strategy of reducing counterparty risk, but the only way of eliminating that is removing leverage altogether, and that would make ICBIT uninteresting.  We are unfortunately moving in that direction.  I would rather have a slightly larger counterparty risk, and then be able to trade at 1:4 or 1:5.  I think that the combination of high fees and low leverage hurts the volume at icbit!

I would think that 15 or 30 minutes is way too short, both to prevent market manipulation and to prevent rapid fluctuations.  Would there be anything lost if that time is set to an hour, with an automatic announcement half an hour before?

Reportedly, Google harvests all URLs pasted into Chrome (as the URL bar and search bar is the same, and their server determines if it is an url).  Possibly they also harvest URLs from Google Mail (when you email the url to yourself).  This is probably how 3000 Instawallet URLs became searchable on Google.