Why the block rule "total inputs + new coin = total outputs" is not enforced

[o]

I was thinking that the total Bitcoin difference between two adjacent blocks is always newcoins = (50e8 >> (height / 210000)), so the following rule should hold:

    "sum of all input values of all transactions in a blocks + newcoins = sum of all output values of all transactions in a blocks"

But it is not!!! Only the ">" instead of "=" holds in the above rule, there have been some blocks having less newcoins than the expected value above. Now, there are more than total 10BTC disappearing in nowhere and the reported total coin in most websites are simply wrong. I feel faked by it as there is really a way to destroy Bitcoin: Users pay the transaction fee and miners throw them into blackhole by not adding it to the block's coinbase.

This rule can be very trivial to verify by simple additions with no additional backtracking required. So why don't we enforce the coinbase output value to satisfy the rule above?

Example: https://blockexplorer.com/block/000000000000016034213ddfedb834de864de92b03723db20ae70d3e631ef68d

[DeathAndTaxes]

That is the attack vector you are worried about?  Really?  Couldn't miners just make the coinbase address a non-existent address and destroy coins just as easily or send them to a non-existent address?

As for why not change it?  It is a hard fork.  Hard forks are never trivial.  In practical terms hard forks will probably never be implemented for anything other than critical (as in "oh my god Bitcoin is going to die") fixes.

[justusranvier]

That is the attack vector you are worried about?  Really?  Couldn't miners just make the coinbase address a non-existent address and destroy coins just as easily or send them to a non-existent address?

As for why not change it?  It is a hard fork.  Hard forks are never trivial.  In practical terms hard forks will probably never be implemented for anything other than critical (as in "oh my god Bitcoin is going to die") fixes.

Just queue it up into the list of changes to be made the next time the block version is incremented.

[o]

That is the attack vector you are worried about?  Really?  Couldn't miners just make the coinbase address a non-existent address and destroy coins just as easily or send them to a non-existent address?

As for why not change it?  It is a hard fork.  Hard forks are never trivial.  In practical terms hard forks will probably never be implemented for anything other than critical (as in "oh my god Bitcoin is going to die") fixes.

No, it is not an attack vector at the moment, but it makes the rules look more arbitrary, harder to explain, harder to understand and harder to verify. I am writing a program and the total UTXO is not equal to the total "expected Bitcoin" at any time, so I have spent hours to find it out. If it were all in some "blackhole" addresses, indeed, that makes thing simple. In case of not having a full blockchain but only UTXO, I am not sure whether it allow some kind of attack.

I am asking why it is not implemented in the first place. The first such transaction is at least two years after the genesis, so I think there may be some intention to do so.
 

[gmaxwell]

Every place the rules are made tighter the system becomes harder to implement correctly and harder to improve in a backwards compatible way. One more thing which someone can be invisibly and nearly undetectably too lax on and cause a terribly hardfork if their implementation is ever widely used.

For example, I suggestion I'd made in the past is that someday transactions could contain small (32 bit) checkpoints against random blocks in the recent chain such that the transaction's fees can only be collected in blocks descending from that checkpoint.  This would allow users to make sure their fees are not funding a malicious miner who is mining a fork which is against their interest. Such a thing would require that the coinbase outputs be less than the allowed value in those cases.

Regardless, your invariant would also be violated by the duplicate coinbases or by unspendable OP_RETURN coins which should not be tracked in the UTXO.

This is by far not the most finicky or subtle implementation rule in the Bitcoin system.

Every time I see someone trying to reimplementing Bitcoin themselves my heart is crushed a little bit. There are so many things that need to be created in our ecosystem beyond yet another reimplementation, most of which are never completed, never made correct, and never widely used.

[o]

For example, I suggestion I'd made in the past is that someday transactions could contain small (32 bit) checkpoints against random blocks in the recent chain such that the transaction's fees can only be collected in blocks descending from that checkpoint.  This would allow users to make sure their fees are not funding a malicious miner who is mining a fork which is against their interest. Such a thing would require that the coinbase outputs be less than the allowed value in those cases.

Ok, it makes a bit sense now, for some possibly real use case. I have included all out transactions including the OP_RETURN, so I was wondering where is the missing.

Subtle implementation rules are not a problem, but it must be stated clearly not only in the code, but written somewhere.

Reimplementation is also a way to check the existing Bitcoin code base, so you cannot blame them, even though their client is just rubbish. After that, they might help back.

Anyway, thanks.

[Come-from-Beyond]

I was thinking that the total Bitcoin difference between two adjacent blocks is always newcoins = (50e8 >> (height / 210000)), so the following rule should hold:

    "sum of all input values of all transactions in a blocks + newcoins = sum of all output values of all transactions in a blocks"

But it is not!!!

Coz Satoshi foresaw that one day one guy would use floating-point arithmetic where 1 + 2 =/= 3.

[o]

I was thinking that the total Bitcoin difference between two adjacent blocks is always newcoins = (50e8 >> (height / 210000)), so the following rule should hold:

    "sum of all input values of all transactions in a blocks + newcoins = sum of all output values of all transactions in a blocks"

But it is not!!!

Coz Satoshi foresaw that one day one guy would use floating-point arithmetic where 1 + 2 =/= 3.

Please give a better example, they have exact representation in IEEE

[Come-from-Beyond]

Please give a better example, they have exact representation in IEEE

They do, but long chain of computations can lead to weird results like 4.00000000561 instead of 4.

Working with floating-point numbers u shouldn't do things like

Code:

if (a == b) ...

The code should be replaced with something like

Code:

double epsilon = 1e-9;
if (a > b - epsilon && a < b + epsilon) ...

If u validate transactions/blocks the code

Code:

if (inputs == outputs) ...

can fail, u r supposed to write it as

Code:

if (inputs > outputs - epsilon) ...

[kjj]

Subtle implementation rules are not a problem, but it must be stated clearly not only in the code, but written somewhere.

This is a popular request, and progress is always happening in that direction.  But it simply isn't possible to have a non-code description of the rules that is complete, accurate and more understandable than the code itself.