The protocol uses integer math exclusively.  Amounts are stored as 64 bit values scaled by 1*10⁸, so 1 BTC is stored as 0x0000000005F5E100.  One Satoshi is stored as 0x0000000000000001.  21 million BTC (slightly more than there ever will be) is stored as 0x000775F05A074000.

Since 21,000,000 requires ceiling(log₂(21,000,000)) = 25 bits to store, if we upgrade the protocol to 128 bits some day, we will have about 100 bits of resolution, so we'll probably change the scale factor to 1*10²⁷.

The other option would be to switch to arbitrary precision math, but integer representation will always be more efficient to store and process.

Go to http://mining.bitcoin.cz:8332 using a browser on same the machine that you are trying to run Diablo on.  It should ask for your username and password.  Put in the username and password for your worker.  You should get back some JSON data.

If your browser can't connect at all, you have a connection problem to solve.
If it rejects your username and password, you aren't using the right ones.
If it all works, you have a firewall that is blocking the diablo application from connecting out.

Go back to mining.bitcoin.cz, keep the port at 8332.  I just switched one of my miners over to it for testing, and it worked fine.

Make sure that you have a worker registered on the site, and that you are putting the right username and password for the worker into your mining client.  If you aren't absolutely sure you have it right, copy and paste them right out of the Workers section of your profile on the website.

Are you connecting to a pool, or to a local bitcoind?  If a pool, double check the host, port, username and password you are using.  If local, make sure it is set to accept RPC connections and double check that the bitcoind RPC username and password match the username and password of your miner.

Yeah, bitcoins really don't exist.

When you spend, you are really broadcasting a message to the network that says "Here is proof that I have the secret number (private key) associated with these old transactions, and I want to transfer control of the balances they represent to whoever can prove they have the secret numbers corresponding to these new addresses."

Everything can be traced through the public block chain, so some coins might end up with a dubious history, but they can't really become tainted or invalidated.  They can be lost though, if a private key for an address is ever lost, or if it never existed (1BitcoinEater).

Much of the block chain is random numbers and outputs from cryptographic functions.  Both of these are very high entropy data and don't compress very well.  I just ran bzip -9 on my blk0001.dat and I got 21.36% savings (606,522,351 bytes -> 476,975,806 bytes).

For comparison, a recent test showed that pruning could reduce the block database by over 70%.

The bigger problem is that no reversible compression systems that would meet our needs as a security function.  Hashing was picked because it has a whole bunch of desirable properties, like the avalanche effect, and that the outputs look very much like random numbers, allowing us to scale the difficulty in a predictable way.

The reward for generating a block is subsidy + fees.  The fees depend on the transactions included in the block, but the subsidy declines using a known function.  The subsidy is also the source of all new bitcoins.  The idea was for the subsidy to provide a distributed means of getting things started, but in the long run, the main reward for securing the block chain (mining) will be the fees.

The subsidy started as 50 BTC for the first 210,000 blocks, which will take about 4 years to happen.  After that, it will halve to 25 BTC for the next 210,000 blocks.  And the process repeats.

The subsidy function has a precision limit of 0.000 000 01 which matches the current network protocol, so the 11th group of blocks will be rounded down to 0.048 828 12 BTC.  This also means that the total number of coins generated will have a discrete total, rather than having to take the limit of 50/(2^N) as N approaches infinity.  That total will be 20,999,999.976 900 00 BTC.

All of these numbers are totally arbitrary.  50 is a nice round number.  210,000 blocks at 6 blocks per hour works out to about 4 years, which is short enough for people to grasp easily, but long enough to jumpstart the system.

The value of a bitcoin comes from exchange, so the total number of coins in the system is pretty much meaningless.  It is really just a question of scale.

The current version of the protocol is hard coded to 8 places, so adding more places isn't super simple, but it certainly is possible.  I fully expect that we will upgrade from 64 bits to 128 for technical reasons long before it becomes economically desirable.

If they faked the ICE seizure, they did a hell of a great job copying ICE's SSL certificate and private key.

You are right.  You don't have to do anything at all.  Debate is much easier when you can just make shit up and say whatever you want.

Sorta.  If you assume a really trusted node, you don't even need 10 digests, or even one.  But it really depends on how thin the thin client is, and what it is planning to do.

Consider a wallet that only holds keys and signs transactions.  In theory, it doesn't need to know anything at all, because it can ask for the transactions it is about to spend at when it is ready to spend.  The worst a hostile node could do at that point is present bogus transactions for the wallet to use as inputs, but that doesn't hurt the wallet any, just the recipient.  And the hostile node will almost always belong to either the spender or the receiver, and one of them would notice the problem quickly anyway.

As you ask the client to do more things, do more extensive verification, or trust other nodes less, it needs more data and needs to do more processing itself.  There is a full spectrum between the full nodes that everyone has now, and the superthin wallets that I think people will eventually be carrying around.

Yeah, my bad.  I was looking at and thinking of AMB but typed M2 instead.  I like to think of excess reserves as lurking money, not in the spotlight, but still there.  The Fed is paying interest on these excess reserves, so clearly they want the banks to keep the money parked there so that it will be available when needed.  Yes, I know they aren't paying much interest, but it is still enough to keep the banks from dumping them.

Nope, sorry.  Gzip is a streaming compressor.

And in general, GPUs aren't as memory limited as you are thinking.  The typical highish end video card that we use has more memory on it than a generic server from a couple of years ago.  Any change that makes hashing memory intensive enough to stop GPU mining will kill the network by forcing nodes to drop out.

I think that your problem with pruning is that you have decided on one way to do it out of many, and your way won't work, so you think that no way will work.

I can assure you that there actually are ways to do pruning that you haven't thought of, and they really do work just fine.

And pruning isn't the only solution to the real and imaginary problems in this area.  For example, tiny clients will probably use a system where they contact one or more special nodes to download transaction data on demand.

The key is in the understanding this is to consider that a you need different subsets of the data to do different things, and not every device needs to do the same things, so not every device will need the same data.

edit: kjj 2011-09-15 12:55 -0500 - though -> thought

M2 suggests that rather than right now being a new second problem, the first one from 2008 is still ongoing.

But I think that there will be no new round of widespread asset dumping because cash will just magically appear out of thin air the minute that it looks like it is necessary to prevent another panic.  The memory of 2008 is still fresh in the minds of those that can make it happen, and I don't think they'd hesitate for a minute to prevent a replay, no matter the long term consequences.  That's why I think that the next round will look different.

Well, that's the question now, isn't it?

Might have been a freak event, never to reoccur.  Or it might have been the first in a series of clear warning signs that we are losing control of the monster we've created.

If there is ever another big liquidity crunch like 2008-2009, I think that you are right that the paper prices will fall again, but I also think that the premiums will go up to match or exceed the fall in paper.  But I don't see a replay of 2008-2009 happening again, at least not while people that remember the last event are still alive and still in positions where they can stop it.  So, the next event should be different.

There actually has been a lot of discussion on this.  Search for pruning.

The trick is that exactly how to do it isn't clear yet, and there is no urgency.  600 MB is trivial for the types of devices that run full clients, and the ideas that people have for tiny clients will probably need something else entirely.

After reading this, I had to go look around to make sure Rod Sterling wasn't lurking nearby.

China can't corner dollars because we can produce them at will in any quantity.  I agree with your long term view of the dollar, but it has nothing to do with China and everything to do with Congress.  And at any rate, none of this relates in any way, shape or form to bitcoin, far less to mtgox.

Bailout would be a better term than either investment or purchase.  But that isn't important in the slightest.  What is important is that they spent them, and spending is the exact opposite of hoarding.  While you may have plenty of faith in your own doubts, I prefer data.  I'm pretty sure that mtgox publishes trade data back to the beginning of time, so if you are interested in replacing your faith with evidence, you should be able to figure out how to come up with a reasonable estimate of how much income mtgox has generated.  Until then, I've provided good estimates that suggest that it will take 3 to 6 months of income to replace the 17k they spent, based on current trade volumes.

And that is just a single noteworthy purchase.  For all we know, they could be spending their excess coins on socks, porn and profit sharing like the rest of us.

You do know that adding more supply to a market lowers prices, right?  And so in your hypothetical example, if they decided to sell, it would make the price go down, and not up.

And every sell transaction gives dollars to MtGox.  As their dollar goes up, they own a greater % of the supply.  They are cornering the dollar market!

See how silly that sounds?

The current 30 day volume stat was 1.18 million.  That represents a maximum income of about 7000 in the latest month.  Because of the discount structure, their real income was probably closer to 3000.  For reference, about 7200 bitcoins are added to the system every day.  And there was an incident recently where they spent 17,000 BTC.  So, it isn't that they are hoarding them, it is just that they don't convert them to dollars.

Also, if they are creating a false scarcity to drive the price up, they are doing a really shitty job of it.

Sorry dude, this makes even less sense now that you've explained it.  I think you might have some deep misunderstandings about how all this works.