Topic: Rollover transaction fees (Read 2917 times)

The point is that the "best" strategy depends on what others are doing.

I am assuming that there are 2 groups of miners, to make it easier to analyze.

Group A always mine the longest chain,
Group B mine one of the top-2 blocks, and mine the longest if all fees equal

Both groups break ties based on the amount of fees paid.

So, someone mines a block with a large "pass-forward" fee on it.

Both groups mine that block, since it has the largest fee of the top 2.  I assume it will pay 125 and the normal blocks will pay 25.

Eventually someone gets the next block, and now it is

Block-X (125) -> Block-Y(25)

The 2 mining groups mine different blocks now.

Group A mines Y since it is the longest chain.

Group B mines X since it has the highest fee of the top-2.  They try to add Block-Y*(25.001).

If group A wins, then the chain becomes

Block-X (125) -> Block-Y(25) -> Block-Z(25)

All miners switch to Z, since the top-2 have the same fee, Group B might as well mine the longest.

Thus the miner who mined Block-Z wins 25, since all miners are now adding to his block.

So, if a Group A miner wins, he gets 25 coins with certainty.

If group B wins, it is different.  They add Block-Y*

Block-X (125) -> Block-Y*(25.001)

So, it is back at the start.  The only way to "lock-in" Block-Y* is for group A to win.

This means that Group B miners want a large fraction of the miners to be group A.

So, the group B miners win 125 coins, but their block might be replaced.

The probability of winning is equal to the fraction of group A miners.

So, if 99% of the miners are group A, then the payouts are

A: 25
B: 125 * 0.99 = 123.75

This means group B win more, so some A miners switch to group B

Lets say that drops it to 50% in each group, the payouts are

A: 25
B: 125 * 0.75 = 62.5

Group B is still doing better, so more switch

This eventually drops it to 20%, the payouts are

A: 25
B: 125 * 0.20 = 25

Thus both groups get the same, so nobody switches and things stay stable.

It also works from the other direction.  If 1% of the miners are in group A, then the payouts are

A: 25
B: 125 * 0.01 = 1.25

Thus, group A pays better, so miners switch back to A.

The odds depend on the ratio of the high fee to the standard fee.  The analysis could be expanded to cover strategy for setting the fee on each block.

This doesn't make sense to me. Why would anyone choose the lower value strategy?

Yeah, it is weird .

Basically, the best strategy depends on what everyone else is doing.  However, that depends on the best strategy, so there is a loop.

So, lets assume that everyone mines one of the top-2 blocks, 50% always mine the highest block with the highest fees and 50% mine the highest fee block of the top-2.

There is a large transaction included in the top block, say fee of 100 coins.

If you mine the top block, you get 25 coins, if you win (standard miner reward).  Also, since the highest transaction is now 2 behind, everyone will stay on your block.

However, if you mine the 2nd highest and get it, you will win 125 coins, but only if the block is then built upon.  You help this by setting your fee to 0.1 coin (i.e. slightly above the best so far), so all the top-builders switch to you.

Once you win, then there will be 50% mining your block and 50% continuing with the 2nd highest block.  That gives a 50% chance that you win the full 125 (if one of the top miners wins the next block) and 50% chance someone else will replace your block.

So, on average you will win 62.5 by mining the 2nd highest block and 25 by mining the top block.

Thus most will mine the 2nd highest block.

If x mine the 2nd highest and (1-x) mine the highest, then

Option 1: mine the 2nd highest and win
- (1-x) you win full reward (125)
- x you win nothing (since someone else adds a block with 0.01 above your fee)

You win (1-x) * 125

Option 2: mine the highest and win
- 25

For balance, both must be equal, or people will switch strategy to the better one, so

(1 - x) * 125 = 25

x = 0.8

Therefore, 80% will mine the 2nd highest block and 20% will mine the top block.

Oh, I think I got it now. I was forgetting that fees earned are just like subsidy and was thinking that method could only be used to pass on up to all of the subsidy.

Can you help me see my contradiction in the first part? If miners know they'll be ignored if they don't pay half or more to the next block then if they are offered half they'll never try to remine since they'd have to pay out half anyway.

That contradicts yourself.  If miners decide on the basis of rollover payments, then they may decide to mine against the older blocks, esp if there is a large fee for some of the transactions into those blocks.

If they solve it before the next block is found and offer a larger fee, then many miners will then switch to their block. 

The algorithm could be, try to add to the longest chain and if a tie, add to the block which pays the largest to "true".  You might have difficulty getting the new block propagated, but if there is a small number of mining pools, you could send it to them directly and get most of the mining power.

There is a tradeoff, mining earlier blocks lets you get more tx fees.  However, there is a risk the rest of the network will have moved on by the time you solved it.


The transaction fee pays into the block.  If you include a transaction, you can direct the funds to the coinbase transaction.  The output of the coinbase transaction can be anything the miner wants.  If he leaves some funds pay to "true", then it is the same as offering a tx fee to whoever adds the next block.  However, they only get it if their block sticks.

I expect building on the latest block will continue to be the norm, but for different reason (rollover payments) in the future.

In the future if some blocks offer rollover payments and some do not the ones that do will be built on, not the first ones to hit the network. My guess is that the rollover payment will be half of the fees in the block. If that was the norm then when faced with a choice between building on the previous block and getting half of its fees or re-mining the block, offering nothing (or less than half) in rollover fees and having your block ignored (by everyone who is expecting and already has available a version of that block that offers 50%) you will choose to build on the block.

I'm still not clear on how to accomplish a rollover payment.

At the moment, the rule (optional-ish) is that miners must try to add to the longest chain.

Therefore, if you mine against one block behind the last block, any blocks you find will probably be orphaned, since the main chain will move ahead.

However, if there is a large tx fee and miners tend to try to get it for themselves, then it breaks that assumption.

If 10% of the hash power always went to the longest chain, then if everyone else split trying to get the full transaction fee for themselves, the actual longest chain would move forward and leave them behind.

There would be a balance, if you mine the previous block, you might get all the fee.  However, that requires that when you find the block, you can somehow convince the rest of the network to add to your block, even though you were behind. 

Yes, I totally get the idea of passing some on as incentive to the next miner. I'm only wondering about what implementation is currently possible. I think if this does not require a protocol change it will happen on it's own (maybe in 20+ years).

Actually leaving out high fee tx as a treat for the next miner is super gross.

No, you are right.  I skipped a step or something.

[edit]

or maybe, it is still reasonable.

The idea would be that it allows a miner to give fees to the next miner.  In effect, if he includes a transaction in the block which pays to "true", then whoever solves the next block can redirect it to themselves.

So, if someone pays a large tx fee, then the miner has an incentive to leave some for the next miners.  If he doesn't they will keep mining against the previous block.

Unless you are meaning something I can't think of, anyone who sees the block that you desire to be built upon can take the tx out and put it in their own block regardless of whether they use your block or not. And they can spend it in the same block in which they include it.

But the miner has first call. 

If he transfers the coin to his own address, the only way to get that coin from him is to keep mining the previous block.

However, if the reward was high enough, it might be worth it. 

There could be a large number of forks, but only for 1 block.  However, if the winner only takes some of the reward, then there is less of an incentive.

If people spend to long on that one block, then someone else might be able to get 2-3 blocks all at once.

I was trying to think how to pay someone for choosing to build on your block using what is currently available.

Including a tx that anyone can redeem doesn't work, that tx can just be put in a later block.

One way to pass fees forward would be to have a transaction that is unprotected.

Whoever adds the next block can direct that to one of their addresses, in the same way as the do for the coins they mint.

This would allow market forces to operate.  The miner might pass some coins further forward.

If there are 2 possible next blocks, miners might decide to focus on the one which passes forward the largest fee.  The current rule is that if there are 2 possible blocks, the miner is supposed to mine the one they received first.

This could lead to more forking though, if the chain is of the form

A(10) -> B(5) ->

then miners might focus on adding to A, since it has a larger fee available.

However, if the B block also shares some of the TX fees, then it could be

A(10) -> B(10) ->

so no loss.

Fairness in transaction rewards will become more important as the block reward reduces. Enabling something like this now will make miner payments fairer in the future.

I like this idea very much. It changes the incentive from just including a transaction in the blockchain to also burying it, which is what the owner really wants. I've suggested something similar before, but I can't remember whether it was on the forum.

Can you explain?

They will do it when the transaction fees become significant, which won't be very soon.

The transaction fees have been determined by the time the block header to be hashed is composed. When mining in a pool, in theory the pool doesn't need to disclose this information to the miners. But a fair pool rewards miners based on the current transaction fees at the time they submitted a share, so to be accountable for this they need to include this information in the getwork request, perhaps complete with the relevant Merkle branch. So whoever does the hashing will know at any point what are the current transaction fees.

I think mining in a pool takes care of most of this issue. I know most pools don't include fees in the rewards yet, but they will have to soon when the block reward drops.  The other problem is that you really don't know what the fees are going to be while you are mining(I guess you could know real time but it fluctuate widely from one block to another) so it is in the best interest of miners to keep their machines on at all time.  The real issue is that fees will become required for all transactions in the future and the sooner everyone comes to grip with this the better.

Transaction fees serve two purposes. They pay for the marginal cost of verifying, propagating and storing the transaction, and they pay for the amortized cost of hashing to secure it and all the other transactions. In this post I will focus on the latter purpose.

The service of securing the transaction is done by the miner finding the block in which it is included, and by the miners finding the next few blocks. However, what the user pays for this service is collected by the first miner alone. This is both a conceptually perverse incentive structure, and can create real problems in some specific circumstances. Suppose someone makes an important transaction, and pays a hefty fee to make sure it is confirmed by several blocks as quickly as possible. It will be included in a block quickly enough; but suppose after that there is a quiet time with very few fee-paying transactions. Miners could be switching their hardware off or to other tasks, delaying the confirmations, even if the sender was willing to single-handedly sponsor them. (There are workarounds, e.g. sending dummy fee-paying transactions. But the fact that a workaround is necessary suggests something is amiss).

I suggest that instead of the transaction fee going just to the miner including the transaction, it will be distributed among him and all subsequent miners. Most generally, some function f will be chosen, and a total transaction fee of T will pay out T*f(n) to the nth miner (the sum of all f values is 1).

If f is an exponentially decaying function, we are relieved of the need to keep track of payment of all past transactions for every block. Some decay rate r (for example 20%) is chosen. Every transaction included will add its fee to a fee pool. Every block, a portion of r of the current fee pool is given to the miner of the block, and the rest carries over to the next block. So a transaction with fee T will pay out 0.2T to the first miner, 0.16T to the second miner, 0.128T to the third miner, and so on.

This can also work in a continuous way suitable for dynamic block times. A decay rate r is chosen; if the fee pool in a block (after putting in the fees of the included transactions) is P, then after the block the remaining pool will be P*e^(-w*r) where w is the weight of the block, and the rest is the miner's fee. More generally, some function f which integrates to 1 is chosen, and the fee paid to the miner which found a block of weight w after W weight units will be T times the integral from W to W+w of f.

Most users who send transactions are incentivized to keep r as high as possible, so they probably cannot be trusted to choose r themselves. It will either need to be hardcoded, or there should be a properly incentivized dynamic adjustment system.