Yep. We went down 10 minutes ago; I just got notified.

There is some sort of problem with our hosting provider; I've filed a critical level ticket, updates here shortly.

Re: API, yes, that's a possibility. The other option is that API devs pull the data from the cookie directly; re: ESAPI, thanks, I'll check it out.

Yep, I totally get the motivation. If I didn't say it before, good luck!

I've been thinking about a long-term value storage solution.. These recent attacks are brutal, 25k coins is horrible, but it will be much more horrible in 10 years if I'm not mistaken.

Here's my current long-term bitcoin storage plan for the 'save for later' coins. I assume here that we are not paranoid about Chinese bootloaders.

1) Purchase new laptop / install clean and fresh Ubuntu onto formatted hard drive
2) download client. Do nothing else on computer
3) download block chain.
4) download optar, (about which more in a second)
5) From current, possibly insecure computer, send "storage" coins to minty fresh computer.

6) Disconnect new computer right after address generation and you have optar, and can see the the coins at least at 0/unconfirmed in the new wallet.
7) Backup the wallet onto the netbook drive, doesn't matter where.

Use optar to print out a PAPER archive of your wallet.dat file: (more here: http://ronja.twibright.com/optar/)
9) seal paper in pouch
10) safety deposit box
11) re-format hard drive of laptop.

You could GPG encrypt the wallet before it was optared, although then you'd need to remember the password for 20 years.

A brief description of optar: it prints scannable bitmaps onto paper. You can fit a few 100k per page with good error correction rates. Low acid paper plus laser printer = long, long term archival storage.

Thoughts?

Bitoption was hit with CSRF attacks today as well; no successes, though.

Re: Curl and Mt. Gox, I believe they changed their SSL Cert recently. My linux boxes didn't have a good CA chain to their authority, and resisted all attempts to add the chain in. Eventually I just imported the direct Gox one and marked it trusted. Curl finally shut up at that point.

Major update for API Developers:

We have moved to using posts for many API requests. I'll update here when I've had a break. Read our main thread for information about CSRF vulnerability cuddlefish pointed out to us today.

OK, we are now requiring posts and using server-generated xsrf tokens for all form submission, html or ajax.

My API developers are going to hate me for a little while, except that they are able to keep all their money, so that should help mollify them. Thanks for notifying me cuddlefish, much appreciated.

My experience building bitoption is that BTC denominated caused many confusing headaches for people who wanted to actually trade in the system. Of course, options have multiple prices associated with them, so it's confusing.

Good luck!

UPDATE: I believe we are now resistant to CSRF attacks.

In fact, click this link to try: https://bitoption.org/sendBTC?amt=200. A common hack is to embed that url in an image link. If someone tries this, they'll be outed pretty quickly.

The site is back up with a few other requested improvements, including better feedback while waiting for exchanging, posting, withdrawing and depositing.

That was fun! Well, not really. I'm tired and chagrined, but happy that ultimate impact seems to have just been on my time.

Damien, I'll respond to your thoughts later, thanks for sending them on -- much appreciated.

p.s. try the link.

Cuddlefish, thanks for the heads up. I'm implementing fixes right now.

As an aside, we got to it early; there is an attempted exploit out in the wild for bitoption right now, but it was unsuccesful.

For discussion, I repost our top of thread status here:


Update:

There is an attempt at a CSRF in the wild right now aimed at bitoption.org. It tries to send 20 BTC to an address starting with: 1GEwYPX6..

I reviewed our balance sheets and transaction log; nobody has been hit by this or any other CSRF to my knowledge; I manually reviewed back four days of transaction, and scanned the rest for repeated withdrawal requests to confirm.

That said, someone has clearly posted an image link, likely in these forums, which directs to sendBTC?etc.etc. This image link will not function, and has not been successful against bitoption.

The site is down right this second, I am putting in a few layers of protection against this, and will update when it's in place.

In the interim, if you would like to exercise your contracts, please email me at admin@bitoption.com FROM your account email, and I'll manually fill your requests, including withdrawals if you need.

I anticipate a few hours to get this sorted out; there will be a slight impact on API developers as well.

Sorry, this is my bad; I thought about XSS but not CSRF when I implemented the API. My hope is that the damage is limited to a little downtime for you all. More here and in the status thread as it comes!

Update:

There is an attempt at a CSRF in the wild right now aimed at bitoption.org. It tries to send 20 BTC to an address starting with: 1GEwYPX6..

I reviewed our balance sheets and transaction log; nobody has been hit by this or any other CSRF to my knowledge; I manually reviewed back four days of transaction, and scanned the rest for repeated withdrawal requests to confirm.

That said, someone has clearly posted an image link, likely in these forums, which directs to sendBTC?etc.etc. This image link will not function, and has not been successful against bitoption.

The site is down right this second, I am putting in a few layers of protection against this, and will update when it's in place.

In the interim, if you would like to exercise your contracts, please email me at admin@bitoption.com FROM your account email, and I'll manually fill your requests, including withdrawals if you need.

I anticipate a few hours to get this sorted out; there will be a slight impact on API developers as well.

Sorry, this is my bad; I thought about XSS but not CSRF when I implemented the API. My hope is that the damage is limited to a little downtime for you all. More here and in the status thread as it comes!

I've just cleared my schedule for a few hours.

Hmm, I'll check that right now.

boris_37, $7 puts are likely extremely cheap on bitoption.org if you want to make a bet on that kind of price movement.

BTC will not even out until it achieves some kind of growth-use stasis. Until then, rising demand will spike prices periodically. Speculators wil push it around as they will for some time; there won't be enough volume to be resistant to manipulation for quite some time.

This value-increase curve is built into the currency; it will not go away for quite a while.

Proposal for Margin Trading System for Bitoption

Goals: Primary goal is to increase liquidity. Secondary goal is to allow traders to speculate more. We cannot break our 'escrowed' commitment to users, so we must make sure all written contracts can be fulfilled. We want to keep the market's margin risk low to nil as well, but this is secondary to the commitment on fulfillment.

Plan: Increase "Available" USD and BTC Calculations using some netting formulas (below), and allow anything up to the Available to be bidded/asked on any given strike price / date / put or call. Implement auto-closing of bids / asks, and auto-exercise if account negative to reduce margin risk to exchange.


Proposed Netting Calculation:
-----------------------------------
Currently your available USD is calculated as: Actual USD - #/puts written * strike of puts.

This would be updated to be: Actual - #/puts written * strike + #/puts bought * strike (for puts that you have real BTC to exercise).

Available BTC is calculated as: Actual BTC - #/calls written.

It would now be: Actual BTC - #calls written + # calls bought (for calls that you have real USD to exercise).

The most valuable puts and calls would be used to calculate last number in each.

Scenario 1
So, let's say you have $100 USD and 10 BTC.

You write 5 calls for December at $100, price: $5. They get bought.

Your old and new available calcs would give you: $125 USD and 5 BTC.

Now, let's imagine two weeks later, you buy 5 calls for December / $100 and you pay $2.

The old calculation would say you have Available BTC: 5, USD: $115.

The new calculation would say you have available BTC: (10 - 5 + 1 call you can pay for) = 6, USD $115.


Scenario 2
You have $100 USD and 10 BTC.
You write 5 calls for December at $100, price: $5. They get bought.
You buy 5 calls for late July at $20 for $10.

Now you have:

USD = $75
BTC = 10 - 5 (for calls written) + 3 (as you can exercise three of your calls for $60) = 8.

Let us now imagine that you write 8 calls for early July, $25 strike. You are paid $1 per.

USD = $83.
BTC = 10 - 13 (for calls written) + 4 (you can now exercise a fourth call) = 1.

Now, imagine that the 8 calls are exercised.

USD = $283
BTC = 2 - 5 + 5 = 2

Now, you for some reason do not exercise your late July calls. After expiration, here is how things look:

USD = $283
BTC = 2 -5 = -3

You are officially underwater. As SOON as this happens, we start to force close you out of your positions to get you back up to above water in both accounts.

How we would execute a margin call
For BTC:
1) We execute any in-the-money calls you own that you can afford, one at a time until we have you above water; lowest strike to highest strike.
2) If you are still under water, we exchange on Gox USD for BTC until you are above water
3) If you are still under water, you have no more USD and no more calls. We proceed to execute any in-the-money puts you have by:
  a) loaning you the BTC
  b) taking back our loan plus a small fee
  c) sending you the remaining USD
  d) exchanging the USD on Gox
4) If you are still under water, you're broke. You have no USD, no BTC, no puts, no calls.

The USD path is analogous.

So, one question is "when could 4 happen?" I'm not sure, frankly. If the path I suggest above is sensible, and we are careful about it, it might happen only in weird exchange circumstances. I'd hate to be wrong, though, so I'm asking you for help testing out this plan in your head..

One thing is clear, we will need to do this margin check before you are allowed to withdraw USD / send BTC.

Thanks for the comments; I took a day or two off except for service requests. my brain was exploding.

mmdough, I'll e-mail you.

Other thoughts are excellent, and I'm working on them. I interviewed on programmer this week, and another is interviewing next week, so hopefully updates will come even faster soon. I'm limited in my hiring somewhat by BTC values, so if it keeps dropping, I'll probably have to cancel the programmer. (Remind me to buy some puts..)

Next post is my proposal for the margin system, comments desired.

Hey Franzl,

I'll check into this and get back to you via e-mail!