A $1 move from $50 gives you a gain ~0.004 BTC (worth about $0.20 at today's exchange rate).  So if fees are 0.003 BTC per contract trade, you need nearly a $2 favorable move to break even.
A favorable $1 move from $80 gives you a gain of just ~0.0015 BTC (worth about $0.075 at today's exchange rate).  So if fees are 0.003 per contract trade you need about a $3 favorable move to break even.

If you hold until settlement there is no closing trade fee, so these are assuming you are doing a round trip.

Margin orders execute immediately.  There would be no order ticket except for one thing, there probably are no bids remaining.   So you filled at $60.06 and had some unfilled at the bottom of the range ... $58.50 -- at least that's what I suspect happened.


The trade fee for every BTC/USD contract type is different.    For BUH3 (Mar 15, 2013) it is 0.005 BTC for BUJ3 (Apr 15, 2013) it is currently 0.003 BTC but that can change at any time.

As far as margin calculations, they are set up the way they are set up.   They may not match what you are familiar with.   But that doesn't make them "all wrong".

Not really.  Merchants accept some risk of chargebacks from employing credit and debit card payment processing networks.  They monitor it and weigh the cost/benefit.

Here's why they will accept some risk.  Selling a Mc SubKing presumably provides profit.

A race attack is not easy to perform (when the merchant is properly configured -- no incoming connections, and outgoing explicitly to well connected nodes and/or subscription to double-spend monitoring service).  And there are no guarantees that the attacker will succeed.

So if I as an attacker some how were to get success 5% of the time, that means I pay for and eat 19 Mc SubKings to get the 20th "free" (on average).

I bet the restaurant would take that customer's business any day of the week, even with those odds.   Fraud is illegal so the attacker would probably be easy to identify -- as the only one ordering a Mc SubKing wearing a full facemask.

If the attacker attempts the Finney attack, success is more likely but it is very expensive.  In that attack, the payment is only made after a block (containing the double spend transaction) has already been mined but is held from being broadcast.  It costs the attacker about $2 per second (at BTC/USD of $50) to perform this attack.   This attacker would be easy to identify also.   He's the one waiting at the counter for hours until his miner gets a block -- then screams frantically about getting a few Mc SubKings ordered, fast, and sends payment as soon as the QR code is presented.  As soon as the merchant accepts payment the mined block is released and the funds double spent.   The restaurant can know of this right away, so again, the attacker would never order anything that can't be hauled out to the getaway car in a matter seconds.   So the full facemask would probably be helpful there as well.


It does however expose the merchant to the same risk of a double spend attack that the OP is suggesting is the reason to wait for confirmations -- BitPay doesn't insure or protect against it happening, they simply notify the merchant (via the same channel as the original payment notification is sent).

Now there is a scenario where a merchant would not want to accept on 0/unconfirmed.  

A coin change machine at an unattended laundromat.   The attacker could try over and over to get a successful race attack.  For the unsuccesful attempts, the atacker gets quarters at face value.     Essentially if the items is high value purchase (above $100), or low margin, and can be purchased without revealing identity -- that's not a good candidate for 0/unconfirmed.  

There's other solutions that could be used as well ... green addresses, BTC payments through an Open Transactions server, Ripple, redeemable codes, and much more.   The problem that Square just had with their gift e-codes shows that regulations make it expensive to pass around digital credits (as money transmitter licensing and consumer protection regulations would need to be considered).    So Bitcoin may have an opportunity to go where others can't.

You do realize that leverage can be used to speculate against bitcoin too, right?

tl:dr; The shorts are coming!

Status shows "Trading"  but no data shows, except for charts.  [Resolved]

2013-03-13 Aljazeera.com - Bitcoin rises, by Nicolas Mendoza
https://bitcointalk.org/index.php?topic=152671.0

by Nicolas Mendoza


 - http://www.aljazeera.com/indepth/opinion/2013/03/2013391325331795.html

Steps to go from private key to Bitcoin address:
 - http://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Coinbase you mean?   CoinLab hasn't yet "transitioned" the Mt. Gox customers from U.S. and Canada yet.

Not sure. 

You've closed and restarted the client I presume (i.e., troubleshooting rule #1, when in doubt, reboot!)

I've no idea how that is anything but a double spend.  A merchant received a payment.  That payment got six confirmations from the latest release of the Bitcoin-Qt/bitcoind client that had sync.   Then later that transaction reverted to 0 confirmations and will eventually disappear as if it had never been made.    

The coins that OKPay thought it got have since been sent by the customer somewhere else.

Spend #1 of a coin: to address of OKPay's hosted (shared) EWallet
Spend #2 of same coin: to address under customer's control.

There's no other name for it.  That's the definition of a double spend.

What did you withdraw, USDs or BTCs?

The factors that matter in order to give you the best answer include:

 - Where are you located (country)?  [You said U.S.]
 - How much are you looking to buy?
 - What payment methods do you have available?
 - How soon do you need access to the proceeds?
 - Is privacy important?

A fairly comprehensive list of options is compiled here:
 - http://en.bitcoin.it/wiki/Buying_bitcoins


For your first purchase this won't help much but if you go get started using Dwolla (create an account, link your bank account) you can get the clock started on your 30-day probationary period in which you are prohibited from sending any funds to a Bitcoin exchange.    Once that probationary period has ended you can use Dwolla to send funds to Mt. Gox (if you've verified your account with them) or Camp BX.  There are also individual traders who accept Dwolla USDs for trade on #bitcoin-otc marketplace.
 - http://www.Dwolla.com
 - http://www.Bitcoin-OTC.com

Coinbase is the quickest way (and among the cheapests) to buy using a bank account.  You don't get the coins right away but you do get the price locked in today.   The downsides are that they too have a 30-day probationary period in which you can buy a max of $100 worth of bitcoins per day.   If for whatever reason Coinbase flags your account, they'll cancel the transaction(s) days after you've initiated the transfer so don't assume you have the coins until you have the coins.

Cash works.  You can deposit cash for credit to your BitMe.com exchange account at Chase bank branches.  With BitFloor, you can deposit cash at any Bank of America branch. You can also add funds using your Capital One 360/ING account.   With Ziggap you can deposit cash as Western Union and Moneygram.   With BitInstant you can deposit cash at 7-11, Walmart, CVS, Moneygram. 

Of course LocalBitcoins works fantastically for matching up buyers and sellers.
 - http://www.LocalBitcoins.com

There may be other methods that work for you as well.

There is only so much space for free transactions in a block.   Miners will try to put even low priority transactions into a block when there is space.  If there is no space, then your transaction waits.    

The mining nodes keep transactions that it knows about in a memory pool.  However that too has a limit.  So if your transaction doesn't confirm in about a day and the miner's memory pool is filling, your low priority transaction might be the first to get shipped to /dev/null (it is based on age).   Your node would rebroadcast it but the miner would just add it back in to the memory pool as a new transaction.  And the process repeats until it gets /dev/null.

Bitcoin wasn't made for sub-cent microtransactions.  Because there was space to accommodate it, you used to be able to get away with free and/or low priority transactions.    Those days are just about over.

So, ..  just pay the freight.  

If you are sending SEPA to Mt. Gox, make sure to send to their EUR bank (Poland), not to Japan.

There are many SEPA methods:
 - http://www.BITSTAMP.net
 - http://www.Bitcoin-24.com
 - http://Bitcoin-Central.net

There's also InstaWire, BitcoinsInBerlin, bitcoin.de:
 - http://en.bitcoin.it/wiki/Buying_bitcoins

You can send cash (EUR) to Bitcoin Nordic in Denmark through the mail:
 - http://www.BitcoinNordic.com

What you are predicting is like the desert island scenario.  The answer to that was:


All this "desert island" would need is a single node with outside connectivity.  The bandwidth requirements are as small as what a dial-up modem provides, with intermittent / period connectivity during each day.  Then that node would then communicate with the local peers on the island.  New blocks would arrive to this node and new transactions would be broadcast out from it.

Of course, the requirement for there to be block confirmations before payments are recognized would be a necessary variation (e.g., no 0/unconfirmed for the anonymous tourists to the desert island).

Ok, I do notice it hasn't happened when I've not been logged in.  But then when I am logged in, even if I'm playing Play Money while logged in it will happen.  It also happened on Firefox 16.0.2 (Ubuntu) as well as on my Android Nexus 7 tablet (Chrome for mobile).  

So multiple browsers, multiple devices.  The only thing consistent is using my same login.  Maybe it is my account?  


I don't normally play roulette.  But to test I just tried on the same browsers and devices and no problem with roulette.  Went back to slots on each and got the indefinite spin right away.  It isn't consistent 100% but I don't have to do more than a spin or three and it will go with the indefinite spin for at least one wheel.

The BDB database lock limit issue discovered March 12th exists with every version of the reference client (Bitcoin-Qt, and prior to that WxBitcoin GUI, and bitcoind) prior to v0.8.


That's the definition of a hard fork.  Old software rejects new blocks which include the incompatible change.
 - http://en.bitcoin.it/wiki/Hardfork_Wishlist

So the moment the fork starts is when any clients not supporting the new rules are no longer supported.


Chances are when the hard fork happens most everyone already would have upgraded.

What that means is that the client released would support both the existing rules and the new rules, with the new rules not taking effect until some future point in time (based on block number).   So essentially if block_number > N then follow the new rules else follow the old rules.

And it would be released well in advance of block N occurring.  [Edit: i.e., two years, according to one core dev:

]

Bruce's client does not know Linda's public key.  Bruce knows Linda's Bitcoin address.

In the wiki article it reads "<pubKeyHash>".  I believe that can be used interchangeably with Bitcoin Address.    But it is not Public Key.

My first spin never ended (all three wheels). I waited maybe 60 seconds then hit reload, and it showed a loss.    Single line.

Then the next half dozen spins went fine.

Then I went three lines hit spin,   Left wheel stops, the right two wheels keep spinning.  More than 60 seconds.

I am on wi-fi with intermittent connectivity but not sure if that's the cause.   Chromium on Ubuntu Linux.