The supply is the same. The demand is the same. Why should the price change?

I see how you can have one or the other of these properties, but I don't see how you can have both.

In order to rig it so that nether Alice nor Bob can cheat each other, the transactions must be published in the hash chain. Otherwise, Alice or Bob could simply post a conflicting transaction to the hash chain and empty the account that was supposed to be used to pay the other. But if the transactions are published in the hash chain, how can Ben not know about the bet?

Update: Ahh, I figured out a way to make it work. Alice creates four transactions:
1) A transaction to lock her money in escrow such that it can only be claimed by transactions 2, 3, or 4 - by hash.
2) A transaction to take her money back if Bob does not accept the bet.
3) A transaction to pay Bob if he wins.
4) A transaction to take her money back if she loses.

She posts '1' to the hash chain. She holds 2 and 4 for herself. She passes 3 to Bob.

Now, Ben cannot tell from just seeing 1 what it means, since the transactions that involve him (3 and 4) are not posted yet. Bob, if he wins, can post transaction 3 himself to claim his winnings.

In that case, how do you solve the factory owner blackmail problem? I can buy land near a multi-million dollar factory and use my land in a way that creates arbitrarily high damages. Say, for example, the pollution is highly toxic to bees. I can bring in the world's most valuable and sensitive bees, wait for them to die, and then make him pay my full cost. I can keep doing this until he pays me millions to stop, or he shuts down his factory.

My objection applies to any scheme were polluters pay for all the damages, whether the payments are imposed by taxes or otherwise. While the pollution is the fault of the polluter, the damage the pollution does is the fault of the relationship between the pollution and the thing damaged. That is not something entirely under the polluter's control.

You can store only the private key. I think a checksum is a pretty good idea. If the checksum doesn't match, you can easily search 'around' the checksum to make it match, checking all single-word replacements that pass the checksum against the block chain to see if they match any public key that appears there.

It seems pretty simple to do this with no third party verifier:

1) To place a bet, you place a transaction that can be claimed either:
 A) By you, up to a certain time in the near future.
 B) By the person you're placing the bit with, after a certain date just before the event.
 C) By you, at any time well after the event. (1 day, say)

2) To accept the bet, your partner places a transaction that can be claimed either:
 A) By him, any time after a time just before the event.
 B) By you, at a time well after the event. (1 day, say)

3) If he doesn't accept the bet, you claim back your money per 1A. Make sure to take back your bet if it's not accepted. If you take back your bet after the bookie places his, he takes back his bet using 2A (he'll have to wait a bit).

4) If you win, you claim both transactions using 1C and 2B, a bit after the event.

5) If you lose, he claims both transactions using 1B and 2A as soon as he knows you lost.

Yes, your bookie can cheat you. But that's much less of a problem than trusting a central authority.

There are a fairly large supply of idiots in the world, but the number of them that are capable of transferring BitCoins is not so large. As soon as you run out of idiots with BitCoins, the game will end.

For every N BitCoins deposited, the pyramid must pay out M BitCoins, where M is bigger than N. So with every deposit, the scheme falls further and further into debt. The longer the game runs and the more deposits it gets, the greater the total loss will be.

They add pronouncability and case-insensitivity. Base58 is designed for machine consumption, RFC1751 is designed for human consumption.

This isn't intended for OCR. There are better solutions for OCR. This is intended strictly for human use. I don't see how a human could lose a space. Humans do not think "therapist" is in any way similar to "the rapist".

In any event, the coding scheme doesn't have to be RFC1751. That's just nice, IMO, because it's a standard. But if people would prefer a BitCoin-specific method, maybe one that was more language neutral or added error correction and not just error detection, that's perfectly fine with me.

If you want to argue that miners should hold their coins because they'll be worth more in the future, that's fine. But if you want to argue that miners should hold their coins so that they'll be worth more in the future, see my reply. You did say: "the more people that hold long the faster the true value will surface" In fact, I think that's completely false. The higher the volume, the faster the true value will surface.

How do you figure? In an inflationary system, interest rates are higher.

I came up with a few more use cases. Mailing BitCoins to someone on paper, communicating them to someone over the phone, and creating BitCoin 'cards' with a scratch-off code that would allow you to add them directly to your wallet.

Hahaha. No.

Whether the currency is deflationary or not, 1 BTC today is always worth more than 1 BTC in a month. Because with 1 BTC today, you can have 1 BTC in a month or you can spend before that. So it has, today, whatever the value of 1 BTC in a month is expected to be plus whatever value there is in being able to spend it before that.

A currency cannot predictably deflate. It's like saying "gold is $1,000/oz today, but we all know it will be $5,000/oz in a year". That's impossible. People who didn't need money immediately would buy up all the gold until its price came very close to $5,000/oz now. Any *predictable* deflation will have already happened and its expected present value will already be bundled into the present cost.

1 BTC today includes the right to sit and hold that bitcoin and watch it appreciate in value. You can, of course, exercise that right by holding it. But you can also sell it to someone else for whatever the fair market value of that right is.

The reason BitCoins have been going up is not because of the deflation built into them but because they have been increasing in popularity, thus increasing the probability they will ever actually experience the deflation built into them.

Would you rather have 1 BTC today or 1 BTC tomorrow? Of course, you'd rather have one today. Because with one today, you can either spend one today or have one tomorrow. So if a bank wants 1 BTC from me today, it had better give me more than 1 BTC tomorrow. Otherwise, I'm giving up my opportunity to spend 1 BTC today for nothing. That's wasted value.

There are so many false premises involved in this argument that I have no idea where to start.

GPU are massively parallel and are extremely good at solving computation that don't require moving large amounts of information or making large numbers of decisions. CPUs are somewhat parallel and are extremely good at solving computations that require moving large amount of information and making large numbers of decisions. Hashing, as it happens, doesn't require moving large amounts of information and doesn't require making large number of decisions. So GPUs win.

A GPU is like a CPU with 1,000 very limited cores.

I have an idea for a feature that could easily be added to the client. It would provide a simple way to backup private keys to paper. The basic idea is to add two RPC commands to the client -- an export command, and an import command. They would work as follows:

The 'export' command would take a BitCoin address whose private key was known to the client and export it in RFC1751 form. This includes a checksum, is case-insensitive, and is very easy for a human being to write down or read out loud. It will typically look like this:
BOGY CURE TIDE HIS DUNK GOOD FEUD GIBE FOUL FROM JOE NEST ADA SMUG FLAT MAKE MALI FAKE WINO ARK LAIN WERE TAN OVA

The 'import' command would take a private key in RFC1751 form and import it into the wallet, returning the BitCoin address and balance as well.

In the non-GUI case, you could use the existing 'listreceivedbyaddress' command to get keys to export. In the GUI case, we could include a way to get the exported keys for all addresses with non-zero balances in a form that could easily be printed. And, of course, a command to enter in a key and add it to the wallet.

This way, people can write their BitCoin private keys on a piece of paper (or print it), lock it in vault, or whatever. The idea is not to serve as a normal wallet backup for an active account. The idea is to serve as a long-term backup for balances that people do not expect to be using for an extended period of time. The biggest argument against it that I see is that it's too much effort for too narrow a use case.

Trivial. Proving you have a particular secret key without comprising it is pretty much trivial.

The auditor presents you a bitcoin address. You then compose a list of public keys and for each one, you sign an intentionally defective transaction transferring 0 BTC to the auditor's bitcoin address. You give the transactions to the auditor. The auditor confirms the signature on each transaction and sums the amount of BTC that can be claimed by each key. He then knows for sure how much you could transfer without ever compromising anything.

The client creates a new address petty much every chance it gets. This makes bitcoins less traceable.

For at least the near future, the only way to pay reliable interest on deposits in bitcoins is if you have a supply of people who wish to take a short position on bitcoins. Otherwise, the risk is unmanageable.

While this would work, it's not a particularly good algorithm to use. The problem is if you want to store it in 13 places such that any 3 are needed, figuring out what you need to store in all 13 places gets really ugly. There are a number of algorithms that allow you to easily pick any N and any M, divide something into N pieces such that any M work, where the pieces are no larger than the original input. Excellent algorithms for this purpose are Shamir's secret sharing and Vandermonde matrices.

Yes, that's quite possible.

Of course. If a CPU sucks, a CPU having to do the extra work to pretend to be something it isn't will suck much more. Now it won't be able to do the hashes the most efficient way for a CPU but will have to do them the most efficient way for a GPU, all while also having to pretend to be a GPU. YUCK!

How can you squeeze *more* power out when you're wasting most of that power just trying to pretend to be a GPU? You'll have to hash with what little is left.

Seems pretty simple:
1) Take map of private key, balance pairs.
2) Omit any pairs with a balance of zero.
3) Sort the pairs.
4) Take the SHA1 hash.
5) Append the SHA1 hash to the total of all balances expressed in any fixed-length format.

This should meet your requirements. Adding or removing zero balance pairs will not affect the calculation at step 4 (because they are eliminated in step 2) nor the total at step 5, because they have no affect on the total. So the output is the same with or without zero-balance pairs.

You can prove the amount of currency has not changed because any change in the amount of currency will require changing one of the private key / balance pairs, which will change the hash in step 4.