Quote from: DannyHamilton on December 31, 2013, 02:08:20 AM

That's sort of the definition of a "reference client", isn't it?

Well, the reference client could be the one that implements a written spec.

I can see source code being a valid way of doing the spec. However, the bitcoin client isn't really written that way.

It would have to compromise efficiency if that helps clarity.

However, Gavin has commented that they are not likely to do a complete re-write of the reference client. At the moment, keeping it functional is more important.

Quote

It does. Doesn't it? That's why it's called "forked". The protocol states that if a miner is using a client that doesn't exactly implement the necessary protocol rules, then the output of that miner is ignored and not accepted as "bitcoin" communication.

A way of doing this would be broadcasting block headers even if the blocks are rejected. The allows all clients to build up the block header tree. It would give them visibility of forks that have happened and an estimate of hashing power.

This would allow clients to display a warning that around 10% of the networks hashing power is being committed to a forked chain.

Similarly, the clients on fork could display a warning that they are on a chain that is only getting that 10%.

In a situation like that, clients could increase the confirm window and/or require confirms on both forks.

This gives an automatic/instant response to the forking of the chain and then the developers of the client that caused the fork can bring their client back into consensus.

The most recent fork was caused by a new release of the reference client. Even if there is only one client, it will still have version numbers. Being able to handle forks so that the network degrades more elegantly would be an improvement and it would allow alternative implementations.

Quote

And how would the "chain" be maintained then? The idea of the blockchain is to force a consensus. If a "customer client" is willing to hold multiple competing blocks as equally valid, then the concept of a consensus is lost.

Soft forks already operate on this principle. It is ok for merchants and customers to have outdated clients. They accept blocks based on the old and new rules.

(A majority of) miners only accept blocks based on the new rules. This means that the chain is guaranteed to only have blocks that operate on the new rules (barring temporary orphans).

Mining nodes need to be stricter than general usage nodes.

With mining pools, they could very easily verify all blocks they receive against multiple versions of the most popular clients.

Handling it with p2pool would be more difficult.

Quote

How would you know when "all" clients had accepted the blocks/transactions? How would you handle a situation where an adversary creates a client that specifically rejects the very transactions or blocks that you believe should be included?

I meant all of the multiple clients that the miner is using to check blocks, not all possible clients.

Even with a reference client, this would be a good system.

Quote

Quote from: TierNolan on December 31, 2013, 12:49:47 AM

The offending block would be logged for analysis and client authors would be expected to bring their software into compliance.

If two clients disagree about a two different blocks, which block is the "offending" one, and which is the "acceptable" one.

If there was 10 common clients, then for almost any block almost all of them would agree. However, in that context, I would take the position that if any of them reject a block, then miners would be recommended to reject the block.