Also, what is to stop a miner adding the extra 8 BTC to get it over the limit? In that case, the block is funded anyway.
Ouch... not much of an assurance contract then is it? It's basically just a donation at random - that's very clever of you. There is of course the risk that your block gets orphaned and another miner takes the fees instead, but that happens something like 1% of the time now, and potentially a lot less in the future. Miners can deliberately orphan the block too, but we really want to implement mechanisms to discourage that behavior for a lot of reasons.
Yeah, there is a risk, esp if the amount you add it very high.
A similar situation was discussed in another
thread (ish).
The current rule is mine the longest chain. However, if a miner included a payment to true in the block, then it would encourage other miners to build on his block.
If the chain was
A -> B -> C ->
but B has a large payment to true and C doesn't, then miners would be encouraged to keep mining against B, rather than accept the new block.
This means that you have a tradeoff. If you create C' and it pays a lot of the reward from B onward to true, then you weaken the incentive.
An equilibrium would set it where there is an incentive to include some payment to true. This means that tx fees are effectively smeared.
I assumed there was basically 2 strategies
1) Mine against the longest chain
2) Mine against one of the top-2 blocks, whichever pays the highest to true
Depending on the payout for the top-2 blocks, neither strategy wins outright, a certain fraction will follow each of them.
You could use nLockTime: basically you would all participate in authoring an nLockTime'd assurance contract transaction. Some time before the nLockTime deadline approaches, if the assurance contract is *not* fully funded, IE a miner might pull the "self-assure" trick, you double-spend the input that would have gone to the contract so your contribution to it is no longer valid.
You can only spend your own input. All other inputs would still be valid. In effect, all participants would have to cancel.
It does offer protection for those who actually care. The miner would have to publish the tx a few days (or hours) before the deadline, so he couldn't add it to his block.
On the other hand, that means anyone can DoS attack the assurance contract process itself by doing exactly that, and if they time it right, they can still pull off the "self-assure" trick.
The only thing that would accomplish is to reduce the total, since the inputs from anyone else who contributed would still be valid.
With a hardfork we can fix the issue though, by making it possible to write a scriptPubKey that can only be spent by a transaction following a certain template. For instance it could say that prior to block n, the template can only be a mining fee donation of value > x, and after, the spending transaction can be anything at all. It'll be a long time before that feature is implemented though.
What would be good would be the timestamping thing. For example, you a hash of the tx must be included at least 10 blocks previously.