Dividing miner reward over a k-length jumping window

[TinfoilHat]

Nowadays, a miner can gain more than another one even when they mine the same amount of blocks due to variance in tx fees. It's expected that, especially once the coinbase reward is gone, this will result in miners competing for "juicy" txs and hence damaging the stability of the system. See https://dl.acm.org/citation.cfm?id=2978408 for future reference.

I've been thinking if it's possible to overcome this simply by changing the rewarding mechanisms of Bitcoin. So let's say we keep a k-length jumping window, take sum of fees in that window and divide it evenly to miners. So if we have k=4 and 1st block has 20 in fees, 2nd has 20 in fees, 3rd has 10 in fees and 4th has 30 in fees each miner will get (20+20+10+30)/4 = 20 in fees.

What would be shortcomings/downsides of such a mechanism ?

[achow101]

It's expected that, especially once the coinbase reward is gone, this will result in miners competing for "juicy" txs and hence damaging the stability of the system. See https://dl.acm.org/citation.cfm?id=2978408 for future reference.

This behavior is known as fee sniping and there are things that are working already to protect against it. First of all, by having more fees in unconfirmed transactions than can be cleared by a block, miners will be more incentivized to mine those unconfirmed transactions because they can make just as much or more money than by fee sniping. Secondly, many wallets are now implementing anti-fee sniping measures such as locktimed transactions. By setting a transaction's locktime to be the block height when a transaction was created, the wallet prevents a miner from being able to orphan that block and fee snipe and include new transactions because the new transactions cannot be included in that replaced block. So this reduces the amount of money that can be gotten by fee sniping which makes miners less incentivzed to do so.

I've been thinking if it's possible to overcome this simply by changing the rewarding mechanisms of Bitcoin. So let's say we keep a k-length jumping window, take sum of fees in that window and divide it evenly to miners. So if we have k=4 and 1st block has 20 in fees, 2nd has 20 in fees, 3rd has 10 in fees and 4th has 30 in fees each miner will get (20+20+10+30)/4 = 20 in fees.

It's impossible to know how many miners there are and impossible to detect if someone is is pretending to be multiple miners so that they get paid more and everyone else gets paid less.

[TinfoilHat]

It's impossible to know how many miners there are and impossible to detect if someone is is pretending to be multiple miners so that they get paid more and everyone else gets paid less.

Why ? Can't we learn the identities of miners simply by checking the k-length window blockchain? Of course I meant, in my original post, we divide the reward to miners of the window. I'm not talking about distributing the reward to whole network.

[DannyHamilton]

Am I understanding correctly that you are suggesting that the block reward that the miner (or mining pool) is allowed to assign in the generation transaction for any given block should be the sum of:

• The block subsidy at that block height
• 1/4 of the transaction fees of that block
• 1/4 of the transaction fees of the previous block
• 1/4 of the transaction fees of the block before that
• 1/4 of the transaction fees of the block before that

So, if the current block subsidy is 12.5 BTC and the most recent 3 blocks had total fees of 2 BTC, 4 BTC, and 1 BTC, and I build a block with fees of 3 BTC, then the maximum reward I'd be allowed to assign myself in the block that I build will be:

12.5 BTC + (0.25 * 2BTC) + (0.25 * 4 BTC) + (0.25 * 1 BTC) + (0.25 * 3 BTC) = 15 BTC

[TinfoilHat]

Yes Danny, you're right. I ignored the default reward (12.5 BTC) for simplicity and assumed revenue is earned solely from tx fees.

[achow101]

Why ? Can't we learn the identities of miners simply by checking the k-length window blockchain? Of course I meant, in my original post, we divide the reward to miners of the window. I'm not talking about distributing the reward to whole network.

Oh, you meant looking back through the last k blocks. That was not clear in the OP.

This would not necessarily work since a coinbase transaction can pay to multiple outputs, i.e. pay multiple people simultaneously instead of just one person/entity.

Edit: My reading comprehension is way off today.

[TinfoilHat]

Sorry I don't follow this part:

This would not necessarily work since a coinbase transaction can pay to multiple outputs, i.e. pay multiple people simultaneously instead of just one person/entity.

How this invalidates the scheme I described ?

[DannyHamilton]

Oh, you meant looking back through the last k blocks. That was not clear in the OP.

This would not necessarily work since a coinbase transaction can pay to multiple outputs, i.e. pay multiple people simultaneously instead of just one person/entity.

Achow101,

Take another look at my example...

The pool would have a total of 15 BTC that they can assign in their coinbase transaction.

They can assign it to as many or as few outputs as they like.  The sum of those outputs just wouldn't be allowed to exceed the sum of the current block subsidy PLUS 25% of the sum of the transaction fees from the 4 most recent (including the current) blocks.

I think there are probably 2 things that make this difficult to implement in Bitcoin...

1.  How would it be handled if 25% of the transaction fees results in a decimal that cannot be represented with 8 decimal places?  This will result in rounding issues, and difficulty in figuring out if all the necessary fees have been collected.

2. This would be a significant hard fork in Bitcoin, and it would be effectively impossible to get an overwhelming majority to implement it.

Because of issue number 2, even if you come up with a good way to resolve issue number 1, this isn't ever going to happen in Bitcoin.  You might be able to get an altcoin to try implementing it though.

[gmaxwell]

As achow noted, fee sniping is a long known concern. The first active countermeasures were deployed a couple years ago in the form of anti-sniping locktime use.  Fee backlog also looks like it will work just fine to stabilize incentives, as expected.

Unfortunately no fee sharing scheme has been shown to be incentive compatible under reasonable assumptions.   The problem is that users can pay miners via mechanism other than (and in additional) to any visible fees that would be shared via additional tx outputs, or completely out of band payments.  Miners have accepted payments in this manner since 2011, so it isn't theoretical.  Any fee sharing scheme would create a very strong incentive to accept alternative payment (which isn't shared) and for users to offer a portion of their fees as alternative payment.

Danny's #1 makes no sense to me-- no one cares about a satoshi difference, just specify the rounding in a particular way and be done with it. That is a one line of code point that no one would care about.

The appropriate consenusus rule change would be to allow coinbase transactions to spend outputs including other immature coinbase outputs. From that simple and generally useful change alone arbitrary fee forwarding or sharing schemes could be implemented in a compatible manner... but we're still left with none that appear even remotely strategically stable.

[DannyHamilton]

The problem is that users can pay miners via mechanism other than (and in additional) to any visible fees that would be shared via additional tx outputs, or completely out of band payments.  Miners have accepted payments in this manner since 2011, so it isn't theoretical.  Any fee sharing scheme would create a very strong incentive to accept alternative payment (which isn't shared) and for users to offer a portion of their fees as alternative payment.

I've used that very same example many times when people suggest that the consensus rules should place a cap on how high of a fee a transaction can have.  I'm surprised it slipped my mind in this example. Thanks for pointing it out.

Danny's #1 makes no sense to me-- no one cares about a satoshi difference, just specify the rounding in a particular way and be done with it. That is a one line of code point that no one would care about.

I was writing off the top of my head without thinking through all the details (which is probably why I missed the out-of-band payment issue).  My concern wasn't that a mining participant would be upset that they missed out on a satoshi that someone else received.  My concern was that (if you don't use a reward forwarding scheme where the forwarded value is specified in the output of previous blocks): Rounding "up" would be inflationary as new satoshis are added to the system in many blocks. Rounding "down" would destroy satoshis permanently. Rounding "off" (to the nearest integer) would be unpredictable as to whether it would create new satoshis or would destroy satoshis.

It would seem that using the coinbase for specified fee forwarding would solve this, but that wasn't what we were discussing at the time.
 

The appropriate consenusus rule change would be to allow coinbase transactions to spend outputs including other immature coinbase outputs. From that simple and generally useful change alone arbitrary fee forwarding or sharing schemes could be implemented in a compatible manner... but we're still left with none that appear even remotely strategically stable.

Agreed.