Fortunately that's not the case with Flattr, and I wouldn't use Flattr if it worked that way.

You initiate a payment from PayPal to Flattr, for an amount of your choosing (say €20). Then you tell Flattr how to use that money (e.g. €2 each month). When your payment runs out, your Flattring stops unless you choose to initiate a new payment to Flattr. At no time is there any kind of automated or Flattr-initiated withdrawal from your PayPal.

Incidentally I'm Flattring €2 per month, and earning about €3 per month from Flattrs. I would love to Flattr with BTC instead if the Flattr guys would offer that option.

Yes, you put a Flattr button on each blog post, right next to the content. If people like the content, they click the "Flattr" button. It takes about the same effort as saying "Thanks".

If a person is concerned that all the Flattr payments in a given month are of an identical amount, they can use PayPal to make donations of whatever size they choose. But ask any site owner who has a "Donate" button on their site - very few people will donate. What Flattr changes is to make it so easy to donate that there's very little disincentive.

Fortunately, Flattr (and kachingle) don't work that way. At the end of each month, they look at the pages you "thanked" in the past month, and divide up your monthly payment amongst those pages (after taking their percentage).

On Flattr, I donate €2 per month. If I "thank" one page in a month, that page gets €2 (less 10%). If I "thank" a hundred pages in a month, each of them gets €0.02 (less 10%).

The "transaction cost" includes the human burden of remembering and typing a password. That seems to be enough to stop micropayments being used by most people.

The Flattr solution (pay a lump sum, which gets "used up" steadily over some months at your chosen rate, and "click freely" to allocate your donations) works really well. It's the only model I can think of that can work safely and effectively on a single click.

Yes, you will have an encrypted hard drive, but the person from whom you received a payment (and who, unknown to you, is a criminal) will have your name in his address book on his unencrypted hard drive.

I actually think that's quite a good price for the massive infrastructure that's needed for this kind of service. Compare it with, say, an App Store that takes 30%.

A Flattr-like system that uses Bitcoin would be wonderful, and I think the easiest way to get there would be to get the Flattr team on board. That way, each web page would still have only the Flattr button on it, but whether you earned PayPal or BTC would depend on what kind of funds the person who flatters you is paying with.

A Flattr-like system is only going to take off if it gains critical mass, and fragmentation will kill it. There would be no advantage to having a "Bittr" button on my webpage if only a small number of people subscribe to Bittr.

But if Flattr would take Bitcoin subscriptions too, there would be fantastic interest in both Flattr and Bitcoin. It would be a great way for newcomers to get their first few Bitcoins, by creating worthwhile web content.

Your confidence in bitcoin should not depend on whether the programming language supports "if" statements, but on whether you think more those who control 50% of the CPU power would accept bad changes in the future.

Let me give you a tangible example. If in the future the limitation of eight decimal places (for the subdivision of bitcoins) became a problem, and someone designed an acceptable way to remove that limitation, it would not be unreasonable to apply that change from a specified block number.

What I would like to see is a document that outlines the core values that can never change without it becoming something other than bitcoin. For example the absolute limit of 21 million bitcoins. There are probably only about half a dozen really core principles.

The purpose of that document would be to provide the moral authority to argue against a usurper (Facebook, say) giving their users an inferior system and saying that it is bitcoin.

I see an analogy with documents like the Debian Free Software Guidelines, the OSI's definition of Open Source, and the FSF's principles of free software. If those had not already been in place, it would have been very difficult to assert that things like Microsoft's "Shared Source" were inferior.

The video is somewhat light on content. How big are JP Morgan's upcoming settlements? By what date does JP Morgan need silver? How high does the price need to rise before JP Morgan's short-selling activities fall apart?

After all, it's not really about how many people buy silver, it's about how high the price is forced.

All one needs to say to these people is: "If it was easy, the coins would be worthless".

Unfortunately a large proportion of the population have been brought up to believe that wealth is some kind of fixed universal quantity that is "distributed", rather than something that can be created by work.

I really don't think you want to type cp /dev/null > wallet.dat in the heat of the moment.

Sorry matonis, let me bring this thread back on-topic by adding another entry to your list of ways that law enforcement will utilitze bitcoin data.

They will simply get a court order to seize someone's computer. Upon running the bitcoin client they will click "Address Book" where they will find a nicely-tabulated list of bitcoin addresses and names.

Operator takes a sizeable cut and saves it in his legal defense fund.

So doesn't that mean that reaching 21,000,000 is likely to happen early, because the blocks per hour is averaging 9 or whatever?

The rate of generation is somewhat arbitrary anyway, and whether 21 million is reached a decade or a century after I'm dead doesn't make much difference to me.

Within a couple of decades we'll be past 20 million. After that time my guess is that the rate of coin loss will be a bigger factor than the rate of coin generation.

The number of addresses is 1.5*10^48. Suppose that ten billion people are generating one address each second. Furthermore suppose I care about bitcoin during my lifetime, and the lifetime of my descendants for the next thousand years.

In that thousand years, those ten billion people will generate 3.2*10²⁰ addresses. So the chance of any given address being duplicated in the next thousand years is one in 4.7*10²⁷.

Every "chunk" of bitcoin can be spent from exactly one address*. So if I owned a billion dollars worth of bitcoins, my statistical risk (i.e. the "expected loss") would be one billion dollars divided by 4.7*10²⁷, which is about 2.1*10^-17 cents.

I can live with that.


*as Bitcoin stands now, with complex multi-signature transactions being unimplemented

Bankers are comfortable with at ATM password of length four digits. If someone finds a card in the street, that gives them a one-in-3333 chance of being able to get money from the card (because you get three tries to enter the password).

By comparison with that, atom-in-universe risks are not worth considering.

I did some rough sums for a 5870-based GPU miner. At the moment it should generate $10 worth of bitcoins per day (one block of 50 per day at $0.20).

But the difficulty rise could be expected to be about 50% every 10 days. Over the next 100 days, the income would be $100 + $66 + $44 + $30 + $20 + $13 + $9 + $6 + $4 + $1.

That's $293 or BTC 1465, which is considerably less than the cost of a Radeon 5870 card.

Of course there are many unknowns, any of which would change the outcome greatly. The price of BTC could rise or fall. The difficulty could rise faster (if GPU mining was integrated into the mainstream software), or it could rise slower (when most of those who are technically capable of using the GPU for mining are already doing so). A major event could damage power generating capacity and push up the price of electricity. A problem with the bitcoin network could put the whole system offline for a while. A massive influx of users could make transaction fees a worthwhile part of the income produced by generating, etc etc.

Surely if random coins are sent to random people, it doesn't matter if the coins of A might occasionally go to B. In fact it's more random that way.

Programming is full of probabilistic situations.

For example, the error checking/correction on your hard disk is probabilistic. A parity bit can detect a single error but not correct it. ECC coding can correct a single error and detect a double error but not correct it. The checksumming used on a hard disk can detect and correct a much larger number of errors.

But for every type of error detection correction, you can add some more errors and the algorithm will report the data as being correct. A parity bit is fooled by a double error, ECC code is fooled by a triple error, etc.

Provided your application (e.g. bitcoin) is depending on probabilities that are way more extreme than those that your hard disk is depending on, it's simply not a relevant issue, even in the black-and-white world of binary bits.

When someone dies, their next-of-kin usually goes through all the deceased's papers, but it's generally an impossible task to go through all of the deceased's online history.

Therefore, a useful option for people wanting to pass on bitcoins to their next-of-kin is to be able to print out a sheet of paper that includes three things:

- A design that looks like a valuable certificate (engraved scrolls etc), so that the paper won't be overlooked,

- The key to spend the bitcoins. Plaintext, not GPG-protected, because the next-of-kin probably won't have the GPG private key. Physical security is what's used to protect valuable papers like these.

- Some very simple instructions explaining what the code is, and how to extract its value.

There are currently 4.56 million bitcoins. Looking at the graph, it seems to be very close to the current reality.

The graph is here:
http://www.bitcoin.org/wiki/lib/exe/detail.php?id=bitcoins&media=total_bitcoins_over_time_graph.png

I'll leave it to someone else to explain how it isn't an estimate based on CPU speed.