Sure...

If I hold the call option in October and BTC is $3000, then I am almost certain that in December I will be exercising the option (i.e. buying a BTC for $1000).  Therefore, my exposure to the price of BTC (or "delta") is very nearly 1.  So to "delta hedge" myself I can sell 1 BTC in the market at $3000.  Meaning my total position is +1 delta from call option -1 delta from BTC sale = 0 delta net.

If subsequently the price of BTC drops to $800, say in November, it then appears unlikely I would exercise my option, so the delta of the option drops towards 0.0.  My position is now 0 delta on the option, -1 from my previous sale = -1 net delta.  So to "delta hedge" my new position I should buy 1 BTC in the market, which I can do at $800.

So just by hedging the option as the market moves, I've been able to sell 1 BTC at $3000 and buy 1 BTC at $800, making $2200 profit.  I'm sure you can imagine that the more volatile the market is, the more opportunities I have to buy low, sell high.  Therefore the buyer and seller express their views of future volatility when agreeing the premium on the option.  If I can make more money delta hedging the option that it costs me in premium then it's a good trade.  Everything is the exact opposite for the seller of the option (i.e. if he delta hedges the option he will be forced to sell low and buy high, but is compensated by the premium for doing so).

Hope that makes some sense!!

It would be a "European" style option which means no early exercise (we're in London after-all).  On an asset like bitcoin there would never be a reason to early exercise anyway, since you would just be surrendering some of the time-value of the option (in which you could continue to make money by delta-hedging as the market moves - again check Options 101!)

I buy the right (but not obligation) to buy bitcoins from him at $1000 on 11th Dec 2014.  I would pay him a premium when we agree the trade.  If bitcoins are below $1000 on expiry then I don't buy from him (exercise) and he earns the premium.  If bitcoin is above $1000 I would buy from him and my profit = Current BTC price - $1000 strike - premium.

The value of such a contract (and hence the premium I'm happy to pay) depends on how volatile the bitcoin market is before expiry... that's what is meant by "vol"... volatility.  There's a lot of info on option on Wikipedia/Investopedia if you're interested.

Yeah, it's definitely naked so I know there's a credit-risk, but we work together and I know he's good for all but the most extreme outcomes.  Still I'm tempted to help him along by capping his downside (maybe making the deal a call-spread $1000 vs. $2000 or something - i.e. I sell him back a $2000 call), though it's a shame to lose the convexity to the upside.

A work mate of mine (who isn't active in Bitcoin) was being all super-sceptical and bearish on BTC today in the office, saying it's going to crash further, it's a Ponzi, blah, blah.  I encouraged him to either put his money where his mouth is or shut his trap.  So we started to informally price-up a $1000 Call option expiring 11th Dec 2014 that he would sell.

I've calculated the recent realised vol (30-day rolling window), but was just wondering if anyone out there has quoted or traded options recently?  Any ideas where implied vol. would be bid out there?

http://i.imgur.com/IFLLOLl.png

Unfortunately, my buddy started out offered at 100% implied vol, but then flaked when I was keen to buy it...    He now seems tentative to sell 150% vol.  Anyone reckon that's value?

Interview just aired on CNBC with Branson saying Virgin galactic to accept BTC, and that he has personally invested in Bitcoin.

Ummm... that guy behind looks a lot like Jeff Garzik to me.

Old trading wisdom...

Bottom-picking is a dirty business.

I would advise caution with regard to CoinFloor for a few reasons:

• It is run in part by Nefario, someone tagged as a scammer on this forum (who still owes me and others BTC from the shutdown of GLBSE).
• Given he is CTO of the site, his GLBSE security record should be recalled.  There was a significant theft from that site (~3500 BTC I believe).
• Also worth considering that every single bitcoin exchange in the UK so far has been cut by banks backing.

Trading through BitBargain and LocalBitcoins is by far the most secure method.

Quick update on my attempts:  Got the latest testing branch 0.89.99.6, and also boosted the ulimit on files to 4096 (from 1024).  This time I got much further in the database rebuild (to the 48th block file), but it eventually fell over with a "Bus Error" (OS error, not a Python Exception).  Trying to restart now without the --rebuild option and it seems to have continued from where it left off, so hopefully after a couple of attempts I'll get fully synced!

@etotheipi: Let me know if you want me to e-mail you any cores or logs?

Thanks.

Thanks, will give this a try tonight.  FWIW, the last run (not your latest code) failed due to exhausting file handles.  lsof lists lots of ~/.armory/databases/leveldb_blkdata/*.sst files open.

Yes:
Ubuntu 12.04 (precise) 32-bit
AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ × 2
2GB RAM

Will look further tomorrow (on London time here  )

Thanks for your help so far!

Just to update on progress from that thread...

The --rebuild progressed for me until the 18th block file, then raised the same socket error just reported.  Armory GUI was still responsive, but stopped processing further blocks.

Not had chance to look in detail at the satoshiIsAvailable() method, but perhaps socket creation should be within the try block?  Might hack that myself and give it a go.

Thanks for the suggestion, giving --rebuild a try now.

I've not needed to move BTC for a while and now I'm revisiting, I'm having a lot of problems getting Armory running on my online machine (mostly since it's a tad under-specced @ 2GB RAM).

I use cold-storage, and I've got coins in an address that was created online, but the offline wallet has never had to sign txns for it.  As a workaround, is there any way I can derive the private key on the offline machine for the online-generated address, to let me use an alternate client?

As a side-point, I've also tried the new testing branch, but that has problems after scanning the blocks, throwing a segfault...


Any assistance greatly appreciated!

Is there any established way to take a short position on mining return... Example: sell 100GH/s Nov13 @ BTC / GH/s

I see you can get long on cex.io, but this isn't really a GH/s "futures" contract, rather physical delivery, which makes it hard to short (i.e. you need to mine to get the GH/s to sell).

Looks like OTC will be the only option, but perhaps someone knows better...?

rPw9LWaEecYJvWsC2TgyrNooZG8S7HEpB6

I'm no lawyer and I'm sure your council will find a way, but rather than keep the securitised "mining bond" contract/configuration/nomenclature, could we not simply define Gigamining as a lease or rental agreement for a portion of the physical hardware?  I don't see how this would differ from say, leasing a Linode.  All totally outside securities regulation.

I mean... I don't think any investors saw this as an actual *bond* in the traditional meaning of the word... (I'm not expecting to be near the top of the list of creditors in case of default).

Anyway, fingers crossed the wind-up will roll along without too many hitches (FWIW a friend and I spoke with Nefario at length at the London conf.  He came across to me as a genuinely pleasant and honest guy and I am certainly happy to trust him for the portion of assets I have lodged at GLBSE, which is not an inconsiderable sum).

Along a similar(ish) line, I implemented (for fun) a private-key sharing mechanism around the Armory python library... effectively you Shamir-split the private key of a user's deposit address, then only ever store one half on the server.  The other-half must be given to the user and never persisted by the exchange.

This would potentially make quite a nice protection mechanism for long-term deposits or even initial margin balances.  If the database was completely publicly exposed, you could just find the exchange's share of your key and retrieve your funds yourself.  Might be a nice stop gap until multisig comes along.

Another possibility is to require users to make their first deposits from an address they control.  Any password change, contact details change, etc. would then require the user to sign a server-generated message from that address (again Armory does this nicely).

I'm sure appropriate lawyers have already answered this, but would the Californian courts hold any jurisdiction over a UK incorporated company (and/or directors) and the NZ main entity?  What action could this court realistically impose on the company?