Topic: Proposal: dynamic max blocksize according to difficulty (Read 3072 times)

Your approach is like BIP Upal. Unfortunately miners can manipulate the metrics involved: tx per block and sum(tx fees). So I think these types of proposals are of no use. We might as well go directly to BIP100 to see what miners really want.

Again, if miners can be coerced into only accepting tx that have appeared it the mempool somehow this might work, but I cannot think of a way to enforce this.

i dont think blockchain usage always add up at the same speed with the difficulty rise.

i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1  to a max of 32.

EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation

I hope you realize that polls of this type are of no use. For a hard fork to work it must be based on consensus. Consensus is a very dynamic process, it can change by the minute. First ideally core devs must arrive to it somehow (and even then miners have to accept the changes). If that doesn't happen, several implementations of the bitcoin core will appear (Bitcoin XT is the first). Then miners will start using them if they think they are superior without immediately causing a fork (as in Bitcoin XT that takes a super majority of 75% having mined with it). When the forking actually happens, the minority will be forced to join the majority unless they stubbornly refuse because of ideological concerns. In this case their blockchain will be supporting a weaker new altcoin (its price will plummet because the ones having funds on both coins will sell the weak one in favor of the strong one).

Thanks anyway.

Most of the proposal are all subjective to much further discussion and test  and all must agree with the one that is most reliable.

This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers

That is why after thinking a bit more, the max blocksize increases according to difficulty must factor in the current subsidy coming from the block reward by coinbase. I thought of 100% when we reach 0 BTC per block (in 2140) and 75% now at 25 BTC per block. But I realize this is very arbitrary. Then again all other proposals out there are even more arbitrary.
Very true and it is very likely that as difficulty increases, the risk for orphaned blocks becomes more significant, specially when the block reward subsidy goes down. So in the end maybe this whole problem about increasing the max block size is overblown. I am tending to think now, lets just go to hard fork to 8MB and kick the can for a long term solution, to several years from now.
Sorry I misstated what I meant to say. What I meant is if we could force the miners to only include transactions seen in the mempool (not ALL transactions), so that miners cannot include bogus tx that only pay fees to themselves with the purpose of manipulating the discussed metrics.  But I cannot think of any way to do this, basically because different nodes can have different sets of transactions in their mempool because it is designed that new transactions that will cause a double spend be discarded.

OK, but does this look correct to you? : some pools got the finder fee + a few transactions and moved on, while people were crying on forum(s) that their transaction is stuck for .. days, though they paid the normal fee or even more in some cases (certainly I don't care about the transactions tried out with 0 fee, those are on their own risk).

So while some miners / pools played fair, some not. And this is something that has to be fixed / enforced.


And then the "spam attacks" or "test" like done not that long ago should not cause so much trouble. And then they could stop (because if nobody notices, it's costly, and boring, and useless).

Higher price commands higher difficulty. The other way around is not true. You cannot deduce price has increased because difficulty went up. The only thing it means is that profitability per hash has increased. A wealth of factors can affect that, not just price.

An increase in price itself does not equate to an increase in block space demand. The tps can go up when price goes down and vice versa. There is no economic evidence of the contrary.

Your proposal has to account for situations when reality contradicts the meaning you give your indicators. I agree that in general, in the absence of a coinbase reward, a growth in difficulty will mean an increase in fee subsidy, and thus block space demand.

However, that does not always stand true, and you need a contingency plan for when that is the case. This is actually a pretty uncommon situation right now, as fee subsidy are about 1% of miner revenue. How much of a solution is your proposal if it only works when the stars align? Some people choose to discuss proposals for the now, others prefer to work on solutions that can also withstand the absence of inflation. However at this rate, you are designing a solution that will only start to make sense in some 20 odd years.


Not really. The emergence of relay networks and IBLT largely increases the cost of these attacks. To fake transaction volume under these conditions means a miner needs to emit txs to himself to recover its own fees. The implies they can't publish these transactions publicly until they are mined, or other miners will pick them up and end making the ill intentioned miner actually pay for the attack. However, relay networks and IBLT produce a coding gain in block propagation by forwarding block content before a solution is found, i.e. each miner is telling others what tx set they are working on.

A miner deliberately slowing down his propagation is exposing himself to a lot of natural orphaning, and past a certain point, he is so easy to identify and such a nuisance that other miners have motivation to just out right orphan him on purpose. Add a decay function on top of it and not only miners will have to pay for spam attacks like any other spammer, but their effort will also be lost in the mid term, as the decay function will correct the effect of the attack.


That's inane. the first and best spam filter is letting miners pick transactions based on economic factors. As long as the incentives are not completely warped, this system works. What you are proposing is making any tx spam attack completely trivial. It would also make DoS attacks by high OPs count and low size tx very effective. A lot more than currently, as they can easily be thwarted by their own nature: low miner profit.

Thanks again for replying.

Remember that currently the market for transactions is distorted severely because of the block reward subsidy. As it goes down, transactions fees become much more significant and will further force the miner to consider which transaction to add to his block. More hashing power makes the bitcoin network stronger, so everyone benefits. More users can lead to increase of bitcoin price, etc

Unfortunately we cannot use transaction data (volume, fees etc) or block sizes as a metric because these can be manipulated by the miners themselves leading to tragedy of commons scenarios. UTXO sizes can also be manipulated with fake transactions. But if we could some how force the miners to always include transactions that had appeared it the mempool, or at least make it a risk not too then this problem would be solved.

Again there is no link between increased hash rate and block space demand. If a new ASIC tech is unleashed on the market tomorrow, why would transaction volume go up? Your local bank gets a new paint job, a larger parking lot, a McD right next to it and a larger safe, and your reaction is "ima purchase more goods and services"? Where is your extra purchasing power coming from? Isn't the fact that your bank is upgrading the result of the fees it's been charging its customers? What leads you to believe said customer are somehow wealthier as a result of this? If anything, shouldn't it be the opposite?

You have demonstrated yourself that if your algorithm was applied from day one, the current block size would be completely bloated and unrealistic. Your argument for supporting your method is that ASIC technology has caught up to its technological debt and is now dependent on Moore's law.

The implication is simple: difficulty growth is only a valid metric within certain bounds (that's your proposition, not mine, I'm just deducing). So again, how does your algorithm deals with situations where difficulty grows outside of its "healthy" bounds?


That's not my point. My point is Intel is not building Bitcoin ASIC miners right now. If Bitcoin's market cap grows big enough for Intel to start building mining hardware, chances are difficulty will be growing much faster than Moore's law dictate for a few extra years.


The fee market is not an end in and of itself. It is a mean to support certain network mechanics, one of which is to pay miners enough to have acceptable blockchain security. Not just security, but high enough that it is more profitable for a brute force attacker to just mine blocks than to try and rewrite block history.

You should design your proposal with the purpose of the fee market as your goal, not to simply sustain any fee market.


There are plenty of other metrics in the blockchain to represent block space demand. Over a difficulty period consider total fees paid, average fee density, UTXO set, total value transfered, average value per UTXO, straight up average block size. Plenty of stuff to get creative with.

If this can be done, I'd propose to be done for real. Because if you say so, they may or may not believe you. Instead, if they indeed see this happening (blocks found, then rejected/orphaned) they'll stop playing with fire.

I have thought about this.

We can publish a bitcoin node that does not relay *new* blocks which have a certain percentage of transactions that were never seen in the mempool, and also blocks that are not near max blocksize if there are still many transactions with fees pending in the mempool. 

This will make miners very very afraid to mine mini blocks or with fake transactions (transactions that were never released to the mempool) since the risk of having their block orphaned increases exponentially against other miners who do mine the transactions that were in the mempool. This bitcoin node doesn't even have to be running, just the idea that it might be out there would be very frightening to miners.

When the hash rate increases because of new ASIC, the difficulty rises, this will allow for the max block size to increase. This increases supply so transaction fees go down, which will cause an increase in block space demand. All of which if you think it over, it makes sense. The bitcoin network has gotten stronger because of a massive increase of hash rate due to new ASIC, therefore it stands to reason it should support more transaction throughput.
Intel has been around for decades, bitcoin only 6 years, of which 3 has shown dramatic growth.
It doesn't matter really at which rate block space demand grows. If it grows slowly, then transaction fees stay low and investment in mining will be low.
Unfortunately we don't have any other metric to determine the max blocksize. All the other proposals so far only arbitrarily set this limit, or in the case of BIP 100 it gives the miners a way to set it via voting which the more I think about it, the more I tend to believe its a terrible idea.

I really appreciate your input. I have been obsessing over my solution for this max blocksize conundrum and I really think it is the best one by far.

Dynamic sizing is better then, because a successful implementation should cover all eventualities. If Lightning, and every other attempt at an overlay network, fail, then on-chain will be there. It's likely that all competing methods will find a balance, as long as the incentives are appropriately structured. It's a big ask though, I won't deny that.

Right, I've looked into it. It seems like instead of taking the necessary steps to outfit Bitcoin, nodes and miners with the ability to handle VISAs volume of transactions, we should just do transactions off-chain and trust Hubs? I don't believe this was a part of the creator's vision for bitcoin. Transactions large and small are supposed to be affordable to do on the blockchain, and if Lightning is adopted it would only be because of altruism or it is too expensive for people to use the blockchain.

Is this what we want? This all creates complications that people are fearful of.

Like keeping the internet strictly HTML forever in 2000 because most people only had 56k?

In addition, the "larger" Bitcoin becomes, the more incentive exists for any company that deals with money (I would assume most do) to invest in it remaining capable of handling transaction volume. This means dedicated internet connections for nodes and things of that nature. A business that deals with credit card processors, for example, save 3% a year, which can be put back into the business and increase the next years profits.

But I also believe Satoshi was correct in saying "I suspect we need a better incentive for users to run nodes instead of relying solely on altruism." Last month.

1. I think that first we need to force the miners don't "run away" with finder's fee and a few transactions confirmed when there are old transactions waiting and max (current) size not filled yet.
This is a much bigger problem than block size, because the block size doesn't matter at all if miners don't use it well.

2. Then, maybe the block size could be adjusted - with some smart formula - to be bigger only when bigger is needed (edit: meaning when there are old transactions waiting for more than a certain time). So a "smart" BIP1xx.

Generally this kind of proposals cannot function without a second factor, which is meant to define a resizing threshold.

How is your code supposed to distinguish between the release of a new ASIC and actual growth in block space demand?


Not necessarily. Consider that Intel is a $55B business whereas the Bitcoin as a whole has a $3~4B market capitalization. We're not yet at a stage where professional chip manufacturers have an incentive to build ASICs.

And generally, what makes you believe block space demand will grow at least at the same pace as Moore's Law?

Your proposal has no thresholds. It simply links block size evolution to difficulty. I believe difficulty changes are a good metric to define by how much the block size should be changed, but difficulty is not a good enough metric to reflect block size demand.

You need another factor to track block size demand, and use that as a trigger for resizing. On top of that, a decay function would be preferable for when the resizing condition doesn't trigger. That's a safety harness that will correct the effect of spam attacks, large miners trying to game the system, and too large a jump in block ceiling.

That's as it may be, but the other camp are far worse: the only significant supporters of BIP101 are commercial companies like Circle and Bitpay, who are variously funded by:

• Goldman Sachs
• Moneygram
• Lightspeed Ventures (the company behind Ripple)

I know there are even more dubious interests involved with the BIP101 supporters, I will be researching it some time soon.



Blockstream are developing a whole range of ideas besides Lightning, any of which could become a competitor to Lightning, and so many more that have got nothing to do with scaling. Not only do the other contingents have no proposals like this on the table, but their main supporters have been "bought out" as you say by manifestly pernicious interests.

Bitcoin is about financial and monetary freedom, and that's not what Moneygram and Goldman Sachs are about.

No, far from it. I suggest you seriously look into it.

FWIW isn't Lightning Network a band-aid solution?