Topic: Default clients: stop caring. (BIP) (Read 1280 times)

This client validates everything except the scripts, the block timestamp, and the block size. A miner cannot fake the fees because the client validates the numbers. The only way to increase the block subsidy is by stealing outputs.

In the attack above they aren't stealing outputs they are increasing the block subsidy.  Instead of getting 50 BTC they give themselves 55 BTC or 58.72 BTC.  A node can't verify the fees paid without verifying the block tx.  If a node can't verify the fees paid it can't verify the coinbase is accurate.  If it can't do that then it will have no idea is "bad" miners decide to mint more coins that they should.

There is no such thing as "kinda verifying".  You either trust nobody on the network and validate everything or your are a lite client and trust others.  A middle ground serves no purpose.  The client is still relatively complex yet still allows attacks like modifying the generation rate on the network.  At least a lite client knows it isn't validating it is dangerous to build a client which gives the user a false sense of security.

But if the only way to increase inflation is to steal other outputs, I'm sure that less than 51% of miners will allow this. If this is still a concern, let the client track its own coins: if they're stolen, it begins its "verify all transactions" contingency plan. The only other concern here is if miners decide to target known lost coins, but I believe such a cabal to be unsustainable (there are, after all, only so many known lost coins).

Either way, this model still provides much more security than a lite node. It may be useful for merchants and laymen who may not have the time and resources to upgrade Bitcoin often.

The threat model here is straightforward. In some far-off future in which the majority of users and merchants are on lightweight SPV nodes that don't validate every transaction, a bunch of miners get together. They realize that if they work together, they can do a 51% attack. Their goal is not to double spend. Their goal is to break the inflation schedule and start awarding themselves as much money as they want.

This attack will work because most participants in the economy will switch to their dominant chain and happily accept payments using the newly minted money as genuine. A few merchants and exchanges on full nodes would reject it, but if all their customers are trying to cash out the bad money they may feel pressure to "fix things" and get the economy moving again.

It's a dangerous gamble by the miners but if they succeed, they become tremendously powerful and nobody can stop them because the vast majority of users are oblivious to the rule change.

Now, can we stop this? One way is to try and keep as many users as possible on fully validating nodes, but for performance reasons that may be hard.

I guess that means that the transactions need to be processed too. The blockchain is already necessary to monitor attacks, so I assume that is present (this is not a lite node). Could this (transaction processing) be done in a reduced fashion?

If I'm not mistaken, every output is a script and a number, not solely a script. The script doesn't need to be processed to retrieve the number. So the only way a miner could trick a node is to act like the inputs are valid, which the client assumes. But this will cause the block to be rejected by other miners, who do preform full verification.

So, could the client simply refuse to process the scripts on all but the Generated transaction, while processing all the numbers?

The coinbase tx also contains fees. You can't know the fees of a block unless you know the value of every transaction input. You can't know the input values without all the previous blocks.

Why couldn't they check the Generation transaction in this scenario? As long as the outputs sum up correctly, I don't think that the miners can successfully conspire.

I think what you're asking for is for users to run SPV clients, a transition which is already taking place.

SPV clients do fewer checks than fully validating nodes. It means they can be fooled by blocks mined at the correct difficulty but which contain garbage. However, they are much cheaper to run and obviously don't need upgrading if there's a rule change.

The primarily problem right now is that SPV clients can't easily check that the coinbase value is correct. One of the most fundamental rules in Bitcoin, which everyone agrees to when they participate, is the inflation rules. An inability to verify this could result in a miner conspiracy, which would be bad. Merchants and other operators that can afford it should use a full node whenever possible to handle that. SPV clients are good for people who are primarily doing low value / personal transactions, eg on laptops and phones.

The thread title here may sound unrealistic, but I believe this necessary for future Bitcoin adoption.

Currently, the client checks a lot. It ensures the blocks are under 10 MB. It has complex rules about what timestamps for blocks are legal and what timestamps are not. It even tries to make sure the transactions within the block are all correct. (correct me if I'm wrong about any of these)

These checks, and undoubtedly more, are absolutely unnecessary. As long as the miners make sure to follow the correct rules, the client should automatically follow the majority of the network. In fact, these checks are bad: they make changes that will inevitably be needed in the future require hard forks. This is a problem because of two reasons: 1), the client will eventually reject blocks over 10 MB once we need them (needing a hard fork), and 2), the client will reject new types of transactions that it doesn't understand (also needing a hard fork).

Of course, the client needs to make sure it isn't being fed a completely bogus blockchain. Therefore, the client does still need to check the block header's hash and the Generation transaction, as well as listing new blocks as unknown until they are confirmed by 2+ confirmations (by which time the client displays the standard "n confirmations" starting with the block. This should prevent any additional wait times (3 confirmations by most standards), avoid a bogus view of the blockchain, and maintain the trust-free nature of a full node.

There are some issues with this, however. One in particular is the improved utility of a 51% attack. Rather than simply a double-spend opportunity, the attacker might fake some transactions (since the client no longer processes the scripts) and downright steal in the minds of the client. This is definitely a major problem, so I propose the following:

• If the client finds an abnormally large amount of reorgs, it begins checking the blocks (this code is included in bitcoind, so it would not be extra bloat).
• If it finds issues with the blocks, it will compare its version with the median version of its peers. If this median version is much higher than its, the client will disable all functionality and call for an upgrade (this can be manually overridden).
• If it believes that it is up to date, it displays a warning that the network may be getting attacked and begins applying strong checks to blocks. At this point, all transaction-accepting functionality is disabled (because double-spends may be in progress). This can be both manually overridden and automatically overridden simply by waiting a few blocks.

Another major issue is the DOS attack caused by an attacker isolating the client by forcing it to connect to the attacker's version of the network and only the attacker's version. This is called a quarantine, and already has disastrous effects. However, these effects are all the worse when the client is not performing verification, as it, along with many things, will give away the fact that it is quarantined. This issue is compounded because the attacker's peers can trick the client into thinking that it is up to date. In this situation, little remedy exists, but there is one giveaway: a comparatively slow hashrate.

Unfortunately, the network does tend to fluctuate and a slowing of hashrate may not be easily exploited. However, unless the attacker also happens to have a large hashrate, the client can assume that something is wrong if blocks are being found for a period of time slower than an hour per block. Because it is still verifying difficulty and headers (this is necessary), it can launch a warning to be handled by its parent that it may be isolated.

At this point, the client will begin verifying blocks again. If it discovers inconsistencies, this is a definite sign of an outdated client that is under attack. It may elevate the warning to a forced shutdown and an upgrade notice, only capable of being overridden manually.

There are likely countless issues with this approach that my non-technical mind has failed to enumerate, and I do not suggest this be immediately implemented. However, of course after extensive theory and testing, it may be an excellent improvement for the network. I would like to note that this patch not only does not require a hard fork (old clients do not need to upgrade), but also prevents most sources of hard forks in the future. Hard forks are known to cause chaos, and a solution to the problem is needed (but not urgent). Miners will, of course, need to react to hard forks still; however, in this changing atmosphere from "everyone's a miner" to "mining is a profession", it may be time to stop treating clients like miners.