Correct.  The 2FA is to protect against a replay attack using your password to access the Blockchain.info website.  It does not protect the backups.

Someone with your blockchain.info/wallet password and access to the encrypted wallet file can decrypt the file and spend your funds.  [Edit: If you have your account configured with a second password for withdrawals, then that password is required as well in order to decrypt and spend the funds.]

Until there is a v1.0, the bitcoin.org client is considered "beta".

If you don't find a buyer here, you might check interest from these places:


Quote from: bitminer19 on December 12, 2012, 01:21:39 PM
I live in the UK.. so its gonna be wire bank transfer to UK. Are you able to do that?  


There are places to list your offer or find a trade as well. Such as:
 - https://localbitcoins.com/location/UK/london/


UK Bitcoin group on Facebook:
 - https://www.facebook.com/groups/300065276761228/


IRC:
 - http://webchat.freenode.net/?channels=#bitcoin-otc-uk


And there are frequently threads with buyers and sellers:



[Edit: And user Tenakha does cash trades:
 - http://bitcointalk.org/index.php?action=profile;u=65105 ]

With Mt. Gox, if I remember correctly for 2011 tax year the account holder could request that an IRS 1099-B report be generated for them.

In the U.S. there are big changes coming to the tax rates.  

So if you are in the U.S. and reporting your capital gains on your taxes, it is better to cause that transaction to occur in 2012 while the rate is lower.

- http://www.businessweek.com/news/2012-10-19/wealthy-advised-to-sell-for-gains-before-unfriendly-2013

So if you had bought a bunch a little over a year ago at the $2 to $4 range, they couldn't have been "long term" until they were held for a year.    So this is the first time that someone with a sizeable investment in bitcoins from late 2011 has been able to cash them out but still be classified as long-term gains.

They aren't so much worried about losing out on further gains as in locking in the gains they've already accumulated but taking advantage of the lower tax rate.

See the relatively big drop at the right?



That's because after the "halving" (to where the block subsidy dropped to 25 BTC per block) a lot of GPU miners are powering down.  They are powering down because they are losing money when mining.  They are paying more in electricity than the value of the bitcoins they get from mining.   The loss of this hashing power appears visually in the graph as a drop in the hashrate.

Only two things can fix the situation.  A much higher exchange rate (like BTC/USD in the $18 to $20 range), or the hashrate falling another 30% or so.   Even then if that happens, the only ones mining on GPUs profitably would be those who pay average electric rates or less.

But that argument is moot really.

The very first ASIC manufacturer to ship (and there are five independent efforts not even including Yohan's super-FPGA that he says they've built) will decimate whatever is left of hope for GPU miners.

So if you were going to buy an Radeon for gaming anyway, and want to play around with mining then would could do that without it costing you anything.   But don't plan on making any money from it.   Those days are likely long, long gone.

The term "wallet" is used because it is a term that people are familiar with, and thus the software was built to follow the concept of a wallet and would then be familiar as well.

But technically, a Bitcoin wallet never receives coins.

A wallet holds private keys that are needed in order to spend coins.

In your example, both clients would have the exact same balance and show the exact same transactions.

This occurs because even the wallet saved prior to the second transaction already had the private key for the second transaction.  This is because the Bitcoin.org client has a pool of unused addresses (pool size is 100 addresses).  

It does this so that you don't need to back up after every single time you click "New Address".

I'ld be curious to know the path between you and that node that mined it because if you were peered only to bitcoin.org clients that transaction would not have made it far. 

Because Blockchain.info considers transactions even when it is a double spend maybe they even relay these transactions regardless.  (and thus a well connected node that you reached somehow and then that it propagated the transaction to a node used by a miner.)

But the block was not mined by an address of any known pools, so that it is using a custom client would not be surprising.

Well, there are various order types for various markets. 

So far for bitcoin exchanges, there are two types of orders, market orders or limit orders.

Other financial markets such as stock markets and others have "kill or fill" (FOK) orders, and "immediate or cancel" (IOC) orders.

You might be interested in what immediate or cancel (IOC) provides.

 - http://en.wikipedia.org/wiki/Immediate_or_cancel

There aren't any bitcoin exchanges that offer this (yet).

Well of course, when closing the program any connections it had, either incoming or outgoing will close as well. 

Are you saying you then re-launch bitcoin-qt but can no longer connect to it via 8333?

You've missed a few headlines:

Virtual Heist Paralyzes BitFloor, the U.S.’s #1 USD Bitcoin Exchange
Sept. 05, 2012
 - http://betabeat.com/2012/09/bitcoin-heist-bitfloor-shut-down-romanshtylman-09052012/



That was addressed here:

- https://plus.google.com/109620439233076225324/posts/bLJRDHApjSP

That's why the recommendation is that a merchant running its own node should not have any support for incoming connections and to explicitly have an outgoing connection to a well-connected nodes.   In that scenario, presumably the well connected node will have the same transactions as the mining pools and thus the chance of a double spend (via race attack) is substantially less than 50%.

And if you have the ability to connect to the merchant's node you can double spend on 0/unconfirmed with at a success rate approaching 100%.

Because of this risk, those trading on OTC or in-person for cash with someone who doesn't have a good history of trust should consider verifying that no double-spend occurred by looking at the transaction on Blockchain.info (or using a service like a "LocalBitcoins Transaction" / escrow).

The pools may use customized clients that behave different from the stock bitcoin.org client, but how the Bitcoin.org client handles it is the first transaction a node receives goes into the memory pool (only if it is a valid transaction, of course) and the second one is rejected as the inputs have already been spent by a valid transaction.

That is likely to be what will happen here.    The first one (without the fee) got propagated fast enough that most nodes never even knew about the second one (with the fee paid).


Well, blockchain.info shows the first transaction (without the fee) as being "first relayed by" 127.0.0.1.    I was thinking that meant that it was a transaction sent from blockchain.info/wallet, but maybe I'm wrong there.  But that is a well connected node and likely that is the transaction that will be included in a block and the second transaction will never confirm.

 - https://blockchain.info/tx/e860c52cd705d398abac710dc9a1df81ca153267dea7857f34fada2cedbc8409  <-- First / No fee pad.
 - https://blockchain.info/tx/41a08e5afede7698f368d2516c6cb85134e158ae9bbf340d5382383b3d3b6183  <-- Second / Fee paid.

Ha, so the new rule caused the CUC to get yanked, then reverted with the new rule moving to the Talk page and the CUC put back in.

Of course, I don't think anyone expected this to not ruffle a few feathers.

That prediction was pretty easy to make, and pissed off miners who never made it to break-even is where we are at now:

Where is this utopia of which you speak?

But without Instawallet being a separate legal entity I am assuming that if Paymium were to be ordered to turn over any and all records relating to Bitcoin-Central account #nnnnn and those records included a deposit from an Instawallet bitcoin address that those Instawallet records too would need to be turned over, in order to comply with the order.

Nope.  The benefit goes to the party that is placing the new order.

If the newest buy order is for a price higher than was needed, that buy order gets filled at a lower price (advantage to the buyer).

If the newest sell order is for a price lower than was needed even, that sell order gets traded at the higher price (advantage to the seller).

That's like a farmer asking if there will be enough rain next season to cause a profitable harvest.

It is true that once ASICs ship in volume, they'll end up being responsible for a huge percent of the hashing capacity (90% to 98% even).    And thus those who start mining with ASICs first will be incredibly much more profitable than those who don't receive ASICs until hashing capacity has already reached the stratosphere.

That doesn't mean an ASIC can't still be "profitable" (e.g., revenues minus expenses and amortization of the hardware over a year or two) but the later ones won't see the one-month to break-even that was at one time looking possible.   

The problem is, no manufacturers are shipping today, and there's know knowing what place in line you end up at when you do have an order in with a manufacturer that starts shipping.

And don't overlook the possibility that the first version of hardware will get absolutely trounced (either with higher performance or lower price) by version two.

So just know, buying an ASIC is taking a gamble on one manufacturer over another, a gamble on how much capacity in total from all manufacturers will be delivered, and the future exchange rate.

Between August and November, 2011 those 20 coins were worth between $60 and $250.    I'ld think someone going through this degree of effort (two posts on Reddit, three threads here including this one) for the money now would have given at least two shits about the coins back then as well.

Anyway, there might be people willing to help do the sleuthing with you, but I suspect offering a bounty would help you get faster results.  Here's a recent incident in which this type of assistance was rendered: