A closed source client is a bad idea.

But this is why users should prefer an open source client. It's not the software developer's job to decide this for the end user.

Thank you Satoshi for sneaking that possessive apostrophe into "computer's date"!

When you say an account is inactive, you just mean that it hasn't been funded for BTC1, correct?

Or do you mean that there is some requirement to stay active by doing something like referring or visiting the site regularly?

MtGox does seem to be working very well. I see they are listing over BTC 27000 as "asks". Therefore MtGox holds over 0.72% of all BTC generated so far, which is pretty impressive. At BTC1=$0.065 that's a nominal value of $1761 held by MtGox in bitcoins.

Actually the figure must be even higher, because the list doesn't show "asks" over $0.10, and I know there are some of those.

There must also be quite a sum held as dollars, of the order of $600 according to my very rough calculations. Maybe there's a possibility to pay the running costs of the site by earning some interest from this money?

Now might be a good time for MtGox to answer some of these questions:

1. What happens if PayPal reverses some payments in or payments out?
2. What happens if the operator of MtGox dies (or is kidnapped or imprisoned or whatever)?
3. What happens if someone hacks the website and finds a way to send themselves everyone's BTC balances?

Of course there is risk everywhere in life, and I don't imagine that it can be eliminated, but I would like to understand where the main risks lie.

The FSF acknowledges that the MIT license is compatible with the GPL. You can fork an MIT project into a GPL project if you like, after which your GPL fork is copyleft.

So the use of the MIT license shouldn't be an issue here.

I think you might find that offering a bribe would be the surest way to prevent the article from being re-included.

I don't think it's worth sweating over the Wikipedia deletion.

Just leave it a month or two until there is some good third-party coverage then try again. The article should stick then.

A full client should be doable without a fork on Nokia's N900 Maemo phone. Maemo Linux supports fairly standard development in C, C++ or Python. I guess the crypto libraries are available because ssh runs on the phone. Most Linux libraries can easily be recompiled for the N900's ARM architecture. The phone has root access "out of the box" and there's no restriction on multitasking or background processes.

The only sticking point would be the GUI library. The N900 comes with GTK+ installed, and QT is optional. But I seem to recall that the Bitcoin client uses some other library, which would need to be recompiled for ARM and made a dependency of the Bitcoin client. No big deal for a developer who is familiar with this stuff (which is not me, unfortunately).

Tell that to people who have gold fillings in their teeth! And professional flautists who feel that a gold flute mouthpiece makes the best sound.

Also, your cellphone contains about $0.40 worth of gold.

Every computer needs gold for some of its internal connections, so in a way every bitcoin minted depends on gold. Is that ironic or what?

[not that it affects the economic arguments being made in this topic; I just didn't want to leave the error about gold not being needed in everyday life uncorrected]

Returning to satoshi's outline scheme:


The buyer can't benefit by failing to pay, that's true, but it's also true that the buyer has no incentive to "get around to" releasing the payment.

Suppose you send a laptop to a buyer. The buyer receives the laptop and forgets to release the payment, so you have to chase them up. Or the buyer says "yeah I got the laptop, but I need to check that it works OK before I release the payment". Then later they say "I'll release the payment if the laptop is still OK at the end of the guarantee period".

The seller is pretty-much powerless in this case, and the buyer has no reason to want to release the payment, other than their repuation. But if we're successfully tracking reputation, then why not cut the escrow out of this situation?

@epaulson: you can take some comfort from the experience of the open source software world.

There have been forks of high profile projects. Lucid Emacs broke away from GNU Emacs, for example. They had good reason to do so, because GNU Emacs had become rather moribund. The fork was perhaps what prodded the GNU Emacs team back into action, and there was a happy ending because the forks later merged. If that fork hadn't happened, GNU Emacs would have been in a weaker position today.

Much the same happened with the GCC compiler. It had become rather moribund, and the EGCS team forked it. (EGCS stood for Extended Gnu Compiler Suite or something like that). The fork prodded the GCC team back into action, and there was a happy ending because the forks later merged. If that fork hadn't happened, GCC would have been in a weaker position today.

Modern projects like Firefox get forked all the time. Some forks are experimental, some are due to a difference in philosophy, some are failed attempts to "get something for nothing". Some of the forks die out, some of them get merged back into the mainstream, and some (like IceWeasel) happily co-exist in a symbiotic relationship. The possibility to fork doesn't hurt Firefox.

So what if someone wants to fork Bitcoin? All that really matters is that those who don't want to fork can continue to use the unforked version.

Of course there will be disagreements in the future, but they're not going to be helped by any kind of legal framework. As kiba says, everyone except the lawyers would lose from that.

I expect that as long as Satoshi is around, the version that he blesses will remain dominant. Human nature is like that.

Yes that assumption is correct. Both parties have a financial incentive to complete the transaction successfully. Forfeited escrowed coins could be burned, or could be used to fund the operation of the escrow service.

But yes, the ability to put your opposition out of business in a leveraged way makes the system unusable as I described it.

Let's see if this tweak works:

1. A offers to sell laptop for 2000 coins, and escrows 2500 coins as security.
2. B offers to buy and escrows 2500 coins as security.
3. B pays 2000 coins to A.
4. If A refuses to send the laptop, both A and B have lost 2500 coins. Therefore, A has an
     incentive to send the laptop, and B can't use this system to put A out of business.
5. A sends the laptop to B.
6. If B refuses to acknowledge receipt of the laptop, both A and B have lost 2500 coins.
     Therefore, B has an incentive to acknowledge receipt of the laptop.

How about this:

A offers to sell laptop for 2000 bitcoins, and escrows 2500 bitcoins as security
B offers to buy and escrows 2500 bitcoins
A confirms that item is sent but never sends it
B never receives it so never release the bitcoins
A now cares because he has 2500 bitcoins in escrow as security

In this scenario, it's in A's interest to send the laptop, otherwise he loses his BTC 2500 security. It's also in B's interest to confirm receipt of the laptop, otherwise he loses his BTC 500 "excess".

The awkward situations are going to arise if both A and B are honest, but an uninsured delivery service loses or breaks the laptop, or if one of the participants dies before releasing the escrow.

Well it seems I'm the only one who has bought a pixel block, as the only image at BitPixel is mine. At this rate, it's going to take a long time to get to BTC 100,000.

On a positive note, the process of purchasing the pixels and uploading my graphic went smoothly, and the ad appeared as promised.

Surely the "ultimate bitcoin generator" will inevitably be a dedicated chip? That's always going to beat a general-purpose opcode-driven CPU. Of course, dedicated silicon is expensive to develop...

Thank you! So far, so good.

I'll pledge my first hundred bitcoins to anyone who can post a 32-bit Fedora version. I'd pledge more, except I don't know how many I'll be able to generate. Perhaps other 32-bit Fedora users can add their pledges to mine.

Thanks for the link to that binary.

Unfortunately it doesn't work for me. The bash shell gives a "cannot execute binary file" error.

I guess bitcoin-r102 is a 64-bit binary, and I'm running 32-bit Fedora.

I am having the same problem on Fedora 12 32-bit, which also uses libcrypto.so.1.0.0a.

As chupacabra says, a symlink doesn't help because the different library versions contain different symbols.