If you state the conclusion at a high enough level of generality then everyone can agree. Yes, all other things being equal, let's prefer a solution that releases less CO2 to one that releases more. But, of course, that's not where the issue is. The issue is how much pain and sacrifice is justified to reduce CO2 by some particular amount and who will suffer the pain and make the sacrifice.

What's funny to me is that the very same people who are arguing for massive changes to reduce CO2 output are vehemently opposed to any other form of climate engineering. They're arguing for the biggest such attempt of them all, with massive, certain affects on human existence.

Yeah, see there's the problem. Let's take, for example, global warming and let's assume that AGW isn't established. (The argument works the same for other things such as GMO and climate engineering, but I'll use AGW.)

Does the cautionary principle work this way: "We're not sure humans are responsible for global warming. But trying to restrict our CO2 output will definitely harm our economy and likely cause a reduction in our ability to produce food. It will raise the cost of energy, causing some people to freeze to death. The cautionary principle says we shouldn't restrict CO2 output."

Or does it work this way: "We're not sure humans are responsible for global warming. But they might be. The cautionary principle says we had better reduce our CO2 output so that we don't risk causing massive damage to our planet."

What happens is that people always raise these arguments to support the conclusions they've accepted for other reasons. Nobody is actually swayed by them. They're basically window dressing. These are issues where both sides claim great impact and claim that the cautionary principle and the lack of complete knowledge justifies the conclusion they wanted in the first place for completely different, and unrelated reasons.

You have to address the real reasons people reach the conclusions they reach. If the evidence is not strong enough to compel either conclusion, people will generally argue for the conclusion that benefits them. And then it's not a scientific argument, it's over who wins and who loses.

I'm saying that that argument won't persuade anyone because people always make it when it supports their position and always ignore it when it doesn't. The people who make that argument about global climate change don't accept it themselves about GMO or climate engineering. So why should anyone accept it when they make it about global climate change?

The people arguing that this applies to climate change never seem to be willing to apply it to things like genetically-modified organisms or intentional attempts to engineer the global climate.

Yes, if the pool isn't empty. But if you've never sent any bitcoins, the pool will be empty. (The client creates 100 *extra* keys when it creates a key for a transaction.) Because these rules are complicated to understand and easy to get wrong, I make my advice clear and simple -- unless you understand the rules exactly, always backup your wallet after sending.

A deterministic wallet is a wallet that generates new keys in a way that is repeatable, rather than creating random new keys. With a deterministic wallet, there is no need to back it up after sending because the new keys it would generate can always be regenerated based solely on the previous wallet.

Unless you know exactly what you're doing (or are using a deterministic wallet), you need to make a new backup of your wallet after every time you send bitcoins. Otherwise, you may not have the private keys necessary to claim the change from your previous transactions.

Unfortunately, I've been completely swamped with work lately, and I haven't had a chance to look at it yet.

Currently, the chain is not so big that anyone has implemented any pruning. Pruning is a bit tricky to do correctly.

Then clients can start using pruning. But disk space is growing much faster than the hash chain, so this may never be an issue.

Probably people will cut over to clients that don't keep the entire block chain but instead keep only their own transactions.

That's correct. You remove the entire chain and all you keep is the hash and a table of all Bitcoins that are still spendable. You throw everything else away.

All you need is the transaction IDs and output offsets of any outputs that are still spendable. You can throw everything else away.

Well, you have to keep track of all coins that are spendable. Other transactions can be thrown away.

In principle, all that remains is a single hash. But that hash is sufficient to reconstruct the one and only state of all current transactions.

How could he? One of two things would have to be the case for the transactions to be accepted:

1) They'd have to claim spendable transaction outputs that this node still knows. In which case, in what sense are the transactions "fake"?

2) They'd have to claim spendable transaction outputs that could be proven valid based on the hash the node still knows. In this case, the attacker either needs to find a hash collision (in which case, everything is screwed) or the transaction must claim valid outputs.

They cannot be injected because they do not claim transaction outputs that any node would consider valid by any method.

They either keep track of all spendable transaction outputs or they require verifiable proof that there exists a spendable transaction output that they don't know of -- validating by hashes and signatures traceable back to data they know is valid.

They're still valid. Their outputs are still spendable.

The client would store its balance, along with the identities of any transaction outputs it could spend.

Nothing disappears. The cut is just to save memory and disk space. The semantics remain precisely the same. The difference is that everyone can forget about transactions with no spendable outputs and they can forget about blocks prior to a checkpoint.

If the pruned away part of the blockchain is replaced with just a hash, replacing that part of the blockchain will go from difficult to impossible. The client could not possibly accept a different view of those blocks because it would have no way to undo their transactions and replace them with transactions in different blocks. A client can only reorganize the block chain for blocks it has. Any pruning of the block chain would only be possible for blocks that had been permanently locked in.

Pruning a block means forever accepting the version of that block you pruned. Without the old contents of that block, there's no way you can replace them with new contents.

I don't think it would be rational for a country to start a cryptocurrency based on Bitcoin technology. The basic ideas of accounts, transactions, and confirmations make sense. But where the lack of a central authority is not an advantage, there's no reason to make all the compromises bitcoin makes to get that.

Doesn't this code access mapBlockIndex without holding the cs_main lock? If that's legal, what protects mapBlockIndex? If that's illegal, isn't the patch broken? (If this question is obsolete because there's a newer version of the patch, where can I find it?)

For today's GPUs, decision-intensive code works well too. Mixing functions like:

k ^= (j&1) ? m : n;
m ^= (j&2) ? k ? n;
n ^= (j&4) ? m ? k;

That's actually not the only reason. Part of it is that there is no competition for varying corporate structures. Pretty much the only way you can form a company is with complete financial immunity for stakeholders and decisionmakers and wherein the decisions are made by investors who can dump the stock any time they feel like it. This is likely not anywhere close to the best corporate structure.

The reason we reject the idea that the workers should own the means of production is that they are free to buy them if they wish. But it would be the unusual coincidence where the best investment most workers could find would be the very same tools they needed to work with. Different investments have different risk/reward profiles and a worker's outlook would match his financial needs only by total coincidence. Yet we have compelled precisely the same flaw in our corporate structures. Votes represent both shares in the profits and shares in the decision making. Shares are dumpable at a moment's notice By law, we have inexorably tied them together.

http://davids.webmaster.com/~davids/bitcoin-4diff-5beta.txt

This is a "first working version". It patches cleanly, compiles, and passes my basic functional tests.

Quite a few of my optimizations were already made. Yay!

I guess I'll have to start working on some new ones.

If Bitcoin dies out, we will learn from the experience and replace it with something superior and the world will be a better place for it. Fall in love with the concept, not the implementation.

They won't be able to get their money immediately, but a bank can easily prevent a bank run from being particularly disastrous. What they have to do is explain in advance what their bank run policy is and have sufficient assets of some kind (which can be loans) to cover the run in the long term.

For example, if the prevailing interest rate is 4%, they can have an "emergency run interest" of 9%. If there's a run on the bank, they declare an emergency and cover withdrawals with 9%, fixed-term notes. Sure, some people won't be too happy to have these notes instead of bitcoins, but their value will likely be a bit higher then the corresponding number of bitcoins, so they could likely sell them for a slight gain.

This assumes the bank isn't in danger of going out of business. This means the loans (or other bank assets) must still be sound. This can only cover a short-term liquidity run problem, not a long-term solvency crisis. (It wouldn't have helped with the bank failures we saw recently.)

However, a bank can easily cover a bank run with non-cash assets. This is another way commodities can be used to inflate the money supply. You might not trust a bank to keep only a 10% bitcoin reserve, but if they had a billion dollars worth of gold or also owned many stable businesses, you probably would. So a bank can leverage any other asset to allow them to put more bitcoins into circulation than they could otherwise.

Fractional reserve banking is debt. My $100 checking account balance is the bank's debt. If a checking account balance is part of the money supply, then debt can be part of the money supply.

Your dollar bill is debt. It is an obligation of the United States. If a dollar bill is part of the money supply, then debt can be part of the money supply.

Whether or not debt actually *will* be part of the money supply depends on a lot of factors. The primary one is whether or not it makes economic sense for it to be. In a hypothetical economy with a currency shortage, there will be a demand for currency, and debt will meet that demand.

If that were true, then no fiat currency would be part of the money supply, inlcuding dollar bills. Fiat currency notes are debt -- most of the money supply for most of the world's nations are notes that represent sovereign debt. See, for example, 12 USC 411. http://www.law.cornell.edu/uscode/12/411.html

This is a reasonable definition of money supply. The fact that the block chain can never contain more than 21 million bitcoins puts no limit whatsoever on how many can be in circulation (just as a bearer bond can circulate the same way dollar bills do) or in demand deposits. The reason you don't see equivalents in circulation with dollars is because of a combination of legal restrictions and the lack of any need for them.