Topic: Elastic block cap with rollover penalties - page 4. (Read 24075 times)

While writing a response to this, I realized the situation is actually much more nuanced than I thought.

Big miners don't have an advantage over small miners. Rather, the existence of big miners shifts the balance of the system as a whole, creating a situation where miners get more rewards, users pay less fees and/or get more of their transactions included, while nodes have to deal with larger blocks.

Here are example scenarios, with made up values for the penalty function. I assume for simplicity (not a necessary assumption) that there is endless demand for transactions paying 1mBTC fee,  that typical blocks are around 2K txs, and that there are no minted coins. The pool clears at 1% per block.

Scenario 1: The network has 100 1% miners.
Every 1% miner knows he's not going to claim much of any penalty he pays, so he includes a number of transactions that maximize fees-penalty for the block. This happens to be 2K txs, with a total fee of 2 BTC and penalty of 1 BTC.

The equilibrium for the pool size is 100 BTC.
Miners get 2 BTC per block (2 fees + 1 pool collection - 1 penalty).
There are 2K txs per block.

Scenario 2: The network has 1 90% miner, and 10 1% miners.
The 1% miners build blocks with 2K txs, fee 2 BTC, penalty 1 BTC, like before.
The 90% miner knows that if he includes more txs, he'll be able to reclaim most of the penalty, so the marginal effective penalty exceeds the marginal fee only with larger blocks - say, which have 4K txs, 4 BTC fees, 4 BTC penalty.

The average penalty per block is 3.7 BTC. The equilibrium pool size is 370 BTC.
There are on average 3.8K txs per block.
A 1% miner gets, per block he finds, (2 + 3.7 - 1) = 4.7 BTC - more than in scenario 1!
The 90% miner gets, per block he finds, (4 + 3.7 - 4) = 3.7 BTC - less than small miners get in this scenario, but more than miners get in scenario 1!

To restate what goes on - the big miners create supersized blocks because it benefits them, but it benefits the small miners even more.

Miners are happy. Users are happy. Nodes are not happy.

But note the following: Big miners make the mining rewards bigger, but you don't have to be a big miner to enjoy it (small miners actually are at an advantage). So if a miner becomes big, he encourages more people to start mining, raising the difficulty and countering the effect.

So more analysis is still in order, but overall, I don't think these dynamics encourage the formation of big miners.

True, if the circumstances were different. Presently the average (7-day, moving) block size (ABS) is about 400KB, 80% of T, and T will certainly be less than the ABS by the time an elastic cap can be implemented. ABS will never approach 2T because some miners will always churn out small or empty blocks (certainly while the reward > block fees), so the present ABS is for practical purposes equivalent to T now. The point which would normally be an alert for attention to be given to the prevailing limit.

The elastic cap with fee pool does need working out in detail, as the discussion between molecular and NewLiberty shows. Its mechanics, incentives, attack vectors and long-term implications need to be known and understood. This won't happen quickly. Phase I buys time for Phase II.

Increasing the 1MB is technically very simple, accepting just the usual risk inherent in larger blocks.

If this type of consensus can be hand-waved away, then we are going to have to go home and learn to love our respective fiats, because they will all be around for a lot longer.

I'd be in his position I'd would too ask to see some code or at least some data analysis supporting the design. You can't just propose stuff and expect the people reviewing it to do all the leg work. An implementation at least proves your design is conceptually sound. It's easy to forget certain aspects when you theorycraft, and having to implement at least the PoC certainly motivates you to keep it as simple as possible.

It's a polite way to say :"i am not interested in your design, i dont want to analyse it, f**k off. "

Pointing to Monero as an examination of prior art is asking a bit much. Are you expecting us to dig through the Monero source code? How do they get around the problem?

This is not very helpful;


https://getmonero.org/knowledge-base/moneropedia/coinbase

Thanks for clearing it up. I can see now where NewLiberty was probably coming from (either the monero mechanism or your earlier proposal referenced in OP, both of which I didn't look at). Your reward calculation formulas cleared things up.

I agree. Also with IBLT or other block propagation bandwidth conservation techniques (some of which seem to be used by pool interconnects already) this effect can (and will) be nullified.

You're both correct, it's a matter of terminology.

The miner has to pay it. But he's not paying by spending any of his previous coins, he's paying by having the payment deducted from the reward he collects. If the reward is not sufficient (negative reward after deduction), the block is invalid.

So the miner will not include so many transactions that the penalty will make the block invalid.

See my previous comment and I hope everything is clearer now. I apologize for not intervening sooner, I had a busy day, maybe this whole exchange could have been avoided...

I'll try to examine your proposal in more detail later.


Looks correct, but I would say there was no problem to begin with.


This is correct but as far as I know, the magnitude of this effect is very small, and not enough to keep block size in check.


This is correct, and I hadn't given enough thought to this problem prior to posting.

Now that I've given it more thought, I think it can be significantly alleviated by making collection from the pool span a longer period, on the time scale of years. Relative hashrate is likely to change over these period, so it may not be the best plan to publish excessively large blocks hoping to reclaim the fee (and publishing typical-sized blocks does not give big miners an advantage). Also, with a different function you can change the balance between the marginal and total penalty so that the actual penalty is small, nullifying the effect (it will require the cap to be a bit harder, but still more elastic than what we have now).

I agree that this calls for more analysis.


Not much to explain. The penalty is deducted from the amount of bitcoins he can credit himself in the generation transaction; The network keeps track of the total pool size, and allows miners to add a fraction of it to the bitcoins they credit themselves.
Instead of
total outputs = new coins + tx fees
You have
total outputs = new coins + tx fees + collection from pool - penalty

The penalty doesn't depend on the fees of txs in the block. It depends on the size of txs in the block. Out-of-band payments are irrelevant - the miner must include the transaction to perform the service he would be paid for. If he includes it he pays a penalty for it, and expects a fee for it - it doesn't matter to either him or the user if the payment is out-of-band or not (except, of course, the extra friction of out-of-band).

This is simply false, as explained above. It seems many people are confusing the current suggestion, with the suggestion I brought up back in 2012 and referenced here.

It's an additive deduction, not multiplicative.

You seem to be thinking the miner's reward is:
(1 - penalty) * (minted coins + tx fees + collection from pool)
Where it is really:
minted coins + tx fees + collection from pool - penalty

Having more fees in the txs included doesn't increase the penalty. There is no difference between adding 1 mBTC to the fee and paying 1 mBTC out-of-band.

The miner chooses how many transactions to include. The penalty starts at 0 and stays there for a while (or alternatively, has a derivative starting at 0). He chooses the set of txs so that his profit is maximal, not so that it is negative...

(PS I apologize for the multiple comments on the same issue, I'm trying to respond to all claims in the order I see them...)

I'll need to examine the Monero implementation in more detail to answer that intelligently. One difference is that Monero, apparently, already has a mechanism to defer rewards to future miners, so it has no need to introduce the extra concept of a rollover pool. Additionally, I suggest a different scaling function (hyperbolic rather than quadratic). It has a different set of tradeoffs (which I currently believe is better overall). I could suggest a different function based on the requirements - finding the best functions to manifest given intuitive concepts is what I'm good at.

I agree with the last part. I, too, am upset when people try to reinvent the wheel. But it's difficult to know whether some feature exists in some system somewhere. I've read several discussions of block size and didn't see a mention it. I started with privately chatting with Gavin and Mike, and they seemed unaware of it either. I don't think it was reasonable for me to do anything but post about it and see what people think, which I did. If I had known about the situation in Monero I may not have made this post.

I'm glad that I did, though. As we can see from the lively discussion here and on reddit, there are obviously many people who are interested in this kind of solution but who, like me, were not previously aware of Monero's system. I think wider awareness and discussion of these issues is a good thing.

No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees.

By miner has to pay it, we mean "not paid to miner but to rollover pool instead"?  They miner is never paying anything, they are simply not given the reward, yes?

I still don't follow you.

Why does it matter wether the fee is payed on- or off-chain. The penalty is the same and the miner has to pay it either way.

I see your point in that the amount of the fees are not part of the calculation of the penalty.
However, why would anyone mine a block for which they will not be paid?  
The incentive would remain to move fees off chain, especially as the coinbase reward decreased.
Off-chain fees would not be subject to the seizure and redistribution of the rollover.
Better for the miner to guarantee positive revenue and get it on the side.

No, that wasn't my understanding (the bolded part doesn't follow from what's said above, does it?). Fees aren't subject to penalty at all. The penalty depends purely on size of block (if I understand correctly). Even if the tx fee was payed out of band, the tx will still contribute to the penalty through increased block size. Yes, it's deducted from the tx fees (can be other tx fees), but it depends (in amount) on the fact that the tx takes up space in the block.

In other words: it's not the fee that's penalized (neither in block nor out of band), but the space it takes up in the block.

Again: if I understand correctly.

EDIT: regarding the discussion about what happens with block reward going to 0: this means that you can't mine a block with only transactions that had their fees paid out of band, because they would take up space and thus effect a penalty, but there'd not be enough on-chain fees to pay for it.

Thanks for that, it was my reading also.
Thus TX fees that are not in the block but paid out of band are not subject to penalty...

Another difference, is that in the Monero method, the penalty can not reduce the block reward to below zero and make the block invalid.
There are many similarities, but also some important differences with the time tested Monero method and the current proposal.

I read that as "from reward, tx fees and rollover pool input".


I stumbled accross this problem, too and I remember it was adressed upthread, not very far from OP. I just searched, but couldn't find it and I also can't remember why (or wether) this wasn't a problem. I think I wasn't convinced or didn't think it through.

But thinking about that a bit, assuming 0 block reward is reached. A block with no transactions in it can always be mined because it doesn't carry any penalty at all. As soon as there's a penalty to be payed there need to be some transactions in the block and the fees they pay must exceed the penalty (otherwise the block is invalid). Is this a problem? I'm not sure, seems to me that depends on the particularities of the penalty function...


 

Sure, there are quite a few edits that would be needed.
However, it has also been deployed and shown to work over time without pernicious economic effects. 

When Gavin says "I need to see working code", he probably means code he can directly deploy to his test setup within the framework of bitcoin-core. I can relate to this demand and find it reasonable.

This is penalty then ONLY taken from the coinbase reward and not also TX fees?
How would this method survive the successive halvings (much less the eventual cessation)?

If it includes the TX fees (which likely it must), then to the extent that fees are off chain, they are not subject to the penalty.

I think the penalty is not dependent on the fee:


So it still has to be paid regardless of wether or not the tx fee payment was on- or off-chain.