Pages:
Author

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

donator
Activity: 2058
Merit: 1054
A longer time period over which the reward is given doesn't help, as the larger nodes or entities will still get a larger ratio of the rolling over fees, by definition.
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.
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
Since the blocksize issue is controversial and may take some time to settle, we are better off implementing this elastic cap right now with a softfork (your phase II) and skip the hardfork part (phase I).

We could do that by choosing T=0.5MB (2T = 1MB = current maxblocksize).

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.


latest poll results "should the blocksize be raised?".
http://www.poll-maker.com/results329839xee274Cb0-12#tab-2:




legendary
Activity: 3766
Merit: 1364
Armory Developer
Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time.  Its not new, or novel, except in ways that it is not as good.

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.

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

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.
member
Activity: 554
Merit: 11
CurioInvest [IEO Live]
Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time.  Its not new, or novel, except in ways that it is not as good.

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.

It's a polite way to say :"i am not interested in your design, i dont want to analyse it, f**k off. "
sr. member
Activity: 433
Merit: 267
An examination of the prior art is warranted.
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;

Quote
The Basics
A special type of transaction included in each block, which contains a small amount of monero sent to the miner as a reward for their mining work.

https://getmonero.org/knowledge-base/moneropedia/coinbase
donator
Activity: 2772
Merit: 1019
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?
No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees.
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...

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.
donator
Activity: 2772
Merit: 1019
I think the current design already incentivize smaller blocks: Smaller blocks get broadcasted much faster and become less possible to be orphaned. If you consider that there are 25 coins to compete for, you would like to broadcast your block as fast as possible once you find it
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.

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.
donator
Activity: 2058
Merit: 1054
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?
No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees.
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...
donator
Activity: 2058
Merit: 1054
...
I'll try to examine your proposal in more detail later.


There is a major shortcoming I can see in the rollover fee pool suggestion: miners are incentivized to accept fees out of band so they can obtain all the highest fees instantly, thus defeating the entire purpose of that feature.
This is only (potentially) a problem in my 2012 rollover fee proposal. Here, tx fees don't go into the pool - fees are paid to the miner instantly. It is only the miner's block size penalty that goes in to the pool, and he must pay it if he wants to include all these transactions.
Just so I can understand properly, your penalty is related to a formula that excludes the transaction fees, therefore paying fees out of band won't reduce the penalty.  Is that how the problem is solved?
Looks correct, but I would say there was no problem to begin with.


I think the current design already incentivize smaller blocks: Smaller blocks get broadcasted much faster and become less possible to be orphaned. If you consider that there are 25 coins to compete for, you would like to broadcast your block as fast as possible once you find it
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.


That said, a problem with any kind of rollover fee is that it assumes that moving fees to future blocks is also moving fees to different nodes.
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.


Can you explain a bit about the mechanism wherein the miner pays into the rollover pool
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

 It is not obvious why this dictinction makes a difference.  It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).
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).

The rollover pool creates an incentive for the miner to not use the fee pooling, and instead contract directly with the TX creators.
If implemented as written, this could become a problem.  Large TX creators and large miners would have an incentive to cartel because of the way this rollover pool works.
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.

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...
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.

Another difference, is that in the Monero method, the penalty can not reduce the block reward to below zero and make the block invalid.
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...)

, and why that is different from the 'original proposal'?
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.

Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time.  Its not new, or novel, except in ways that it is not as good.
An examination of the prior art is warranted.
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.
donator
Activity: 2772
Merit: 1019
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.

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.

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?

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

Edit: Saying again for clarity - In the current proposal, fees from transactions will be paid to the miner of the current block instantly and in full. The miners can't gain anything by accepting tx fees out of band. The one paying into the rollover pool is the miner himself, as explained below.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
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.

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.

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?
donator
Activity: 2772
Merit: 1019
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.

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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
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.
donator
Activity: 2772
Merit: 1019
The penalty will be deducted from the funds he collects in the generation transaction

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

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...

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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'?  It is not obvious why this dictinction makes a difference.  It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).

I think the penalty is not dependent on the fee:

The miner of a large block must pay a penalty that depends on the block's size.

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


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)?

The penalty will be deducted from the funds he collects in the generation transaction

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

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.
donator
Activity: 2772
Merit: 1019
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'?  It is not obvious why this dictinction makes a difference.  It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).

I think the penalty is not dependent on the fee:

The miner of a large block must pay a penalty that depends on the block's size.

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


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)?

The penalty will be deducted from the funds he collects in the generation transaction

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

If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.

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...


 
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time.  Its not new, or novel, except in ways that it is not as good.

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.


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. 
donator
Activity: 2772
Merit: 1019
Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time.  Its not new, or novel, except in ways that it is not as good.

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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'?  It is not obvious why this dictinction makes a difference.  It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).

I think the penalty is not dependent on the fee:

The miner of a large block must pay a penalty that depends on the block's size.

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


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.
donator
Activity: 2772
Merit: 1019
Can you explain a bit about the mechanism wherein the miner pays into the rollover pool, and why that is different from the 'original proposal'?  It is not obvious why this dictinction makes a difference.  It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).

I think the penalty is not dependent on the fee:

The miner of a large block must pay a penalty that depends on the block's size.

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