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

From: Eric Voskuil <eric@voskuil•org>
To: Gregory Maxwell <greg@xiph•org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	Nathan Parker <icesby24@gmail•com>
Subject: Re: [bitcoin-dev] Proposal: rewarding fees to next block miner
Date: Sat, 27 Jan 2018 15:48:10 -0800	[thread overview]
Message-ID: <65742e8e-ee27-40b9-f8ad-37f22916002d@voskuil.org> (raw)
In-Reply-To: <CAAS2fgSzx_beEQqPOdoRJRVMSk0JNT6LGk0fHTktVSCU7sH1cA@mail.gmail.com>

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

The OP premise is flawed:

https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy

as is the idea that side fees are incentive incompatible:

https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy

e

On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote:
> Not incentive compatible. Miners would prefer to include transactions
> paying fees via alternative mechanisms (anyone can spend outputs,
> direct pay to miner outputs, or completely out of band), if they even
> paid attention to internal fees at all they would give a lot more
> weight to direct payment fees. Users would accordingly pay much lower
> fees if they used these alternatives instead of directly, so the
> equlibrium state is almost everyone bypassing.   Bypass fee mechenisms
> have been supported by miners since 2011 too, so it isn't just
> conjecture.
> 
> On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 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
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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 --]