[bitcoin-dev] Encouraging good miners
jg at 112bit.com
Tue Mar 28 14:38:40 UTC 2017
If a miner try to hurt the network mining just empty blocks at some time the rest will start rejecting their blocks and will be orphans so will loss the reward incentive and that miner will join the behavior of the rest of the miners, if that miner has 51% of hashrate there the smallest problem are the empty blocks.
From: bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Stian Ellingsen via bitcoin-dev
Sent: Monday, March 27, 2017 2:50 PM
To: Btc Ideas <btcideas at protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Encouraging good miners
On 27/03/17 18:12, Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more
> transactions. This comes into play when 2 blocks of the same height
> are found. The first good block mined would be orphaned if it had less
> transactions than another. Optionally, have this rule apply to the
> current block and the previous one.
This would encourage miners to make their own tiny junk transactions to fill up their blocks, perhaps leaving larger, more space-efficient transactions in the mempool.
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but
> that would no longer be a good assumption.
> I read some miners could attack a chain by mining small or empty
> blocks. This makes that a little more difficult, but they can still
> attack the chain many ways.
"Good" miners should probably build upon the block with a set of transactions more similar to what they themselves would include based on their mempool at the time. However, miners don't have an incentive to do so today. Instead, they may be better off building upon the block that leaves the most valuable transactions in the mempool, e.g. a small or empty block, and maybe leave some valuable transactions in the mempool for the next miner. This issue could possibly be addressed by a soft-fork that requires miners to pay a portion of their fees to future miners.
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
More information about the bitcoin-dev