Quote from: goatpig on June 03, 2015, 08:22:10 PM

...

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

Quote from: jonny1000 on June 03, 2015, 10:47:16 PM

Quote from: Meni Rosenfeld on June 03, 2015, 07:39:38 AM

Quote from: tacotime on June 03, 2015, 03:09:57 AM

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.

Quote from: johnyj on June 03, 2015, 11:19:50 PM

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.

Quote from: DumbFruit on June 04, 2015, 01:51:27 PM

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.

Quote from: NewLiberty on June 04, 2015, 04:32:01 PM

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

Quote from: NewLiberty on June 04, 2015, 04:32:01 PM

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

Quote from: NewLiberty on June 04, 2015, 05:41:22 PM

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.

Quote from: NewLiberty on June 04, 2015, 06:24:02 PM

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.

Quote from: NewLiberty on June 04, 2015, 06:24:02 PM

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

Quote from: NewLiberty on June 04, 2015, 04:32:01 PM

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

Quote from: NewLiberty on June 04, 2015, 05:41:22 PM

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.