Meni Rosenfeld

Legendary





Offline



Activity: 2058

Merit: 1022









DonatorLegendaryActivity: 2058Merit: 1022 Elastic block cap with rollover penalties June 02, 2015, 08:16:17 PM

Last edit: June 08, 2015, 02:28:18 PM by Meni Rosenfeld #1 tl; dr: I propose replacing the hard cap on the data size of a block (1MB, 20MB, or whatever it is) with an elastic one, where resistance to larger blocks accumulates progressively. Miners will be required to pay a superlinear penalty for large blocks, to be paid into a rollover fee pool. This will greatly increase Bitcoin's robustness to a situation where the block cap is approached, and allow a healthy fee market.



Background

In these days there is heated debate about whether the block size limit of 1 MB should be relaxed. Many arguments are being discussed, but the most common one is the classic tradeoff:



Bigger blocks -> Harder to run a node -> Less nodes -> More centralization

Smaller blocks -> Less payments can be done directly as transactions on the blockchain -> More reliance on payment processing solutions involving 3rd parties -> More centralization



Most agree that there is some optimal value for this tradeoff, and the debate is about what it is, how to determine it, how to make decisions revolving it, etc. And most assume that if the blocks are too small, we'll get a "heads up" in the form of increasing tx fees.



However, should find a fee equilibrium where transaction supply matches demand, whatever they are. However, market forces don't react fast enough to fluctuations, creating buildups that technically can't be handled by the software.



Mike argues also that since we don't know when we'll reach the limit - and once we do, we will have catastrophic failure without warning - we must hurry to raise the limit to remain safe. That part I have an issue with - if Bitcoin can't gracefully degrade in the face of rising transaction volume, we will have problems no matter what the current block size limit is. We should instead focus on fixing that problem.



In this post I will introduce a protocol modification that might eliminate this problem. I will describe the suggestion and analyze how it can help. With it in place, we no longer run the risk of a crash landing, only rising fees - giving us an indication that something should be changed.



And then, we can go back to arguing what the block size should be, given the tradeoff above.



Rollover fee pool

This suggestion requires, as a prerequisite, the use of a rollover fee pool. I first introduced the concept



The original idea was that fees for a transaction will not be paid to the one miner of the block which includes it - rather, fees would be paid into a pool, from which the funds will gradually be paid to future miners. You could have, for example, that in each block, the miner is entitled to 1% of the current funds in the pool (in addition to any other block rewards).



In the current suggestion, we will use such a pool that is paid out over time - but it will not be the users who put money into the pool. Transaction fees will be paid to the miner who found the block as normal.



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.



Elastic block cap

The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.



This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). (



This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.



Analysis

I assume we do want scarcity in the blockchain - this prevents useless transactions that bloat the blockchain and make it harder to run nodes, and incentivizes users to fund the Bitcoin infrastructure. A block size limit creates scarcity - but only if there ever really are situations where we reach the limit. But as things stand, reaching the limit creates technical malfunctions.



Mike calls the problem "crash landing", but to me it's more like hitting a brick wall. Transaction demand runs towards the limit with nothing slowing it down, until it painfully slams into it. One minute there is spare room in the blocks, and no reason to charge tx fees - and the next, there's no room, and we run into problems.



If more transactions enter the network than can be put in blocks, the queue will grow ever larger and can take hours to clear, meaning that transactions will take hours to confirm. Miners can use fees to signal to the market to ease up on new transactions, but the market will be too slow to react. First, because the software isn't optimized to receive this signal; and second, because transaction demand is inelastic in short time scales. If, over sustained periods of time, transaction fees are high, I will stop looking for places to pay with Bitcoin, I will sign up to a payment facilitation service, etc. But short-term, if I have a transaction I'm set on sending right now (e.g. a restaurant tab), I'll be willing to pay very high fees for it if I must. So fees are not effective in controlling the deluge of transactions.



Enter an elastic cap. When tx demand exceeds the target block value, a backlog doesn't accumulate - miners simply include the extra in the block. They will start to require a bit of extra fees to compensate for the penalty, but can still clear the queue at the rate it is filling. If the incoming tx rate continues to increase, the marginal penalty miners have to pay per tx will increase, so fees will become higher - but since the process is more gradual, clients will be in a better position to understand what fee they need to pay for quick confirmation. The process will resemble climbing a hill rather than running into a brick wall. As we push the limits, the restoring force will grow stronger until we reach an equilibrium.



On longer time scales, the market will have an understanding of the typical fees, and make decisions accordingly. It can also analyze times of the day/week when fees are lower, and use those for any non-time-sensitive transactions.



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. With an elastic cap, a longer queue cause transaction fees to be higher, encouraging miners to include more in a block, increasing the speed at which the queue clears. This is a stable equilibrium that prevents the queue from growing unboundedly, while always maintaining some fee tension.



Incidentally, the current system is a special case of this suggestion, with f(x) = If (x<T, 0, Infinity). We assume that an invalid block is equivalent to an infinite penalty.



The way forward

I believe there is very little downside, if any, to implementing this method. It can prove useful even if the crash landing scenario isn't as grave as Mike suggests. And the primitives will be handy for other possible protocol improvements. I believe it is an essentially simple and fully fleshed-out idea. As such, I hope it can be accepted without much controversy.



It is however a major change which may require some significant coding. When discussing this idea with Gavin, he explained he'd be in a better position to evaluate it if given working, testable code. Writing code isn't my thing, though. If anyone is interested in implementing this, I'll be happy to provide support.



Related work

A similar system exists in CryptoNote, see e.g. section 6.2.3 of



Greg Maxwell proposed a similar system with variable mining effort instead of reward penalty - see e.g.



This proposal is not directly related to floating block limit methods, where the limit parameters are determined automatically based on recent history of transaction demand. In these days there is heated debate about whether the block size limit of 1 MB should be relaxed. Many arguments are being discussed, but the most common one is the classic tradeoff:Bigger blocks -> Harder to run a node -> Less nodes -> More centralizationSmaller blocks -> Less payments can be done directly as transactions on the blockchain -> More reliance on payment processing solutions involving 3rd parties -> More centralizationMost agree that there is some optimal value for this tradeoff, and the debate is about what it is, how to determine it, how to make decisions revolving it, etc. And most assume that if the blocks are too small, we'll get a "heads up" in the form of increasing tx fees.However, Mike argues , and I tend to agree, that this is not how it will work. Rather, if the block limit is too small for the transaction demand, the Bitcoin network will crash. The gist of his argument, as I see it, is - market forcesfind a fee equilibrium where transaction supply matches demand, whatever they are. However, market forces don't react fast enough to fluctuations, creating buildups that technically can't be handled by the software.Mike argues also that since we don't know when we'll reach the limit - and once we do, we will have catastrophic failure without warning - we must hurry to raise the limit to remain safe. That part I have an issue with - if Bitcoin can't gracefully degrade in the face of rising transaction volume, we will have problems no matter what the current block size limit is. We should instead focus on fixingproblem.In this post I will introduce a protocol modification that might eliminate this problem. I will describe the suggestion and analyze how it can help. With it in place, we no longer run the risk of a crash landing, only rising fees - giving us an indication that something should be changed.And then, we can go back to arguing what the block size should be, given the tradeoff above.This suggestion requires, as a prerequisite, the use of a rollover fee pool. I first introduced the concept here - this post is worth a read, but it used the concept for a different purpose than we have here.The original idea was that fees for a transaction will not be paid to the one miner of the block which includes it - rather, fees would be paid into a pool, from which the funds will gradually be paid to future miners. You could have, for example, that in each block, the miner is entitled to 1% of the current funds in the pool (in addition to any other block rewards).In the current suggestion, we will use such a pool that is paid out over time - but it will not be the users who put money into the pool. Transaction fees will be paid to the miner who found the block as normal.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.The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). ( graph This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.I assume we do want scarcity in the blockchain - this prevents useless transactions that bloat the blockchain and make it harder to run nodes, and incentivizes users to fund the Bitcoin infrastructure. A block size limit creates scarcity - but only if there ever really are situations where we reach the limit. But as things stand, reaching the limit creates technical malfunctions.Mike calls the problem "crash landing", but to me it's more like hitting a brick wall. Transaction demand runs towards the limit with nothing slowing it down, until it painfully slams into it. One minute there is spare room in the blocks, and no reason to charge tx fees - and the next, there's no room, and we run into problems.If more transactions enter the network than can be put in blocks, the queue will grow ever larger and can take hours to clear, meaning that transactions will take hours to confirm. Miners can use fees to signal to the market to ease up on new transactions, but the market will be too slow to react. First, because the software isn't optimized to receive this signal; and second, because transaction demand is inelastic in short time scales. If, over sustained periods of time, transaction fees are high, I will stop looking for places to pay with Bitcoin, I will sign up to a payment facilitation service, etc. But short-term, if I have a transaction I'm set on sending right now (e.g. a restaurant tab), I'll be willing to pay very high fees for it if I must. So fees are not effective in controlling the deluge of transactions.Enter an elastic cap. When tx demand exceeds the target block value, a backlog doesn't accumulate - miners simply include the extra in the block. They will start to require a bit of extra fees to compensate for the penalty, but can still clear the queue at the rate it is filling. If the incoming tx rate continues to increase, the marginal penalty miners have to pay per tx will increase, so fees will become higher - but since the process is more gradual, clients will be in a better position to understand what fee they need to pay for quick confirmation. The process will resemble climbing a hill rather than running into a brick wall. As we push the limits, the restoring force will grow stronger until we reach an equilibrium.On longer time scales, the market will have an understanding of the typical fees, and make decisions accordingly. It can also analyze times of the day/week when fees are lower, and use those for any non-time-sensitive transactions.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. With an elastic cap, a longer queue cause transaction fees to be higher, encouraging miners to include more in a block, increasing the speed at which the queue clears. This is a stable equilibrium that prevents the queue from growing unboundedly, while always maintaining some fee tension.Incidentally, the current system is a special case of this suggestion, with f(x) = If (x https://cryptonote.org/whitepaper.pdf Greg Maxwell proposed a similar system with variable mining effort instead of reward penalty - see e.g. http://sourceforge.net/p/bitcoin/mailman/message/34100485/ for discussion.This proposal is not directly related to floating block limit methods, where the limit parameters are determined automatically based on recent history of transaction demand. bitcoin-otc WoT

- Exchange bitcoins for ILS (thread)

Analysis of Bitcoin Pooled Mining Reward Systems (thread, 1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr | Who am I? Bitcoil - Exchange bitcoins for ILS ( thread ) | Israel Bitcoin community homepage summary ) | PureMining - Infinite-term, deterministic mining bond

lechango



Offline



Activity: 14

Merit: 0







NewbieActivity: 14Merit: 0 Re: Elastic block cap with rollover penalties June 02, 2015, 09:09:16 PM #2 This is a very good, but as you said will require a lot of work, seems like a good portion of BTC's code would need to be rewritten. I'd say we're better off just letting BTC croak and eventually once the damage that is caused to public image has faded, transitioning to a better alt will be in the best interest of the whole cryptocurrency community.

ArticMine



Offline



Activity: 2268

Merit: 1041





Monero Core Team







LegendaryActivity: 2268Merit: 1041Monero Core Team Re: Elastic block cap with rollover penalties June 02, 2015, 09:12:50 PM #3 The key here is how is T set. If T is fixed then 2T becomes the hard limit and the problem remains. If T is set based on an some average of previously mined blocks then this may address the problem Concerned that blockchain bloat will lead to centralization? Storing less than 4 GB of data once required the budget of a superpower and a warehouse full of punched cards. https://upload.wikimedia.org/wikipedia/commons/8/87/IBM_card_storage.NARA.jpg https://en.wikipedia.org/wiki/Punched_card

binaryFate



Offline



Activity: 1456

Merit: 1001





Still wild and free







LegendaryActivity: 1456Merit: 1001Still wild and free Re: Elastic block cap with rollover penalties June 02, 2015, 09:49:39 PM #6 Isn't it precisely what is implemented in Monero? (except you don't have a rollover pool, the penalty is simply deducted from the block reward for good).

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's.

This makes Monero a better candidate to deserve the term "digital cash".

leopard2



Offline



Activity: 1371

Merit: 1011









LegendaryActivity: 1371Merit: 1011 Re: Elastic block cap with rollover penalties June 02, 2015, 09:52:25 PM #7



So, I support the idea. Just that 2T is a bit high, will that work? I mean, will it be possible to download a blockchain with 2T blocks in it? A 2T blockchain consisting of smaller blocks is not an issue, but what happens if the download gets stuck DURING the 2T?



Is the Bitcoin client ready to download blocks partially and continue after a crash/shutdown/process kill?

I think (in contrast to global politics) we should follow the most intelligent people, and Meni is certainly smarter than most people here.So, I support the idea. Just that 2T is a bit high, will that work? I mean, will it be possible to download a blockchain with 2T blocks in it? A 2T blockchain consisting of smaller blocks is not an issue, but what happens if the download gets stuck DURING the 2T?Is the Bitcoin client ready to download blocks partially and continue after a crash/shutdown/process kill? Truth is the new hatespeech.

digicoin



Offline



Activity: 1106

Merit: 1000









LegendaryActivity: 1106Merit: 1000 Re: Elastic block cap with rollover penalties June 02, 2015, 10:18:17 PM #9 Oh Monero solution to block size limit



Block size limit is not important in the discussion.



The important is



+ Too many people don't understand block size and block size limit is

+ Political discussions: bitcoin for everybody or for elites only (lots of people try to ignore where bitcoin network effect comes from)

+ Group interest

+ Boys crying wolf: Viacoin, Blockstream devs

bitcoinfees



Offline



Activity: 4

Merit: 0







NewbieActivity: 4Merit: 0 Re: Elastic block cap with rollover penalties June 03, 2015, 02:34:26 AM #12



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.) Just a comment on the following: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.)

tacotime



Offline



Activity: 1484

Merit: 1004









LegendaryActivity: 1484Merit: 1004 Re: Elastic block cap with rollover penalties June 03, 2015, 03:09:57 AM

Last edit: June 03, 2015, 03:38:29 AM by tacotime #13 Quote from: Meni Rosenfeld on June 02, 2015, 10:10:53 PM Quote from: binaryFate on June 02, 2015, 09:49:39 PM Isn't it precisely what is implemented in Monero? (except you don't have a rollover pool, the penalty is simply deducted from the block reward for good).

No idea what happens in Monero, but if so, more power to them. No idea what happens in Monero, but if so, more power to them.

Yes. There is a quadratic penalty imposed for blocks above the median size (with a maximum size of 2 * median(size of last 400 blocks)), with a dynamic, elastic block sizing algorithm. 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.



See section 6.2.3 of the CryptoNote whitepaper:



It was one of the most criticized components by the Bitcoin core developers, but so far testing on the mainnet and testnet has failed to evidence any failures.



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. Yes. There is a quadratic penalty imposed for blocks above the median size (with a maximum size of 2 * median(size of last 400 blocks)), with a dynamic, elastic block sizing algorithm. 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.See section 6.2.3 of the CryptoNote whitepaper: https://cryptonote.org/whitepaper.pdf It was one of the most criticized components by the Bitcoin core developers, but so far testing on the mainnet and testnet has failed to evidence any failures.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. Code: XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns

Bitcoin Betting Guide



Offline



Activity: 190

Merit: 100







Full MemberActivity: 190Merit: 100 Re: Elastic block cap with rollover penalties June 03, 2015, 03:13:59 AM #14



Quote We still need some way to determine the optimal block size, but we have much more leeway. The wrong choice will not cause catastrophic failure

Fantastic, we can just take our best guess without pulling our hair out with worry of what disasters will insure if the guess is wrong. Perhaps 8mb + 20% per year elastic cap where those values can be adjusted with a soft fork.



What if the rollover fee could become the full node reward? By George you have done it old boy! This solves so many problems.Fantastic, we can just take our best guess without pulling our hair out with worry of what disasters will insure if the guess is wrong. Perhaps 8mb + 20% per year elastic cap where those values can be adjusted with a soft fork.What if the rollover fee could become the full node reward? The world's best source of crypto gambling information. Helping bettors win crypto! https://bitedge.com

gmaxwell

Legendary





Offline



Activity: 3178

Merit: 4301









ModeratorLegendaryActivity: 3178Merit: 4301 Re: Elastic block cap with rollover penalties June 03, 2015, 04:31:48 AM #15 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.

That is the main aspect of what monero/bytecoin does that I complained about-- that you can simply pay fees out of band and bypass it as the subsidy declines (even with the constant inflation the subsidy might be inconsequential compared to the value of the transactions if the system took off). In Bitcoin this is not hypothetical since 2011 at least pools have accepted out of band payments and its not unusual for varrious businesses to have express handling deals with large pools; and this is absent any major reason to pull fees out of band.



My proposal (on bitcoin-development and previously on the forum) is effectively (and explicitly credited to) the monero/bytecoin behavior, but rather than transferring fees/subsidy it changes the cost of being successful at the work function.



I haven't had a chance yet to read and internalize the specifics of what Meni is suggesting (or rather, I've read it but the complete, _precise_ meaning isn't clear to me yet). The main things to watch out for solutions of this class are (1) bypass vulnerability (where you pay fees, or the like, out of band to avoid the scheme) and (2) scale invariance (the scheme should work regardless of Bitcoin's value). My proposal used effort adjustment (it's imprecise to call it difficulty adjustment, though I did, because it doesn't change the best chain rule; it just changes how hard it is for a miner to meet that rule).



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.



Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written. That is the main aspect of what monero/bytecoin does that I complained about-- that you can simply pay fees out of band and bypass it as the subsidy declines (even with the constant inflation the subsidy might be inconsequential compared to the value of the transactions if the system took off). In Bitcoin this is not hypothetical since 2011 at least pools have accepted out of band payments and its not unusual for varrious businesses to have express handling deals with large pools; and this is absent any major reason to pull fees out of band.My proposal (on bitcoin-development and previously on the forum) is effectively (and explicitly credited to) the monero/bytecoin behavior, but rather than transferring fees/subsidy it changes the cost of being successful at the work function.I haven't had a chance yet to read and internalize the specifics of what Meni is suggesting (or rather, I've read it but the complete, _precise_ meaning isn't clear to me yet). The main things to watch out for solutions of this class are (1) bypass vulnerability (where you pay fees, or the like, out of band to avoid the scheme) and (2) scale invariance (the scheme should work regardless of Bitcoin's value). My proposal used effort adjustment (it's imprecise to call it difficulty adjustment, though I did, because it doesn't change the best chain rule; it just changes how hard it is for a miner to meet that rule).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.Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.

goatpig



Offline



Activity: 2646

Merit: 1172



Armory Developer







LegendaryActivity: 2646Merit: 1172Armory Developer Re: Elastic block cap with rollover penalties June 03, 2015, 05:17:58 AM #16 I personally think a P2P network cannot rely on magic numbers, in this case 1MB nor 20MB blocks. The bar is either set too low and it creates an artificial choke point, or it is set too high which opens room for both DOS attacks and more centralization. As such, a solution that pins block size to fees is, in my point of view, the most sensible alternative to explore. Fees are the defacto index to determine transaction size and priority, so they are also the best candidate to determine valid block size.



However I have a couple divergence with Meni's proposal:



First, while I find the fee pool idea intriguing, and I certainly see benefits to it (like countering "selfish" mining), I don't believe it is a necessary device to pin block size limits to fees. Simply put, I think it's a large implementation effort, or if anything a much larger one than is needed to achieve the task at hand. It also requires modifying, or at least amending consensus rules, something the majority of the Core team has been trying to keep to a minimum. I believe there is wisdom in that position.



Second, I expect a fee pool alone will increase block verification cost. If it is tied to the block size validity as well, it would increase that cost even further. The people opposing block size growth base it on the rationale that an increase in resource to propagate and verify blocks effectively raises the barrier to entry of the network, resulting in more centralization. This point has merits and thus I think any solution to the issue needs to keep the impact on validation cost as low as possible.



Meni's growth function still depends on predetermined constants (i.e. magic numbers), but it is largely preferable to static limits. Meni wants to use it to define revenue penalties to miners for blocks larger than T.



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.





https://btcarmory.com

edmundedgar



Offline



Activity: 352

Merit: 250





https://www.realitykeys.com







Sr. MemberActivity: 352Merit: 250https://www.realitykeys.com Re: Elastic block cap with rollover penalties June 03, 2015, 06:56:07 AM

Last edit: June 03, 2015, 07:13:02 AM by edmundedgar #18 If we're making drastic changes it may be worthwhile to target balance of unspent outputs instead of / as well as block size, since UTXO size seems to be a more likely bottleneck than the network, unfortunate American core devs still connected to the internet using 1870s-style copper wires notwithstanding.