Well, if polls matter, this was already voted on two years ago:


And the winner is ....

"millibit":
 - http://en.bitcoin.it/wiki/MilliBit

FFS, people.   Stop using exchanges tied to the banking system [Edit: directly] with services that will likely get you in trouble.  

You can use a throwaway wallet somewhere in the middle as one approach.

You can use a mixing service, such as shared deposits with Blockchain.info/wallet, for example.

Yankee, by providing support in a dozen threads what that does is encourage more support requests in those threads or gives incentive for more threads to be created.

Perhaps for each and every instance of support requested outside the BitInstant support thread the best response would be to direct the person to post (or re-post) their inquiry in the BitInstant support thread.  Having fewer points of contact (i.e, not spread out here, there and everywhere) provides a better level of service to them.

travelmonkey12, if you weren't aware:

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

A 51% attack would likely be performed so as to double spend against an exchange,

e.g., attain a significant amount of hashing power for solo mining but don't release solved blocks, start DDoS against pools, spend LTC to exchanges and spend same LTC to a locally controlled address broadcast only to self-mined blocks.  When the LTCs reach an exchange, sell them and withdraw bitcoins.  Then release the secret blockchain which is now longer than DDoS'd side has reached, which will then invalidate the LTC payments to the exchanges but that doesn't impact the BTC withdrawal.

This only makes sense though if there will still be value to the LTCs the attacker received after the double spend.   An attack like this might render those LTCs essentially worthless.

Either way, any exchange that converts between crypto currencies and then honors withdrawal requests when pools in either currency are being DDoS'd would be essentially inviting such an attack to be attempted (and thus putting customer's funds at risk).

Contact the seller.  If it doesn't even show in Blockchain.info, then it wasn't sent.

They have an account-to-account (A2A) transfer method?

Some transactions will confirm right away without a fee.  Others will take longer even with a fee due to other properties (e.g., having INPUTs who themselves have not yet confirmed).

This is going to become an increasingly important area to manage for those who accept on 0/unconfirmed (e.g., retail merchants).

Imagine paying at the counter and then being told your payment had no fee and thus you need to wait (hours maybe) to receive the merchandise you paid for.  There's no way to cancel the payment, which makes it even worse.

I keep flip flopping on whether or not bitcoin can work for merchant payments.

If the retailer can make it economically unprofitable to try to double spend then there won't be a problem.  i.e., if the attacker/thief has to buy 19 hamburgers before the 20th is "free" from a successful double spend, then an attacker probably isn't going to try.  But the merchant isn't looking to figure out a way bitcoin will work, the merchant is looking only to sell hamburgers, and if a payment network gives hassle and risk it is not likely to be embraced.

Now that FinCEN has stated that merchants can accept bitcoins for goods and services without having to register as MSBs, there will probably be some new approaches coming (including intermediaries, likely).

Since they give the quote for whatever pairs you pick, the USD/BTC shows a 0.00779 BTC per dollar.   I guess I just haven't seen that pair order in a while and it shocked me a little.

I'm a little late on verifying 2.4, but here it is:

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.4 (1d5951f6a04dd5a287ac925da4e626870ee58d60) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
1d5951f6a04dd5a287ac925da4e626870ee58d60  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.4"
eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb v2.4 French translations

$ git checkout eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb
$ git rev-list --max-count=1 HEAD
eeed4db91edd9eda5eb4277a61aa16ad80bdcdcb

$ sha1sum bitaddress.org.html
1d5951f6a04dd5a287ac925da4e626870ee58d60  bitaddress.org.html

You can check with blockchain.info to see any transactions that were sent.  If they appear in Blockchain.info, and they are for addresses in your wallet, then you should see them in your wallet as well. 

If they don't show on blockchain.info, then they weren't sent and the problem isn't on your side (receiving end) but instead on the other side (sending end).

The Bitcoin.it wiki uses a bitcoin validation method (send bitcoin to the address for your username) to protect against spammers:

If you didn't want to sign up there, I've added your service:

 -  http://en.bitcoin.it/wiki/Trade#Cloud_Providers_and_Services

This Bitcoin.it wiki isn't just used for Bitcoin (the software), it is use for and by much of the Bitcoin ecosystem.  That includes third party services, tangentially related projects, and more.

Though the wiki has admins, the admins are frequently going to be less knowledgeable or interested in each particular article's subject.  

Let's take the Tonal bitcoin article.  That's Luke's baby.  He knows more about it, is the most motivated to maintain it, etc.    Therefore, I as an admin generally am going to defer to the domain-specific champion for that article.   If that person feels there is trolling and wants to clean it up I don't want some "wiki governance policy" telling me that removal is prohibited and that I as admin can't just let Luke deal with it.    If he thinks gibberish should be purged on that discussion page for that specific topic, then I'll support Luke with that decision.   Either way, it is inert -- nobody is harmed or misled by the content on the Tonal bitcoin article so I as admin am comfortable letting that be with no intervention as an admin.

Now for topics which are directly related to the Bitcoin-Qt/bitcoin client, Bitcoin protocol or other Bitcoin-project specific areas then having some rules could become necessary, I suppose.  The odd thing is, for those there's almost never been edit wars, incessant trolling, ego trips, etc.    So that's why even without governance there's never been much of a need for administrator intervention with those.

There are a lot of new users arriving, downloading the blockchain.  That puts additional traffic on each peer, especially if [edit: and only if] it is configured to accept incoming connections.

BitInstant sends USDs not Bitcoins.  

I'm guessing you are hoping to take bitcoins from BTC-E and sell them at Mt. Gox where the exchange rate is higher, and then I'm guessing you don't want to wait for the six confirmations that the transfer will take.

This is a common trade, and is easy.  You simply want to sell your coins over-the-counter to someone who will pay you a MTGOX USD redeemable code.

The problem with that is you would be asked to send first and you would only want to transact in this manner with someone who can be trusted. The #Bitcoin-otc marketplace provides a Web of Trust (WoT) which gives a trust history so if you find a trading partner willing to offer this you can see that party's trust history.  You might be able to find a counterparty by placing an offer on the #bitcoin-otc marketplace IRC channel.

e.g.,
  SELL 10.0 BTC at "{mtgoxbid}" MTGUSD "MtGox Redeemable Code.  Adequate trust required."

If you want this trade to happen right away, offer a premium:

For example, to offer to sell with a 4% premium (e.g.,, at 96% of the spot price), you would enter the order as:
  SELL 10.0 BTC at "{mtgoxbid}*.96" MTGUSD "MtGox Redeemable Code.  Adequate trust required."

There might already be an order there from someone with MTGUSDs looking to buy your coins.

Or announce your request in the #bitcoin-otc channel, and someone will be likely be interested.

 - http://webchat.freenode.net/?channels=#bitcoin-otc-foyer
 - http://bitcoin-otc.com
 - http://bitcoin-otc.com/viewratings.php

There's a bit of a curve to getting up and running with GPG and registering with the IRC bot gribble, but the effort is worth it if you will be doing these types of trades in the future.

If your client sent the funds, no ... never, at least not automatically.

Other nodes will eventually push that transaction out of the way to make room in the memory pool for more recently received transactions.  At the same time, your client will sporadically (e.g., at least once an hour) notice that the transaction has not confirmed and will re-broadcast the transaction to its peers.  Those other nodes that have pushed the transaction out will re-learn of the transaction when it gets re-broadcast.

The factors that matter are:

 - Where are you (country)?
 - How much are you looking to by?
 - What payment methods can you use?
 - How soon do you need the bitcoins?
 - Is privacy / near-anonymity important?

Only once those are known can recommendations be made.

In the U.S., Coinbase works for many.  1% fee, though they are out of inventory frequently.  Other times there's no guarantee that your order won't get canceled.

A fairly comprehensive list of methods exist on the Bitcoin wiki:
 - http://en.bitcoin.it/wiki/Buying_bitcoins

At some point a feature that was developed might be included in a release such that if the recipient of the funds wants to help a transaction get confirmed there is a way to help nudge it -- by spending the received funds and including a fee.    That way for the miner goes for the transaction with the fee but has to include the parent transaction that hadn't confirmed.

So there's solutions, just nothing running today.

Bank wire to an exchange will be your most economical.

Mt. Gox lets you do that, though for some amount they'll want you to verify your accoutn:

BITSTAMP is another.

And there are many more:
 - http://en.bitcoin.it/wiki/Buying_bitcoins

You could try also doing a transfer from Coinbase.

You might find someone local willing to trade.

Try multiple paths, including a local buy perhaps:

 - http://www.LocalBitcoins.com

2013-04-03 Felix Salmon - The Bitcoin Bubble and the Future of Currency
https://bitcointalk.org/index.php?topic=166154.0

The problem is slippage for large payments.

Just about 24 months ago there was a flurry of suggestions for the person wanting to buy $100K of bitcoins and be able to do so without losing a ton to slippage.  Today slippage for that amount is just a fraction of a percent maybe if it gets spread out over a few hours.

So is bitcoin ready for multiple $10M transfers?   Not today.   But extrapolating the trend and that day that it could is not really all that far out there.