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

Unlike Meni's suggestion, the reduction in block subsidy is not given to a pool but rather deferred to future miners because the subsidy algorithm is based around the number of coins.

Well, the pool does have the ultimate effect of deferring rewards to future miners.

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

See section 6.2.3 of the CryptoNote whitepaper: https://cryptonote.org/whitepaper.pdf

Interesting. I argue that regardless of other issues, the particular function they suggest is not optimal, and the cap it creates is too soft.

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.

Of course, if you'd like to post this criticism on that thread, I'll be happy to discuss it.

Quote from: bitcoinfees on June 03, 2015, 02:34:26 AM

Just a comment on the following:

Quote

With a hard cap, the queue of transactions can only clear at a specific rate. Below this rate there is no fee tension, and above it there is instability.

I don't think you can say that - that would be like saying, queues are never a problem as long as utilization is < 1 (which of course is required for stability). But long queues do in fact develop when utilization is < 1, due to variability in service / arrival times (re: bitcoin, the dominant source of variability is in inter-block times).

As long as there are queues, fee tension will be present, as mempool transactions are largely prioritised by feerate. Empirically, we are observing periods of fee tension (i.e. busy periods, when pools' max block size is reached) quite often these days.

Otherwise I like this perspective on the block size problem (even though I can't really comment on the proposed solution), in particular the observation that in the short term transaction demand is inelastic. (Upon further thought, however, proponents of increasing block size would say that the inelastic demand problem doesn't really apply if the block size cap is sufficiently higher than the average transaction rate.)

That's true in general; however, for the specific time scales and fluctuations in queue fillrate we have here, I'd say that "no fee tension" may be an exaggeration, but captures the essence.

Sure, if the block limit is high enough we can always clear transactions... But then there will be little incentive to give fees or conserve space on the blockchain. The post assumes that we agree that too low is bad, too high is bad, and we don't want to be walking a thin rope in between.

Quote from: gmaxwell on June 03, 2015, 04:31:48 AM

(1) bypass vulnerability (where you pay fees, or the like, out of band to avoid the scheme)

I don't think this is an issue here. Transaction fees are paid instantly in full to miners, so users have no reason to pay fees out of band. Miners are forced by protocol to pay the penalty if they want to include the transactions (and if they don't include the transactions, they're not doing anything they could be paid for). You could talk about miners paying penalty into the pool hoping to only get it back in future blocks, but with a pool that clears slowly enough, that's not a problem.

Quote from: gmaxwell on June 03, 2015, 04:31:48 AM

(2) scale invariance (the scheme should work regardless of Bitcoin's value).

In the space of block sizes, you do need to occasionally update the parameter to match the current situation. I think it's best this way - currently only humans can reliably figure out if the fees are too high or node count is too low. But if a good automatic size adjustment rule can be found, it can be combined with this method.

In the space of Bitcoin value, transaction fees and hardware cost, the proposed function is multi-scaled and thus cares little about all of that. For any combination of the above, the function will find an equilibrium block size for which the penalty structure makes sense.

Quote from: gmaxwell on June 03, 2015, 04:31:48 AM

I think this kind of proposal is a massive improvement on proposals without this kind of control; and while it does not address all of the issues around larger blocks-- e.g. they do not incentive align miners and non-mining users of the system-- it seems likely that proposals in this class would greatly improve a some of them of them; and as such is worth a lot more consideration.

I'm still hoping Red Balloons, or something like it, will solve that problem.

Quote from: gmaxwell on June 03, 2015, 04:31:48 AM

Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.

Thanks, and likewise - I've only recently heard about your effort-penalty suggestion, I hope to be able to examine it and do a comparison.

Quote from: gmaxwell on June 03, 2015, 05:55:35 AM

Quote from: goatpig on June 03, 2015, 05:17:58 AM

I expect a fee pool alone will increase block verification cost.

It would not, in any meaningful way.

Right, the proposal here only adds a constant amount of calculations per block, taking a few microseconds. It doesn't even grow with the number of transactions.

Quote from: goatpig on June 03, 2015, 05:17:58 AM

I would scrap the fee pool and use the function the opposite way: the total sum of fees paid in the block defines the maximum block size. The seeding constant for this function could itself be inversely tied to the block difficulty target, which is an acceptable measure of coin value: i.e. the stronger the network, the higher the BTC value, and reciprocally the lower the nominal fee to block size balance point.

With an exponential function in the fashion of Meni's own, we can keep a healthy cap on the cost of larger blocks, which impedes spam by design, while allowing miners to include transactions with larger fees without outright kicking lower fee transactions out of their blocks.

As Meni's proposal, this isn't perfect, but I believe it comes at the advantage of lower implementation cost and disturbance to the current model, while keeping the mechanics behind block size elasticity straight forward. Whichever the community favors, I would personally support a solution that ties block size limit to fees over any of the current proposals.

This is similar to the idea of eschewing a block limit and simply hardcoding a required fee per tx size. The main issue I have with this kind of ideas is that it doesn't give the market enough opportunity to make smart decisions, such as preferring to send txs when traffic is low, or to upgrade hardware to match demand for txs.

Another issue with this is miner spam - A miner can create huge blocks with his own fee-paying txs, which he can easily do since he collects the fees.

Using difficulty to determine the size/fee ratio is interesting. I wanted to say you have the problem that difficulty is affected not only by BTC rate, but also by hardware technology. But then I realized that the marginal resource costs of transactions also scales down with hardware. The two effects partially cancel out, so we can have a wide operational range without much need for tweaking parameters.