What is it about bitcoin that suppresses the freeloader in everyone?

It means the specific coins you use must have been in your wallet (have not moved) for a few hours. The client's logic in selecting which coins to use is a bit mysterious, and it won't always find the best combination of coins to use. It is not so much the client's fault -- it's also an issue that which coins are best depends upon what you plan to do in the future, which of course the client cannot know.

If you have a lot of small incoming transactions, you may need to do one "clean up" transaction. You can manually connect to a bitcoin client known to accept transactions with no fee, do a single "clean up" transaction, sending all your bitcoins to one address with a small fee, and then be very patient and hope the transaction gets to the client and then a miner picks up that transaction. It can take a day or so, but you should only need to do it once. Then just stop doing whatever created the mess in the first place.

Try this:
1) Create a new bitcoin address.
2) Backup your wallet.
3) Set your transaction fee very, very low (say, .005).
4) Start your bitcoin client with this on the command line:
-addnode=173.242.112.53
This connects a no-fee client run by Luke Dash Jr.
5) Create a transaction to transfer all your bitcoins to the new address you created in step 1. You may need to subtract .005 or so for the fee.
6) Go away for a few hours. If you're lucky, the transaction got into a block and all your bitcoins are now in one place. Let them sit there a few more hours and your problems should be solved.

If the transaction doesn't go through, you can revert to the saved wallet.dat file to undo the transaction.

No, you are correct. But it doesn't matter. Here "easier" means that if you dedicated every computer on the planet to breaking a key, it might take a few dozen centuries rather than a few hundred centuries. In fact, the system is so strong, even if you released the master public key, allowing an attacker to generate as many related public keys as he wanted, it would still be impossible (for practical purposes) for him to compromise a single private key. (In fact, this scheme was originally developed with the idea of using it exactly that way.)

This is the interesting thing about public key cryptography. Attacks are always possible. Every conceivable compromise is doable in principle. So you can't just check if an attack is theoretically possible, you have to ask if it is practical.

Are you 'gathering' a large number of very small transactions together? That tends to cause excessive fees. It costs about .001 BTC per source to gather coins into a transaction. So if you have a large number of transactions each around .001 BTC, it can be impossible to gather them effectively.

The solution is not to make large numbers of small transactions. It may help to let the coins sit still for a few hours.

I would recommend not stripping it unless you have some specific need to. The larger size is due to debug information that is never loaded or used when the program is running (it doesn't actually bloat memory or slow execution in any way). But without it, you cannot make sense of core dumps.

PayPal is not vulnerable to the same thing. PayPal just uses an email address as a handle to locate a PayPal account. It doesn't use an untrusted method to map email addresses to accounts.

What people really want to do, when permitted to make up their own rules, is cooperate and specialize. They will make up the rules that makes that as efficient as they possibly can because the vast majority of individuals expect to personally thrive in that type of environment. You don't need centralization or single-mindedness to ostracize people who treat their fellow men unjustly. Each person finds it in their individual self-interest to ostracize such people.

Yes. Many factors affected its value, but deflation wasn't a significant one of them.

How do you figure?

We all know ACH chargebacks between the depositor and Dwolla are possible. That wasn't the issue. The issue is whether Dwolla will pass on the chargeback to the merchant if an ACH chargeback occurs. They specifically said they would not:
http://www.dwolla.org/blog/retail-merchants-rejoice-web-kiosk-online/

And they had, and still have, no legal grounds to do so. The transfer from Dwolla to the merchant was approved by Dwolla. So they cannot claim the transfer to the merchant was unauthorized by the originator of that transfer.

Dwolla still has not claimed the right to pass on chargebacks to indirect recipients. All they have said is that they can chargeback the sender and they can claw back funds prior to arbitration. So if I put $100 in my Dwolla account and then reverse that deposit, they can deduct $100 from my Dwolla account without going to arbitration. They have never claimed the right to deduct from other people's Dwolla accounts, yet they have done so.

https://www.dwolla.com/dialogs/terms_and_conditions.aspx

This clearly says that it is about chargebacks within the account. It doesn't say anything about charging back Jack's account because Jeff issued a dispute. The last part also doesn't say they can charge back Jack because Jeff did something fraudulent.

They do expose TradeHill to precisely the same fraud. You ask for $1,000 through Dwolla. TradeHill send the $1,000 to Dwolla. Dwolla refuses to transfer the money to you claiming TradeHill has a negative balance with them because two other transactions from last month were just reversed. TradeHill cannot send a single dollar to Dwolla until Dwolla reimburses them the money they are owed and commits to no future chargebacks based on past transactions.

I think I correctly indicated that I was quoting you quoting someone. But I removed the attribution just in case it was confusing.

They're going back on what they told everyone. Apparently, they never really considered how they would handle ACH chargebacks, even weeks after they started getting them!

No question they screwed up. There is no imaginable defense for silently deleting transactions or "unconfirming" transactions with no notice other than "We screwed up, we're sorry, and we'll make it good".

Unfortunately, pretty much every company's terms of service can be summarized that way. We can do whatever we want, take your money, send you nothing, and you can't do anything about it. Your ultimate recourse is always, of course, to sue them.

Yeah. If I had noticed that you had already said exactly the same thing, I wouldn't have posted it.

As soon as the current issues between TradeHill and Dwolla are resolved, assuming Dwolla is willing to resolve them, TradeHill could resume using Dwolla for outbound transfers. But that would require Dwolla to reimburse TradeHill for all prior reversed transactions.

Sure, in a Democracy that's exactly what happens. Those who don't give a shit simply get the government to set pollution limits that allow them to pollute as much as they want and pre-empt any nuisance lawsuits. But that tool wouldn't be available to them in a Libertarian society.

That can't happen until all the issues between TradeHill and Dwolla are resolved and Dwolla agrees to cover all losses from transactions before now.

Otherwise, TradeHill could send your $1,000 to Dwolla, go to send that money to you only to have Dwolla say, "Sorry, TradeHill, you can't send money to CubedRoot because you have a negative balance." Tradehill responses, "What? We had a zero balance and then sent in $1,000." Dwolla replies, "Yeah, you had a zero balance, but then two transactions from two months ago were reversed. You now have a negative $1,500 balance.".

This type of confusion is the reason you have to separate the issue in two. There are two possible cases:

1) Global warming is not a real problem. In this case, as you say, nobody would give a shit about it because it's not going to hurt them. But there's no reason they should care.

2) Global warming is a real problem. In this case, those individuals who are really looking out for themselves would give a shit about it because it's going to hurt them.

You can't have it both ways. You can't say the problem is real but that still there's no incentive for anyone to find ways to reduce other people's impact on it.

Which proves only that the computer that made that transaction was using that MAC address at that time.

Or use a random MAC address.

Okay, I don't understand. Jack deposits money in his Dwolla account. Then Jack transfers money to me. While Jack can reverse his transfer into his Dwolla account, how can there be a "bank level return" on the transaction from Dwolla to me?

Say Jack puts $50 into his Dwolla account with 5 transactions and sends $5 to each of ten people. If one of those deposits into Jack's Dwolla account is reversed as unauthorized, what bank does a "bank level return" on any of his ten $5 sends? Since those sends came from a Dwolla account, how can they be reversed unless Dwolla says they were unauthorized by Dwolla?

As I understand it, Dwolla does not do direct customer-to-customer transactions. You always fund a Dwolla account and then send Dwolla money to someone else. Unless I'm misunderstanding how Dwolla works, this explanation is nonsensical.

Yeah. The risk is that Dwolla would keep the money against additional chargebacks. TradeHill might send your $1,000 to Dwolla only to have Dwolla claim TradeHill has a negative balance because someone else charged back a transaction from last month and so can't send you any money.

By reducing the total number of connections. Are you running the client?

Otherwise, I'm going with heat as the explanation.