By the way, if you want a good argument to use, it's this: Mining algorithms that work most efficiently on CPUs would tremendously increase the incentive to create bot nets and use malware to mine.

The best counter-argument to that is that we're already starting to see botnets that do GPU mining. But I still think it's a downside.

No. There are two cases. One is mining, the other is validating PoW. In the case of mining, yes, you have to compute many hashes. But it makes no difference how easy or hard that is. If we make it ten times harder, the difficulty will just be ten times less.

The only case where performance matters is validating PoW. That only takes a single hash.

Why is that stupidity? The whole point is to make the mining algorithm difficult. We currently do that by raising the difficulty number, but it's just as reasonable to simply make the algorithm itself difficult to compute. There is no inherent benefit to one method over the other.

The GPU can't deal with the expansion problems. The GPU may have a large number of computation units, but its memory bandwidth is only so high, and it's not optimized for the kind of random accesses the algorithm would require. The reason GPU mining works so absurdly well is because the Bitcoin mining algorithm uses so little memory.

Look, if GPUs could do everything better than CPUs, why would we have CPUs?

You do keep repeating that, but you've yet to form anything resembling an argument. I wonder what you will you say that when some entity makes an ASIC that can mine dozens of times more efficiently than any GPU.

How so?
These are quite sound ideas. If you know something wrong with them, do tell.

A CPU can trivially use 128MB for a split-second to validate a block header. Trying to do that on a GPU would slow you down to a crawl -- it doesn't parallelize well because the GPU doesn't have as many memory paths as it has execution units.

There is really nothing complicated about making a mining algorithm that works much better on a CPU than a GPU. After all, the algorithm -- so long as it is concatenated into a hash -- can be anything at all so long as it's deterministic. If all deterministic computing tasks could be done better on GPUs than CPUs, we wouldn't have any CPUs.

My point is that this is trivial to get right. It is not even not impossible (as has been suggested in this thread), it is not even challenging. To anyone familiar with the details, it is immediately obvious that one could do this. (And it is trivial to prove that any attack on the composition function would also equally be an attack on the underlying hash function.)

The tricky part is designing the 'MESS' so that it has the characteristics you want. As you pointed out, if someone finds a trivial way to accelerate the 'MESS', the whole effort gains you nothing. It is almost trivial to do this passably, you can just take 'scrypt'. But it is very challenging to do this well. (And, in fact, it can backfire if someone finds a way to, say, implement the 'MESS' 1,000 times faster than anyone else can and they can keep that method secret.)

Well, it doesn't matter how long it takes to perform the mining operation for a miner. If the operation takes ten times as long, the difficulty will just be one-tenth. However, it does mean that it will take each client a bit longer to verify that the proof of work is valid.

Fortunately, you could make that verification about 1,000 times more expensive than it is now without a problem. And remember, it's typically the CPU that has to verify the PoW, and we're talking about algorithms CPUs can do efficiently anway. Theoretically, it could even be possible to make it easier to verify on a CPU than Bitcoin is, but that would be hard.

I'm being serious that these are all things that can be done and might even be improvements over the way Bitcoin does things. However, I'm quite doubtful that he's actually done these things or gotten them right. I too will believe it when I see it. (I also see little point in a new currency with fees if it brings nothing significant to the table.)

It's trivial. You simply have some complex obscure function that may or may not be secure and then you combine it using a secure hashing function like SHA-256.

For example, where Bitcoin does SHA(SHA(header)) you can simply do SHA(SHA(header)+MESS(header)) where 'MESS' is some operation that takes lots of memory and lots of decisions. (Here + is concatenation.) The security properties of the SHA-256 hash are provably still preserved by this change -- that is, you couldn't design an algorithm for 'MESS' that made this any weaker than SHA(SHA(header)) even if you specifically tried to.

I already explained this. Simply take something that a CPU does better than a GPU (for example, accessing large amounts of memory) and put it at the center of your hashing algorithm.

Except the memory access is not independent. Alternatively, you simply include large numbers of decisions in the hashing algorithm, which slows GPUs down.

You simply use a hashing algorithm that won't parallellize effectively. For example, if the hashing algorithms "expands" the block header up to 128MB before it compresses it down to the 256-bit output, trying to run 128 of these at once on a GPU will just massively bottleneck at the memory controller.

If you use a hashing operation that consists of an expand/mix/compress mechanism in such a way that the 'expand' and 'hash' steps need to access a large amount of memory (say, 128MB) and the 'mix' step requires lots of decisions (say, testing bits to decide which entries in the 128MB expanded table to XOR or swap), GPUs will absolutely suck at the hashing operation.

As I said, it is not difficult to design a hash function that runs very, very poorly on a GPU. You simply use the operations that CPUs do well (make decisions, access large amounts of memory) and avoid the operations GPUs do well (long chains of pure computation on small amounts of data with no decisions).

A hashing algorithm can do anything at all, so long as it's deterministic. You could, for example, do a standard SHA-256 and then also do something massive and crazy (but totally unlike SHA-256), XOR the result of that massive, crazy thing with the SHA-256 result, and still preserve all of the cryptographic properties of the hash. It is not difficult to make that massive, crazy part something GPUs do poorly.

If GPUs were better than CPUs at every possible algorithm, why would we have CPUs at all? Of course there are algorithms that CPUs are better than GPUs at. If you used such an algorithm to generate the hashes that have to meet the difficulty target, CPUs would be better miners than GPUs.

I'm saying that if we think we want less pollution, and respond by exerting downward pressure on the amount of pollution, we may wind up with an amount of pollution that's inefficiently low.

I agree. That's because most people don't understand the issues. They just assume that we'd be better off with less of bad things without thinking that a bit less of bad things may mean much less of good things. There is a tendency to assume that bad consequences are inherently inefficient, but that reasoning is bogus. In fact, that reasoning may be so bogus that the level of bad things we have is already inefficiently low.

For example, many people are worried that they might die in a plane accident. But if they responded by putting downward pressure on their chances of dying in a plane accident, they would most likely wind up increasing their chances of dying in a car accident or irrationally forgoing opportunities for business or pleasure travel. While plane accidents are certainly bad, there's no reason to think they're inefficiently bad. If the government, for example, put downward pressure on plane accidents, it would likely result in higher ticket prices, which would actually kill more people in car accidents.

You can't say "that's bad, put pressure to reduce it". You need to say "that's *inefficiently* bad".

The difference would be that the probability of inadvertently entering a situation where large parts of the network disagree over a block's validity would be much, much lower.

Nothing prevents people from using NTP to mine blocks with accurate timestamps. If the question is why Bitcoin doesn't force people to provide more accurate timestamps it's because there's no technical requirement for them and it increases the risk of inadvertently entering a situation where large parts of the network disagree over a block's validity.

Right, which just requires changing the "5" to a "6" and the "10" to a "9".

No, it doesn't. You've moved it from one account to another, not from one address to another.

The fact that addr1 is associated with acc1 means *ONLY* that newly-received coins sent to addr1 are credited to acc1. If a new address needed to be created, there would be no reason to associate it with acc1 specifically and in fact it would be associated with the default account.

If the protocol demanded strictly-increasing timestamps, what should you do if a block shows up whose timestamp is one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?

Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.

Addresses are assigned to accounts only to determine which account's balance to increase if new coins arrive. Any coins you hold belong to your wallet. Account balances are purely for user convenience.

No, but it does mean that if you apply external downward pressure on automobile accidents, you may just increase the amount of efficient driving that's suppressed.

The optimum amount of pollution is not zero. (If it was, we couldn't cook food or breathe.) Unless you have evidence that the present level of pollution is above the optimum level, it is entirely possible that what we actually want is *more* pollution.

Using taxes to engineer society in this way requires a government that can make these decisions rationally. I have little hope that such a thing is likely to ever exist.

That's more or less the way I feel. I know all the problems with pollution taxes, but I don't know of any better way.

That's actually the general way I feel about Libertarianism overall. I can't see my way all the way through to a perfect Libertarian utopia, and such a thing probably doesn't exist. But I can certainly see a lot of ways we can make things a lot better than they are, and maybe we will figure out the rest once we get closer. (Maybe not, but as long as things keep getting better, I won't complain about the fact things aren't yet perfect.)

The 'bitcoind' program itself is doing zero hashes per second. The 'accepted 16' count indicates the number of shares that were accepted. If you're solo mining, accepted shares are worthless. If you're mining in a pool, accepted shares are what earn you payouts.

But that's because they see denialism as a way to prevent massive increases in government power. If there was no threat of a coercive government response to global warming, why would Libertarians particularly care one way or the other?

I don't follow the argument. Yes, I agree that some of the motivations would exist even in a Libertarian society. But certainly some of the biggest motivations (the fear of a massive, coercive, economy-killing government response) would not. So I don't see why you think it would be "bigger lies".

If you think there's something wrong with it, please feel free to say so. But "That's what you think" just isn't constructive.