Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4162 bytes --]

Miners accept less than the optimal (i.e. highest net fee) set of
transactions all the time. The reason is that it takes too much time to
compute the optimal set. All other things being equal, the miner who is
more efficient at computing a set is more profitable.

Intentionally not accepting the most optimal set possible is a cost, not
a source of increased returns. Miners can raise the historical fee level
by paying this real cost, just as can any other person (by submitting a
competitive-fee transaction). They cannot "recover" this cost. They have
no place of advantage in terms of competing for block space.

Finally, historical prices do not determine future prices. Current
competition for block space determines future prices.

e

On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
> 
>     Miners can fill their blocks with transactions paying very high fees
>     at no cost because they get the fees back to themselves. They can do
>     this for different purposes, like trying to increase the recommended
>     fee. Here I propose a backwards-compatible solution to this problem.
> 
>     The solution would be to reward the fees of the current block to the
>     miner of the next block (or X blocks after the current one). That
>     way, if a miner floods its own block with very high fee
>     transactions, those fees are no longer given back to itself, but to
>     the miner of future blocks which could potentially be anyone.
>     Flooding blocks with fake txs is now discouraged. However, filling
>     blocks with real transactions paying real fees is still encouraged
>     because you could be the one to mine the block that would claim this
>     reward.
> 
>     The way to implement this in a backwards-compatible fashion would be
>     to enforce miners to set an anyone-can-spend output in the coinbase
>     transaction of the block (by adding this as a rule for verifying new
>     blocks). The miner of 100 blocks after the current one can add a
>     secondary transaction spending this block's anyone-can-spend
>     coinbase transaction (due to the coinbase needing 100 blocks to
>     mature) and thus claiming the funds. This way, the block reward of a
>     block X is always transferred to the miner of block X+100.
> 
>     Implementing this would require a soft-fork. Since that secondary
>     transaction needs no signature whatsoever, the overhead caused by
>     that extra transaction is negligible.
> 
>     Possible Downside: When the fork is activated, the miners won’t get
>     any reward for mining blocks for a period of 100 blocks. They could
>     choose to power off the mining equipment for maintenance or to save
>     power over that period, so the hashrate could drop temporarily.
>     However, if the hashrate drops too much, blocks would take much
>     longer to mine, and miners wouldn’t want that either since they want
>     to go through those 100 reward-less blocks as soon as possible so
>     they can start getting rewards from mining again.
> 
> 
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
> -- 
> Lucas Clemente Vella
> lvella@gmail.com <mailto:lvella@gmail.com>
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]