That data and more is populated monthly here:
 - https://docs.google.com/spreadsheet/ccc?key=0AmcTCtjBoRWUdHJuUE1mUkFxa3A0eHBDQkxZLVVFZmc

Executing the transaction (at an agreed upon price) and actually getting the settlement (proceeds delivered to you, you deliver the coins) are two separate components.  

The convenience of using an exchange like Mt. Gox is that these two essentially can occur at the same time.  I sell and then on-demand I can withdraw (as a bank wire or whatever).

If you can trust your trading counterparty(ies) then you have a much easier time finding buyers.  Most bulk sellers will allow a rate to be locked in but only if payment (e.g., bank wire) clears within a specific (and short) period of time, but even then they require a premium to be paid.

Another approach is to sell a futures contract on ICBIT.se.  For instance, at this moment the spot market rate at Mt. Gox is 44 but the April 15th 2013 futures contract on ICBIT.se can be sold at 47.  So that would be an agreement to take a selling price of 47 today but you'ld need to wait for settlement on April 15th.  Well, technically you are paid (or charged) variation margin daily with the contract settlement on April 15th.  But the point is that you can use futures contracts to lock in a price.

The problem with that approach is that there aren't 10,000 BTC of liquidity there.  But they are growing and someday that type of transaction could work.

Also, along the same lines you could write CALL contracts on MPOE (at MPEX) at a certain strike price (or buy PUT contracts).   There they do apparently offer liquidity for that size of transaction.  That comes at a cost however as the bid/ask spread is relatively very wide.

Other methods the provide liquidity are coming.   CoinSetter and Kraken are two such services that are expected to be launching soon.

Hm, that is very odd.  Maybe it is a bug.  Or maybe some issue with the data.

Blockchain.info support will probably need to have a look at the contents of the wallet to further troubleshoot, unless they know why this is occurring.

So if you wanted to you might try exporting the private keys and importing them in another empty wallet on Blockchain.info.  (So on the one you Import/Export, then export unencrypted.  Then log out and create a second new wallet where you import the private key(s) and try to spend from there.)

I'm not following.  What is it that you believe the CEO of Mt. Gox is doing?

Nailed it.

Calling it a "temp wallet" is the wrong term.  It is simply the Bitcoin address their ordering system presented to you as the customer for use when sending payment.


Then the merchant got the money (assuming Mt. Gox's service credited everything properly after the 6th confirmation).

So your BTCs should have been received by Mt. Gox and automatically credited to the merchant's account.  But ignore the blockchain.   It gives no useful information other than yes, the payment from you has received six or more confirmations.  After that, nothing matters because the address your payment went to isn't either your wallet nor is it the merchant's wallet.

Have you contacted the merchant to inquire?

Gotta give this scammer points for persistence!  I wonder when PayPal will figure out who this really is.

Update, latest incarnation:
 - bitswing.com

The e-mail address for that PayPal account: bitcoinecheck@live.com

Previous scams (in chronological order) likely by the same scammer:

 - EasZPay.com
 - MtGax.com
 - MtGix.com
 - i4Dollars.com
 - BTKoin.com
 - BitcoinTalks.com
 - VirWex.com
 - bitcoin.appee.com
 - silkroadtor.com
 - mtgox.us

Please report this scammer as badware:

 - http://www.google.com/safebrowsing/report_badware/?url=http://bitswing.com

Yup.  That's no surprise.  Here's the transaction that you say you aren't seeing:
 - http://blockchain.info/tx/72a9ec4eab8349937c326310267261553b0db1cfd6dd1e7d9b8f5668e2e881c2

In order for your node to know about a transaction the peers your node is connected to need to know about it.    So your peers must first see the transaction then they must verify the inputs, and only then will they relay it.

Now here's the problem.

That transaction uses inputs from two other transactions ... two "parents".  Neither parent transaction has confirmed.  Here's one:
 - http://blockchain.info/tx/2b7c5c019a3dbbe8c62cee9900248d010b6abaadd10401b130d1732433c3f1a2

And that transaction, ... 2b7c5c019a3dbbe8c62cee9900248d010b6abaadd10401b130d1732433c3f1a2, itself has a parent, and that parent hasn't confirmed either.  Here's that:
 - http://blockchain.info/tx/550f81600de37788b1010ea8a1cbadab24c7d2c25147df6b5765c0e31d5a3551

And same thing with even 550f81600de37788b1010ea8a1cbadab24c7d2c25147df6b5765c0e31d5a3551's parent:
 - http://blockchain.info/tx/06585f02e5992bd7fdf28f69b1d3f6f91a5a6969c79061ec67c29c17c7f5a1f5

Shall we keep going?  We must ... so that 06585f02e5992bd7fdf28f69b1d3f6f91a5a6969c79061ec67c29c17c7f5a1f5's parent:
 - http://blockchain.info/tx/cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a

Which brings us to cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a's parent ... still not confirmed:
 - http://blockchain.info/tx/f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9

And finally f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9's parent does actually have confirmations:
 - http://blockchain.info/tx/921e5b5dda9d2b3a0f9844442af180590a3b8576985205be6117ab24b072d602

So what is likely happening is the nodes are refusing to relay this transaction (plausible) or more likely the peer node's memory pool is only so big and not all these spam-like transactions are saved long enough and thus your transaction is invalid (the parent transactions can't be found when searching the memory pool).

The solution is to stop doing this crap.  (i.e.,As a commercial provider, don't send out a payment unless the funds you are using for the payment themselves have many, many confirmations.  Your customers deserve better than that.)

Bitcoin is not good for microtransactions.    I know that revelation ruins the business plans of all these "free bitcoin" sites but them's the breaks.  Nobody is going to tell them that no, they can't do this.  But the Bitcoin-Qt/bitcoind client was designed to be resilient against attack and this looks more like an attack than legitimate value transfers.

What the mining pools (or freebie coin service, or whatever it is) can do is maintain a wallet for each user and then when some payout threshold is reached (e.g., a nickel's worth of bitcoins) then and only then is the payout sent through the blockchain.

Now the resolution for this is, ... if the node which first broadcast the "top" spend transaction (f44a37fa096958d0b41f0109b152a626384832f9011b6e3baf77fbd096b462a9) then continuously re-broadcasts that (which is the default, at least once an hour if it has not seen a confirmation), then eventually a miner will take that transaction and it confirms.  It may take a day or so.   Then the next transaction in the sequence (cb52fd82a3916f3004f7d329250d462b74ed34e67371121ce0bb1b68d0cf188a) would get re-broadcast and mined ... that's another day or so.  Then repeat for each in the sequence.  So it is possible your client won't see that transaction for nearly a whole week.      

With Bitcoin-Qt/bitcoind v0.8 you can do an importprivkey and rescan=true on the last one to import and it will rescan.  With versions prior to v0.8 it did a rescan after each import, or you could (and still can) force a rescan when launching the program.

listreceivedbyaddress will give all the addresses in which you've received funds.

There are a lot of services, especially online casinos, which provide hosted (shared) wallet accounts, so not every single one has been added to the wiki:

 - http://en.bitcoin.it/wiki/Category:EWallets

Yup.


The client still uses BDB for the wallet.dat.   The previous versions would bog down after the wallet held several thousand addresses, but I'm not sure if the move to LevelDB for the blockchain in v0.8 made that problem go away (at least to where the sluggishness wouldn't reappear even after a level much much higher number of addresses).


To your node, yes -- sluggishness.   To the Bitcoin network?  Nope.


Maths and keyspace.   i.e., There's no reason to worry about it ever happening.
 - http://bitcointalk.org/index.php?topic=104461.msg1143851#msg1143851

They had a half-week outage following a security breach and then a burst of activity, so it is reasonable to conclude they are backlogged.  They are not likely scanning the forums for new threads, so you might have better luck putting your inquiry in the thread that they do monitor:

Official BitInstant Support Thread (Active Customer Support)
 - http://bitcointalk.org/index.php?topic=128314.0

I do see reports there of people getting their service inquiry addressed.

Description:


 - http://en.bitcoin.it/wiki/Private_key#Base_58_Wallet_Import_format

and related:

 - http://en.bitcoin.it/wiki/User:Casascius/Base58Check-encoded_objects_proposal#Proposal_to_standardize_the_Sipa-format_key

Er, scratch that.  Now that Bitcoin-Qt has debug mode (v0.7 and higher) the best method is to use that to export your private keys, and then import them elsewhere, either into a newly created, clean and empty wallet or to import them into another client, such as Blockchain.info/wallet.


[Edit: To export your keys:


You can do listreceivedbyaddress in the debug window, then for each address:

dumpprivkey [address]

Here, now you can know about as much of them as I do:

- http://www.thebitcointrader.com/2013/01/finally-bitcoinica-replacement.html

and
 - http://twitter.com/CoinSetter





 -

You might be misunderstanding how hosted (shared) EWallets function.   When you are given a Bitcoin address for depositing to your Mt. Gox's account, that address is not your own address, it it simply an address in Mt. Gox's wallet and any payments received to that address are added to your Mt. Gox exchange account.  So looking at the blockchain will help you verify that your payment was sent, but it cannot be used to determine what happens to those funds from that point on.  Mt. Gox will credit the appropriate account when the transaction reaches six confirmations and that's the end of it are far as what you can determine by monitoring the blockchain.


So if you are the customer, then only the merchant will see the payment confirm.  If you sent the payment and that transaction has six or more confirmations, then the merchant should have gotten notification that payment was completed.   Are you saying the the transaction has confirmed and the merchant is still waiting on your payment?

Ya, but they monitor that thread and probably are unaware of this one.  So if your problem is not yet resolved and you haven't done so already consider posting your inquiry there:

Official BitInstant Support Thread (Active Customer Support)
 - http://bitcointalk.org/index.php?topic=128314.0

More than once I've found sitting in my spam folder the response I'ld been so eagerly awaiting.  Perhaps that is what happened here.

You might want to send a PM to Yankee asking for a resolution.
 - http://bitcointalk.org/index.php?action=profile;u=21181

This is one of those online games which probably can be rendered well on a mobile (e.g., versus blackjack in which by the time your UI design accommodates splits and stuff a mobile's small size display just isn't sufficient),

You should consider making this more usable from a mobile.

I'm not sure I'm following but let me answer the question I think you are asking.

When you use blockchain.info/wallet, you never need to touch private keys yourself.   When you want to receive money it will give you a bitcoin address to use each time you click "New Address".   That address will have a private key and can be used for spending.

It is possible to make an existing Bitcoin address into a "watching only" address by going into the Advanced mode and then delete the private key.  Or you could simply take any Bitcoin address from anywhere and add it as a watching only address.  

So in working with a "watching only" address you are going above and beyond the basic functionality provided by Blockchain.info/wallet.  With that comes the necessity to understand  when a private key is needed and it appears that is about where your question lies, so it is good that you are asking this question.

When you have a "watching only" address,  you cannot spend any funds received to that address unless you have access to the corresponding private key.

So I am thinking that your question is this:

  If a watching only address is added now, can that address be used to request payment from others even though it says "watching only?"  

The answer to that is yes, as long as you have the private key for it somewhere and that key is kept secure.

The Blockchain.info/wallet can later import private keys.  If you add a private key it will look to see if the address already exists.  If it does and it is a "watching only" Bitcoin address then Blockchain.info/wallet will simply change the mode for that address so that it is no longer a "watching only" address and store the private key with it.  You can then use any funds received to that address for spending.    

So as long as you have a private key for a Bitcoin address you can always spend any funds received to that address.  The private key is only needed at the time you plan to spend funds at that address.  The private key does not necessarily need to be in the Blockchain.info/wallet at the time a payment is received to that "watching only" Bitcoin address.

You can see all the Bicoin address/private key pairs in your Blockchain.info/wallet by clickiing on Import/Export then Paper Wallet.  

For any private key, you can use a tool to have it compute the corresponding Bitcoin address.  BrainWallet.org generator can do this:
 - http://brainwallet.org/#generator  <--  Paste your private key, it will show the Bitcoin address.

So if you are seeing a problem reported with a certain address -- firstly a mismatch between private key and Bitcon address shouldn't happen, but just to know a bit more where your problem lies, perhaps check the private key on BrainWallet and ensure that it does indeed provide a Bitcoin address that matches the one shown on the Paper Wallet view.