Elastic block cap with rollover penalties

[Meni Rosenfeld]

This is not the prisoner's dilemma table. The Nash equilibrium is the best possibility for both. When a player chooses S, he helps the collective but also helps himself selfishly. There is nothing anyone can gain by "defecting". Every miner chooses S because it benefits him, not because he has some sort of pact where the other miner does the same.

The defector does gain by defecting; They gain market share. This isn't a prisoner's dilemma, it's just the best way for a mining entity to out-compete the other. It doesn't make a lick of difference that they can make more profit (Split between the two) by cooperating over a long period of time by not leveraging a competitive advantage over that same period.

Market share and out-competing are means, not an end. The goal of a miner is to maximize his profits. A big miner does this by creating large blocks. Why would he care that the other miner also gets more profit? Is he jealous or something? Please clarify what it is exactly that you're trying to say...

Sure, but the defector gets more profits by capturing market share. The defector gets more profit at 90% market share than his competitor at 10% even if total profit between the two is higher by cooperating at 50%.

It really is very similar to a cartel, except that the mechanism for higher profits is different. The way the cartel falls apart is the same; The defector gains profit for itself by capturing a larger market share.

I'm sorry, and I hoped it wouldn't have to come to this, but I give up. This discussion is not going anywhere. You keep making the same statements and I keep making the same refutations. The difference is that I've backed my claims with calculations. You didn't point out any problem in my calculation (the assumptions or one of the steps) and didn't provide a calculation of your own. You just object to the final conclusion without any regard to the derivation that led to it.

It seems you're trying to force classical game theory cases into fitting the situation we have here. You say you agree that "this isn't a prisoner's dilemma" but all of your statements are taken from the world of prisoner's dilemma. But they just don't fit, the game here is different, and you refuse to address or listen to the logic that demonstrates this.

You also make generic statements without clarifying under which situations they apply, whereas I've tried to map out how the situation will play out in varying circumstances.

To conclude this line of discussion, I'll restate my thoughts on the matter:

1. If we assume that the hashrate distribution and difficulty are static, big miners will create supersized blocks because they know they'll reclaim some of the fee themselves. This is a Nash equilibrium and does not rely on any sort of collaboration or reciprocity. This will shift the balance we tried to achieve with the cap in the first place, allowing more txs into blocks than what would happen without this effect, and giving slightly more profit to big miners and much more profit to small miners.

2. In practice, the assumption above is not realistic; miners know that if they create supersized blocks, they will make mining more attractive, thus attracting more miners, thus increasing the difficulty, thus reducing their profits. So longer-term it is actually not beneficial for them to do this. So in all likelihood, big miners will not create supersized blocks, and all miners will get the same reward per block, without any superlinear advantage. Because of this, the original objection that the method in the OP encourages centralization of mining, has been refuted.

[1715557087]

1715557087

[1715557087]

1715557087

[1715557087]

1715557087

[1715557087]

1715557087

[DumbFruit]

2. In practice, the assumption above is not realistic; miners know that if they create supersized blocks, they will make mining more attractive, thus attracting more miners, thus increasing the difficulty, thus reducing their profits. So longer-term it is actually not beneficial for them to do this. So in all likelihood, big miners will not create supersized blocks, and all miners will get the same reward per block, without any superlinear advantage. Because of this, the original objection that the method in the OP encourages centralization of mining, has been refuted.

I already said my original argument wasn't true because it was only true in cases where larger blocks provide a higher reward per block to the miner. Your algorithm doesn't do this.

That's what I was saying here;

What I wrote would only apply to penalties that don't reduce the reward below the target block size reward.

I agree that big miners will not create supersized blocks, but it isn't because it attracts more miners, it's because mining supersized blocks confers a competitive advantage to the other miners that don't. The net effect is I can't imagine a situation in which any miner would create any supersized blocks because doing so would immediately damage their position in the market.

[molecular]

This is not the prisoner's dilemma table. The Nash equilibrium is the best possibility for both. When a player chooses S, he helps the collective but also helps himself selfishly. There is nothing anyone can gain by "defecting". Every miner chooses S because it benefits him, not because he has some sort of pact where the other miner does the same.

The defector does gain by defecting; They gain market share. This isn't a prisoner's dilemma, it's just the best way for a mining entity to out-compete the other. It doesn't make a lick of difference that they can make more profit (Split between the two) by cooperating over a long period of time by not leveraging a competitive advantage over that same period.

Market share and out-competing are means, not an end. The goal of a miner is to maximize his profits. A big miner does this by creating large blocks. Why would he care that the other miner also gets more profit? Is he jealous or something? Please clarify what it is exactly that you're trying to say...

Not sure about this, but maybe two things Meni says could be contested:

• "The goal of a miner is to maximize his profits": If miners were individual humans I would say this is false (let's hope it's not and they act rationally maximizing their profits). There are studies showing that humans prefer a small gain to a large one if it is comparatively larger than some implied gain of some other person. Say a choice between receiving 1 Bitcoin or receiving 2 Bitcoins is offered, but another person receives 0 Bitcoins in the first case and 10 in the second case. Then the individual will tend to choose to receive only 1 Bitcoin, just to receive "more than the other guy". That's not "maximizing profit", that's maximizing some kind of "relative perceived profit" and yes, it boils down to jealousy (or rather 'envy'). Not sure this applies here, but I think it's possible. In case such psychological effects do apply, there's more human peculiarities that might be of interest, like loss aversion, where avoiding losses is preferred to acquiring gains of the same amount.
• "The miner has higher profit choosing S over N": I think this might be dumbfruits point: there might be some other, indirect effects stemming from the increased profit given to the competition influencing the miners profit in the long run. Let's take for a example a rather efficient miner. Let's say he can cover his cost in both cases S and N and let's say his counterpart mines with higher energy cost. Choosing S might push his competition into the profit zone, while choosing N might force the competition to shut down operations. In such a scenario, choosing N would be the more profitable option. Or maybe less crass: by reducing the competitions profit overproportionally to it's own, a miner can maybe slow down their expansion or increase of efficiency and maybe deven drive them out of the game entirely.

;tldr: I'm not so sure if it isn't a prisoners dilemma after all. Sure, Menis math checks out, but maybe that model (looking only at direct profit) is inadequate for predicting miner behaviour because it possibly omits important side effects or (less likely imo) makes false assumptions about miner motivation / decision making premises.

[jonny1000]

"The miner has higher profit choosing S over N": I think this might be dumbfruits point: there might be some other, indirect effects stemming from the increased profit given to the competition influencing the miners profit in the long run. Let's take for a example a rather efficient miner. Let's say he can cover his cost in both cases S and N and let's say his counterpart mines with higher energy cost. Choosing S might push his competition into the profit zone, while choosing N might force the competition to shut down operations. In such a scenario, choosing N would be the more profitable option. Or maybe less crass: by reducing the competitions profit overproportionally to it's own, a miner can maybe slow down their expansion or increase of efficiency and maybe deven drive them out of the game entirely.

Yes this could be another risk and your argument is probably correct, however the impact of this might be small and it actually has characteristics similar to normal mining economics.

Overall, at this point, in my view Meni’s proposal could be the best suggestion so far, in respect of partially alleviating some of the concerns associated with the block size limit issue.

The potential options we have are outlined below:

1. Increase the max blocksize to 20MB
Advocate: Gavin

2. Do Nothing
Advocate: ?

3. Introduce a variable difficulty based on blocksize
Advocate: Gregg

4. Limit the CoVar of the transaction fees in blocks
Advocate: Sergio

5. Elastic block cap with rollover penalties
Advocate: Meni

6. Dynmaic block size limit based on averages of historic blocks sizes or historic fees
Advocate: ?
 
7. A less direct solution like Lightning, Sidechains or off chain transactions
Advocate: ?

8. Allow users to choose their own limits, with the 1MB chain confirming transactions in larger chains
Advocate: Adam

9. A compromise between 1MB and 20MB
Advocate: ?



Unlike most of the other proposals, Meni's suggestion appears to have less of an impact on the network if it is not used and has far fewer security risks than the other proposals, in my view.  At the same time it can be combined with a variable limit based on historic medians, to produce a more complete solution to the problem.  I hope people scrutinize this proposal, and the others, in an objective way and that we eventually implement a solution in a thoughtful and patient manner, based on the best technical solution, with the smallest amount of valid attack vectors.

[Meni Rosenfeld]

I agree that big miners will not create supersized blocks, but it isn't because it attracts more miners, it's because mining supersized blocks confers a competitive advantage to the other miners that don't. The net effect is I can't imagine a situation in which any miner would create any supersized blocks because doing so would immediately damage their position in the market.

But you didn't explain why "competitive advantage" and "position in the market" matters. And I can't myself think of any reasonable explanation, other than something equivalent to what I said about increasing difficulty. (See also response to molecular below).

"The goal of a miner is to maximize his profits": If miners were individual humans I would say this is false (let's hope it's not and they act rationally maximizing their profits). There are studies showing that humans prefer a small gain to a large one if it is comparatively larger than some implied gain of some other person. Say a choice between receiving 1 Bitcoin or receiving 2 Bitcoins is offered, but another person receives 0 Bitcoins in the first case and 10 in the second case. Then the individual will tend to choose to receive only 1 Bitcoin, just to receive "more than the other guy". That's not "maximizing profit", that's maximizing some kind of "relative perceived profit" and yes, it boils down to jealousy (or rather 'envy'). Not sure this applies here, but I think it's possible. In case such psychological effects do apply, there's more human peculiarities that might be of interest, like loss aversion, where avoiding losses is preferred to acquiring gains of the same amount.

Of course, I am assuming straightforward profit maximization. Assuming otherwise would drastically alter the problem. But, in the scales involved, I think this assumption will be close enough to reality.

"The miner has higher profit choosing S over N": I think this might be dumbfruits point: there might be some other, indirect effects stemming from the increased profit given to the competition influencing the miners profit in the long run. Let's take for a example a rather efficient miner. Let's say he can cover his cost in both cases S and N and let's say his counterpart mines with higher energy cost. Choosing S might push his competition into the profit zone, while choosing N might force the competition to shut down operations. In such a scenario, choosing N would be the more profitable option. Or maybe less crass: by reducing the competitions profit overproportionally to it's own, a miner can maybe slow down their expansion or increase of efficiency and maybe deven drive them out of the game entirely.

This is a special case of what I said about "attracting more miners". It doesn't matter if the miners he is attracting are new miners, or old miners who are now able to continue operating or grow their operation. Note that "competition" in mining only matters through the difficulty mechanism.

;tldr: I'm not so sure if it isn't a prisoners dilemma after all. Sure, Menis math checks out, but maybe that model (looking only at direct profit) is inadequate for predicting miner behaviour because it possibly omits important side effects or (less likely imo) makes false assumptions about miner motivation / decision making premises.

Well, it is a prisoner's dilemma, but in scenarios different from the ones I was discussing. Most of what I wrote here on the centralization issue refers to the "static hashrate distribution and difficulty" case, which is not very realistic but is the baseline scenario; without agreeing on it, there's little hope to agree on anything else. Which is why the discussion with DumbFruit was frustrating - he kept disagreeing, but he never clarified if he thought the results for this case are incorrect (with which I strongly disagree) or just ultimately irrelevant (with which I agree, and have agreed from the very start - see next-to-last paragraph here)

There are two cases where this becomes a prisoner's dilemma:

1. Miners aren't satisfied with just supersized blocks, they want to make hyper blocks - blocks even bigger than what optimizes (tx fees - penalty * (1-hashrate)). This is not a Nash equilibrium and only profitable if others follow their lead. I've mentioned this scenario to demarcate the discussion (See last paragraph here) but it's simply not what I was talking about. I was talking about selfish supersized blocks.

2. Miners consider the long-term effects on difficulty and hashrate distribution. Then the Nash equilibrium is probably creating normal blocks. If they want to band up in cartels and create supersized blocks even in this scenario, sure, they can go ahead, but... I'm not sure it's profitable even with a strong cartel (since it's the small miners who benefit the most), and again, I was never trying to argue miners should create supersized blocks in this scenario.

In other words, in all cases I am advocating going with the Nash equilibrium. I was never even considering strategies that would make this into a prisoner's dilemma.

[Meni Rosenfeld]

The table is nice (didn't really check the numbers though), but I think it fails to consider the ways in which different ideas can be combined. Some ideas work very well with others.

I'll comment on my own position:

• I haven't yet examined Greg's proposal in detail, but originally my main concern with it revolved around implementation difficulty, and the magnitude of change in the spirit of Bitcoin. If those are out of the way... Then it might turn out that mathematically and economically, it's actually equivalent or even superior. We do need to carefully consider how this proposal changes the difficulty.
• An elastic cap should be combined, IMO, with an increase in the block limit. T=3MB would work well for now. Without the soft cap, the block limit should go up to something like 4MB.
• I still find it hard to believe that Side chains are actually possible (recent news about first sidechain being rolled out notwithstanding). But assuming they are, they're a game changer. They would pretty much take the edge off the entire debate since everyone can just choose a chain to their liking. Assuming someone implements it, of course, but that should be easier when people can spend less of their time arguing and more developing.
• Micropayment-channel based payment networks are a critical component of long-term scalability, but they're not a replacement, and still need more time to be viable.

[someone42]

Just to make sure everything is clear, the penalty pool is not related to mining pools, despite the usage of the word "pool". I have not talked about mining pools in this discussion.

Sorry my mistake.  I was thinking miners could leave mining pools in this scenario, to benefit from the remaining members of the pool producing larger blocks.

I decided to analyse the situation in the case of mining pools. As a start, I used Meni's parameters as described in https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115.

Assume I have 1% of the total hash rate. I am currently in a 90% mining pool. There are also 10 1% miners. Using the results in Meni's post, my expected income per block is 0.04685 BTC.

Will I earn more by leaving the 90% mining pool and solo-mining?

If I solo-mine, the 90% mining pool is now an 89% mining pool and there are 11 1% miners. Solving for these parameters:
n0 = 7217 (slightly smaller)
n1 = 5945 (almost the same)
p = 0.6906 mBTC (slightly larger)
Penalty paid by 1% miners: f(5945) = 0.4602 BTC
Penalty paid by 89% miner: f(7217) = 3.3043 BTC
Average penalty: 0.89*3.3043 + 0.11*0.4602 = 2.9914 BTC
Reward per block for 1% miner: 5945 * 0.0006906 + 2.9914 - 0.4602 = 6.6368 BTC
Reward per block for 89% miner: 7217 * 0.0006906 + 2.9914 - 3.3043 = 4.6712 BTC

My expected income per block is now 0.06637 BTC, 42% higher than when I was in a mining pool. There is a very strong incentive to betray the large mining pool. I have not done any additional calculations, but I suspect it is also profitable for every individual miner in the larger mining pool to leave and solo-mine, or at least join a smaller pool.

Thus a sensible large mining pool operator should not mine supersized blocks. Meni, I realise you've come to this conclusion another way (higher income means higher difficulty), but this is yet another reason why rollover penalties discourage large mining pools from mining large blocks.

[Meni Rosenfeld]

My expected income per block is now 0.06637 BTC, 42% higher than when I was in a mining pool.

My expected income per block that I find is 6.637 BTC. It's true that my expected income per block found by the network at large is 0.06637, but I find it confusing to refer to it as "expected income per block".

There is a very strong incentive to betray the large mining pool. I have not done any additional calculations, but I suspect it is also profitable for every individual miner in the larger mining pool to leave and solo-mine, or at least join a smaller pool.

Thus a sensible large mining pool operator should not mine supersized blocks. Meni, I realise you've come to this conclusion another way (higher income means higher difficulty), but this is yet another reason why rollover penalties discourage large mining pools from mining large blocks.

Right. Mining pools, in this view, are essentially a way for small miners to band in a cartel to create blocks which are individually hyper-sized (but supersized for the pool as a whole), hoping for a greater profit. Hyper-sized blocks are not a Nash equilibrium (every miner hopes that the others band up, and enjoy their supersized blocks without contributing himself), and thus pools that try to form around this objective will quickly disintegrate. A big miner needs to be monolithic to have any hope of creating supersized blocks and not disintegrate.

[jonny1000]

pools that try to form around this objective will quickly disintegrate. A big miner needs to be monolithic to have any hope of creating supersized blocks and not disintegrate.

Is this considered a security improvement?

[Meni Rosenfeld]

pools that try to form around this objective will quickly disintegrate. A big miner needs to be monolithic to have any hope of creating supersized blocks and not disintegrate.

Is this considered a security improvement?

No, it just strengthens the point that the proposal does not create new reasons to centralize. It does nothing about old reasons though.

Meni Rosenfeld: What do you think about the BIP 100 draft?

If I understand correctly, in this proposal the miners get the ultimate say about what the block limit will be. That is ill-advised, as their incentives are not aligned with those of the users and the nodes. A voting mechanism makes it very easy for miners to collude.

I agree that it will be good to set a precedent that the Bitcoin technology can be changed, and that therefore we should start with a small change. But is seems Jeff's proposal is anything but, rather it's a very controversial change with significant economic implications.

Take that part out, and I support this. I'd prefer, though, either going straight for 4MB, or an accelerated timetable for 2MB.

[sdp]

Can we use this curve to set the minimum mining fees?  The "penalty" needs a  constant multiplier because the units cancel each other out and we don't get bitcoins units at the end of our calculation.



Suppose the constant multiplier is 1 mBTC and we use a free limit of 400kB and a hard limit at 1 MB.  Then when blocks get to 95% filled the transactions simply get rejected unless they are paying 15.125 mBTC per transaction.  Getting close to 750kB means we have to pay around 1 mBTC.

Small Blocks
Take the soft limit to be say 400 kB and the hard limit to be 1 MB with a fee multiplier of 1 mBTC.

size (MB)	Cost in mBTC
0.1	0
0.2	0
0.3	0
0.4	0
0.5	0.05
0.6	0.25
0.7	0.75
0.8	2
0.9	6.25
0.95	15.125

Big blocks.
Soft Limit of 3 MB, and a hard limit of 6 MB.  The fee multiplier of 1 mBTC.

size (MB)	Cost in mBTC
0	0
0.25	0
0.5	0
0.75	0
1	0
1.25	0
1.5	0
1.75	0
2	0
2.25	0
2.5	0
2.75	0
3	0
3.25	0.00757575757575758
3.5	0.0333333333333333
3.75	0.0833333333333333
4	0.166666666666667
4.25	0.297619047619048
4.5	0.5
4.75	0.816666666666667
5	1.33333333333333
5.25	2.25
5.5	4.16666666666667
5.75	10.0833333333333

I would say this would be what the miners would have to adopt for a change in a protocol, or they could adopt one of these fee tables without a change in the protocol.

Perhaps an SPV client could look at the size of the last ten blocks and judge what fee will probably get charged and quote that to the user.  Maybe 10 mBTC would be a better multiplier.


sdp

[jonny1000]

Meni Rosenfeld: What do you think about the BIP 100 draft?

If I understand correctly, in this proposal the miners get the ultimate say about what the block limit will be. That is ill-advised, as their incentives are not aligned with those of the users and the nodes. A voting mechanism makes it very easy for miners to collude.

BIP 100 is the best available option
Jeff’s BIP 100 suggestion is not perfect and Meni’s comments on it our partially true.  Please see Meni’s comments here:
http://www.reddit.com/r/Bitcoin/comments/39qh66/i_would_like_more_discussion_about_this_objection/

Under BIP 100 miners will vote on the blocksize limit and it is true that miners interests are not perfectly aligned with users and therefore the limit may be sub optimal.  The limit will however be able to dynamically increase with demand, but in a conservative manner, which should alleviate many peoples concerns that blocks will get too big.  This proposal may result in blocks being too small, for the reasons Meni says, but this may be appropriate conservatism.  No solution is going to be perfect, but we need to have some kind of limit policy.  I think BIP 100 is the best suggestion so far, better than doing nothing, increasing the limit to 20MB or implementing an historic median based rule.

Median based rule versus BIP 100
The classic problem with the median based rule is that each individual miner may try to maximise short term profit by including more transactions in blocks.  Therefore the limit is increases.  As a whole the mining industry would prefer not to include that many transactions as they would rather reduce supply a bit and achieve higher fees.  This is analogous to the tragedy of the commons problem.  BIP 100 solves this, as miners collectively vote on the maximum blocksize, in order to maximise the USD value of fees.  It is in the miners long term interests to see higher transaction volumes, a higher USD exchange rate and for Bitcoin to succeed.  At the same time miners need to ensure the supply of space in blocks is sufficiency scarce to be able to maintain high enough fees.  Miners will make a balanced decision, partially based on price elasticity of demand, which is ultimately driven by the users.

More Economics
This proposal allows miners to control the supply side of the market for transactions and users to control demand.  This seems an appropriate balance to me.  Unlike what may occur in other industries when cartels try to restrict supply, this vote will not enable the miners to implement barriers to entry.  Any miner will always be free to join the industry at will, and vote for larger blocks, without a competitive disadvantage.

The economic value of mining transaction fee revenue is the core Bitcoin metric that should be maximised
Miners will vote to maximise the value of mining transaction fee revenue over the long to median term.  People have different visions for what Bitcoin should be and would like to prioritise different metrics.  Personally I think maximising mining transaction fee revenue is perhaps the most important long term metric measuring Bitcoin’s success.  This measure reflects Bitcoin’s long term sustainable security.  I challenge anyone to suggest an alternative single metric considered more indicative of success.

Improves Network security
BIP 100 is also a defence  against any future SHA256 two way pegged Sidechain.  Currently if one wants to use bitcoin is a zero trust environment, one needs to use the main Bitcoin Blockchain, this creates transaction demand that should eventually secure the network.  If in the future a Sidechain begins to become successful, users could switch to this and miners could also begin to switch over.  Eventually if the Sidechain has more revenue for miners, it could have a higher hashrate than the mainchain which could undermine the mainchain security.  A Sidechain is more likely to achieve this if it implements policies which maximise mining revenue.  I therefore propose that Bitcoin core implements policies to maximise mining revenue now, to secure it against this and other future attacks, which aim to incentivise miners more on another system.  Sidechains may be inevitable anyway, and I am not against competition for the mainchain, I just think its in Bitcoins interests for the mainchain to be the most secure.

Therefore, at this point, I give my support to BIP 100.

[Meni Rosenfeld]

Can we use this curve to set the minimum mining fees?  The "penalty" needs a  constant multiplier because the units cancel each other out and we don't get bitcoins units at the end of our calculation.

In theory you are correct, the formula needs a constant multiplier in the Bitcoin dimension. I've deliberately set the constant to 1 BTC and ignored its existence for several reasons:
1. Because of the speed at which the function grows, the constant doesn't really matter much, it more or less just shifts the typical block size by a small amount. That is, the function works at multiple scales of the BTC price / processing cost dimension.
2. Because it doesn't matter much, I wanted to keep the formula simpler, and not make it seem like there are many parameters which need to be chosen.
3. A value of 1 BTC gives reasonable results. (Perhaps a bit lower is better, since there's too much support on the low block sizes).

I wasn't really able to follow the rest of your calculations:
1. It seems you are giving values of the total penalty, but to figure out tx fees you need to look at its derivative.
2. It's not clear how many txs you assume fit in a MB; for values of, say, 3000 txs per MB, I get much lower values.