About the only options are VirWoX and BTCQuick.

For VirWox, you actually buy Second Life Lindens (SLLs) and pay with credit card.  Then you convert those SLLs to BTCs and withdraw.
 - http://www.VirWoX.com

For BTCQuick, it depends on catching them when they have stock:
 - https://www.btcquick.com/buy/index.php?route=product/category&path=60_63

Otherwise, you pretty much are stuck.

I did see that Transferwise now accepts Debit card (EUR and GBP).  So you could then add funds from TransferWise and transfer those to your exchange account (e.g., if GBP, then convert to EUR and use SEPA withdrawal to BITSTAMP).

But cash is really the easier way to buy coins in most areas (U.S., Canada, Australia, New Zealand, Russia, Brazil, E.U., and more).   

In the U.S., cash deposit at BItMe (using Chase bank), BitFloor (using Bank of America), Ziggap (Using Western Union or Moneygram), BitInstant (Moneygram) and more.   The other options can be found from this list:

 - http://en.bitcoin.it/wiki/Buying_bitcoins

Here's someone else, couldn't even get anyone to do a $2 trade with PayPal.  Even after posting a pic of a sad looking puppy.   

But that same person could find a lender for same, just by offering a usurious interest rate.   It's a bizarro world.

Does this help?

 - http://en.bitcoin.it/wiki/Tor#Pooled_Mining

That really is what determines what price you pay.

If you simply sit above the current highest bid, eventually someone will hit you because someone will sell at market rate eventually (and that's your bid).  What could happen is the exchange rate rises though and you have to stay above the highest bid and you could end up paying more than if you hit the lowest ask right off the bat.

So it all depends what you mean by "relatively quickly".  Since you don't when a sell order at market will come in that could be hours or more.  Or it could be ten minutes.

Decentralized (proof-of-work based) digital currencies are vulnerable to a 51% attack.  Thus to be protected they need a sufficiently high level hurdle to reach 51%.  

When Bitcoin was small, its hurdle to being 51% attacked was that nobody knew it was anything more than an experiment.  There was relatively little value crossing the wires.     Today Bitcoin is protected from a 51% attack by the fact that to do so might cost tens of millions of dollars (if attempting just to procure the equipment to do a brute-force 51% attack.)

This is not something "very, very vanilla" between Bitcoin and the alternatives.

I've no idea what you did but there should not be a directory called "bitcoin.-recan" or any new directory.  

Your wallet.dat contains the private keys necessary to spend.  As long as you still have that, you should still have access to spend those funds (once you get a client in sync).

At this point you are first simply trying to ascertain that the funds are still there.

In the bitcoin client click on Receive.  Do your addresses show?  If not, you are running the client against an empty wallet.dat.

You can stop the client and swap out wallet.dat files (e.g., rename the current one and restore from backup another one) to see if that shows any different.   With 4K blocks to go, that means if you did ANY spending with your wallet since January you shouldn't trust the balance that shows until it has sync.   Newer versions of the client don't show bogus results when not in sync, so if you had done any spending from your wallet then this is a problem that you see only because you are still on an older client.

Discussed here:


When the funds for Mt. Gox's current U.S. and Canadian customers are "transitioned" and then handled by Coinlab, that's discussed here:


 - http://coinlab.com/storage

Put simply, look at the following image.  

For you, up just a little is something bad.  Up like this is redonkulously bad.


 - http://bitcoin.sipa.be/speed-small-lin-ever.png

And that is with not all Avalons that have been paid for being shipped yet, nonetheless how BFL hasn't even started shipping.  Either of those happens and there won't be a single remaining GPU miner who can smile (unless, of course, there is a corresponding BTC/USD increase that tracks the difficulty increase).

Sure you can.  It just takes one or more miners to mine before transactions are included in a block and eventually confirm.  Just like after the hard fork occurred and v0.8 was ten blocks ahead, anyone could still mine on the v0.7 side even though it had just a fraction of the hashing capacity and the v0.8 side had the longest chain.

It isn't the miners who decide.   It is the economic majority who will buy the miner's coins that decides.  

If this happened today and the very next block were to be a fork as you describe as 80% of the hashing power ganged up and switched over to a client that followed your protocol change, the decision facing users, merchants and exchanges would be .... do we follow, or do we boycott?

Probably what would happen is that payment processing for much of the bitcoin economy would be immediately halted (i.e., there would be no recognition of confirmations on either side of the fork) until some discussions occur.  But if those who buy coins (the economic majority) were to boycott the protocol change, it would only be a matter of time (minutes to hours) before individual miners would leave the pools that pulled that stunt and the chain for the original protocol would gain and extend beyond the height for the chain with the changed protocol.

[Update: And the difference between your scenario and this weeks' hard-fork was that users, merchants and exchagne were already using software that unknowingly accepted the rule change (no more 10K BDB locks, and reverting to v0.7 was compatible with both v0.7 and v0.8 clients.  i.e., it didn't require everyone to have to change their software to something that understood a change to the protocol rules.]

Is this pretty much BTCJam except with more social network stuff?

Related:
 - http://en.bitcoin.it/wiki/Tax_compliance

Manually?
 - http://brainwallet.org/#tx  <--- Be very careful to spend every bit of the funds (except the fee), otherwise the unspent balance goes ... to fees.

Also, EasyWallet from a mobile has one-touch scan and redeem (to an EasyWallet).   But I believe it is N confirmations (3 ?) before the funds appear in the wallet.
 - http://www.EasyWallet.org

The field for Quantity is assuming the input is Octal numbers when there is a leading 0.  e.g., if I enter quantity 011 that gets understood as 9.   If I enter 09 that gets an "invalid quantity" (because in octal, anything above 7 doesn't exist.)

The original transaction (to OKPay) had fees of 0.0005 BTC:
 - http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195

The double spend transaction had fees 0.00139906 BTC and was mined by BTC Guild.
 - http://blockchain.info/tx/762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91

The double spend transaction wasn't seen by Blockchain.info until 2013-03-12 08:07:30, which was hours after the chains converged.  It got included in the next block.  But BTC Guild had already mined a dozen blocks on the v0.7 side by then.

I'm wondering if BTC Guild included the double spend transaction because of the higher fees versus following the protocol of rejecting it as invalid (for having an input that was already spent in a previously received transaction).

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].

Here's the thread:

Chances are you've been playing Satoshi DICE (even if that was a month ago). 

Does the transaction show up in the blockchain (e.g., on Blockchain.info ?)

If not, let your client run for a half hour to an hour to ensure there is an attempt to re-broadcast it.    Then check blockchain.info again.

The transaction fees are claimed in the coinbase, so a party refusing to accept a miner's proceeds (by boycotting a corresponding protocol change) means also refusing both the block reward subsidy as well as any transaction fees.

If you can't find a trade here, ZIGGAP offers this.
- http://www.ZIGGAP.com

I just tried and would access it through Tor just fine.


EasyWallet.org is like Instawallet.