[2016-01-07] A Simple, Adaptive Block Size Limit

[LiteCoinGuy]

A Simple, Adaptive Block Size Limit

The block size limit is a consensus rule. If a block is larger than this limit, miners won’t incorporate it into the chain they are building. If a miner produces a block that isn’t incorporated into the chain by a majority of miners, it will be orphaned and the miner that produced the block will receive no compensation for their work. While Bitcoin could work without a preset fixed limit, that would leave a lot of uncertainty for miners. It is useful for miners to know the limit that is observed by a majority of the mining power and that we have a clear and simple consensus rule for it.

https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.s764hrull



best idea. never again a discussion about it.

[HostFat]

Good idea

[rav3n_pl]

This is BEST way to raise block limit.
We need it, like we need SegWit.
It should be rolled ASAP, but code need upgrade to v14: https://github.com/bitpay/bitcoin/issues/42

[Carlton Banks]

Easily gamed with a Sybil attack (attacker floods the Bitcoin network with nodes voting for whatever they want to force)

And the miners would conduct the attack, then approve the blocksize they chose. No different to any of the other flawed dynamic/adaptive systems, just with a different name to describe the technique.

No. Thanks.

[Kprawn]

The miners will never go for this, because they re riding the extra fees that are being generated now from the indecision about SegWit & BU. We

already gave them a taste for this "extra" high fees... so they will just milk this to the last drop... even if it destroys Bitcoin in the process. These

greedy MF's rule decisions and cost for the users using this technology. 

[rav3n_pl]

Easily gamed with a Sybil attack (attacker floods the Bitcoin network with nodes voting for whatever they want to force)

And the miners would conduct the attack, then approve the blocksize they chose. No different to any of the other flawed dynamic/adaptive systems, just with a different name to describe the technique.

Well, no.
This code is pushing max block size to protocol level, it is calculated from last block sizes. Miners can not decide to raise it further, also have to accept all blocks within limit (like it is now).

[Carlton Banks]

it is calculated from last block sizes

So transaction flooding is the attack then. Game theory fail.


If we'd been doing this for the last 2 years, the spam attackers would be pushing the size up instead.


Blocksize is and always has been a constant, changing that is foolish. If there is no upper overall limit, it's dangerous that it will be gamed until the Bitcoin blockchain becomes too big to download to keep it's distribution decentralised.

If there is an upper limit, you may as well make that limit the blocksize anyway, as it will still be gamed with spam flooding until it reaches that upper absolute limit.


Game. Theory. Fail.

[rav3n_pl]

There always be risk of spam attack. This is why 1MB limit was introduced in 1st place. But it was at point, where block are like 1-10kb.
At this point, 1MB limit is just way to squeeze more fees from bitcoin users.

[Carlton Banks]

Spam attack is more serious under this proposal. It can be used to push the blocksize up according to malign intent, not natural demand.


Game theory fail, it's dead in the water my friend.

[ArticMine]

As someone has has been working very closely on the Monero adaptive blocksize limit and fee structure, I must comment on this .

This is essentially the adaptive blocksize limit in Monero with two critical safety and security measures removed.
1) No penalty to increase the blocksize above the median. Monero imposes a quadratic penalty to a maximum of the base block reward for a block that is 2x the median.
2) No tail or minimum base block reward. Monero has a minimum 0.6 XMR per block base reward in perpetuity. This is approximately equivalent to 3 XBT per block in the case of Bitcoin.  Monero uses 2 min blocks vs 10 min blocks in Bitcoin.

To provide an idea of the ramifications here. In Monero the per byte fees are actually proportional to the (base reward) / (effective median blocksize). This is a direct result of the blocksize scaling penalty. This works in Monero because of the  minimum base block reward. In Bitcoin on the other hand the total fees per block will fall to zero along with the base reward creating little or no incentive for the proof of work.

Ethereum mentioned in the article also has at least the option in their social covenant to have a minimum base block reward. So this approach can also work in Ethereum.

There is a reason why many in the Bitcoin community are opposed to adaptive blocksize limits in Bitcoin. They are very concerned  with securing Bitcoin once the base block reward becomes minimal.

Edit: The above would also apply to other coins with a fixed number of coins such as Litecoin, Dash, ZCash, Ethereum Classic etc. On the other hand Dogecoin could go this route and even the venerable demurrage Freicoin could also go this route.

[d5000]

You won't believe it, but here I agree with Carlton Banks. It's too easy to game it. The Monero variant is better, but doesn't stop long-lasting spam attacks by large miner groups (the attacks won't cost them much if some of them collude).

I continue to prefer BIP 100-based solutions for a compromise, or BIP 102 (2 MB)+Segwit for a temporary fix that could even be enough for the next 5 years or so.

[rav3n_pl]

SegWit is necessary to finally fix all malleability issues. It also open sidechains, lighting etc - stuff that can scale bitcoin.
BUT before all this happen, we need some easy but permanent fix for scaling w/o SegWit. Adaptive block size is doing it once and for ever. Raising to 2MB is not final answer, it may need change in future.
Also, because of BTC value spam attack for 2 weeks to raise limit is really unlikely, because of cost.
Remember: 1MB limit was introduced by Satoshi ONLY as temporary protection, and it was set 10x-100x real needs. ABS is setting limit only 3x actual needs.

[ArticMine]

You won't believe it, but here I agree with Carlton Banks. It's too easy to game it. The Monero variant is better, but doesn't stop long-lasting spam attacks by large miner groups (the attacks won't cost them much if some of them collude).

I continue to prefer BIP 100-based solutions for a compromise, or BIP 102 (2 MB)+Segwit for a temporary fix that could even be enough for the next 5 years or so.

Actually spam attacks by large miner groups is not the issue here. There is no incentive for miners to bloat the blocksize in this fashion in Monero since miners actually profit from the penalty. This kind of attack works against a fixed blocksize in order to drive fees up and it does not require a significant proportion of the hashrate if the blocks are already full with transactions. The real issue is long term insecurity, with miner rewards including fees falling to zero.

Unless one is prepared to violate the Bitcoin social covenant in a drastic manner such as for example:
1) Violating the 21,000,000 XBT limit by introducing a minimum block reward or
2) Introducing demurrage
Monero like blocksize scaling variants are a prescription for disaster over time in Bitcoin.

Edit: For the record I run Bitcoin core on my full Bitcoin node, and as a consequence I am well aware of the impact on bandwidth of spam attacks against the Bitcoin mempool.

[Carlton Banks]

You won't believe it, but here I agree with Carlton Banks. It's too easy to game it.

It's because I actually am using reason to form my observations. I have no need to make references or contrasts to/with people's internet pseudonym's in order to state my case, reason does the job better.


And you're still wrong about blocksize increases because of reason, not because my name's Carlton and your name's d5000.


Blocksize changes are not a way change the scale of transaction rate, blocksize changes alter the resources the Bitcoin network needs to run, which defies the definition of scaling. All blocksize increases come with a series of risks attached, 4MB Segwit included.


On-chain should be expanded, but using actual scaling improvements, like improving the way transactions are encoded.

[Carlton Banks]

Actually spam attacks by large miner groups is not the issue here. There is no incentive for miners to bloat the blocksize in this fashion in Monero since miners actually profit from the penalty.

Can you not read? Why the fuck should I waste my time and that of others repeating this in the same thread


You're forgetting something important: what if a miner wants Bitcoin to become screwed up and unusable, because the miner has incentives to drive Bitcoin into the ground? You're not looking at it broadly enough, and it's painful as it would be far better if everyone could try to imagine the broader game theory possibilities from as many angles as possible. I can't possibly think of them all myself, and most of the people in this thread have demonstrated they can be thoughtful and imaginative in the past. Help!

[notthematrix]

Store of value is more important.
Most peop[le dont realize the state fiat currency is in.
https://www.youtube.com/watch?v=vpAnysBCQuw
Watch this to eng translated docu.
Please enable caption.
Its about ecb money creation. how it works, insiders tell the deplorable state of the fiat system.
, if no fait system works , a payment sytsem is useless becuae bitcoin can behave like gold to back any other alt coin.

[DooMAD]

You're forgetting something important: what if a miner wants Bitcoin to become screwed up and unusable, because the miner has incentives to drive Bitcoin into the ground? You're not looking at it broadly enough, and it's painful as it would be far better if everyone could try to imagine the broader game theory possibilities from as many angles as possible. I can't possibly think of them all myself, and most of the people in this thread have demonstrated they can be thoughtful and imaginative in the past. Help!

So we consider various attack vectors and improve the proposal to compensate, not rule it out altogether "because game theory".  It's like saying we can't make any changes because "what if?" happens.  It's not a conducive mindset to progress.  Bitcoin never would have got off the ground to begin with if we had persisted with the notion that because a miner could do something malicious, we shouldn't even bother trying.  Despite your continued insistence to the contrary, people should continue to both consider and enhance this dynamic, adaptive and algorithmic approach.

Other proposals have already factored in things like the total fees paid per block, so it's more difficult to flood pointless transactions.  It should also be remembered that the adaptive nature goes both ways and that the blocksize can decrease as well as increase, so the moment any artificial volume ends, things will revert back to a lower blocksize with just the legitimate transactions, so the incentives to carry out a flood attack in the first place are seriously diminished.

[Carlton Banks]

So we consider various attack vectors and improve the proposal to compensate, not rule it out altogether "because game theory".

Uh, I'm not sure which version of reality you think you're living in, but if game theory rules it out, that means players in the game will exploit the exploitable. So, yes, "because game theory".

It's like saying we can't make any changes because "what if?" happens.  It's not a conducive mindset to progress.  Bitcoin never would have got off the ground to begin with if we had persisted with the notion that because a miner could do something malicious 

Which is precisely why the 1MB cap exists at all.

Instead of giving up, we capped the amount of resources the network can use. Can you not remember back that far back or something? 



Re: dynamic size


Can't you read either? Present a dyanmic/adaptive/responsive (whatever you want to call it) resizing proposal that can't be gamed, and I'll take you seriously. Instead, you just keep ploughing on, repeating over and over again about how dynamic blocksize is a better idea than a static or stepped static blocksize. And you've yet to recommend a proposal that actually does the job.


How can you not understand that when something is flawed, forget it. Recommending it again and again isn't going to remove the flaws but it will remove the number of people interested in listening to you.

[DooMAD]

So we consider various attack vectors and improve the proposal to compensate, not rule it out altogether "because game theory".

Uh, I'm not sure which version of reality you think you're living in, but if game theory rules it out, that means players in the game will exploit the exploitable. So, yes, "because game theory".

It's like saying we can't make any changes because "what if?" happens.  It's not a conducive mindset to progress.  Bitcoin never would have got off the ground to begin with if we had persisted with the notion that because a miner could do something malicious 

Which is precisely why the 1MB cap exists at all.

Instead of giving up, we capped the amount of resources the network can use. Can you not remember back that far back or something? 



Re: dynamic size


Can't you read either? Present a dyanmic/adaptive/responsive (whatever you want to call it) resizing proposal that can't be gamed, and I'll take you seriously. Instead, you just keep ploughing on, repeating over and over again about how dynamic blocksize is a better idea than a static or stepped static blocksize. And you've yet to recommend a proposal that actually does the job.


How can you not understand that when something is flawed, forget it. Recommending it again and again isn't going to remove the flaws but it will remove the number of people interested in listening to you.

If you actually read the link, you'd see they're not entering into to this blindly:

At BitPay, we will experiment with this approach. We will perform back testing to analyze what impact various settings might have on historic blocks. We will also analyze behavior under extreme circumstances and critique it from a game theoretic perspective. You can follow our work with our fork of the bitcoin client: https://github.com/bitpay/bitcoin. If our findings convince us that it is the best approach for Bitcoin, we will work to convince others (most importantly, miners) as well.

So it's clearly not a question of doing something reckless without a thought for the consequences.  It's about taking a thorough, rational approach, testing ideas, weighing up advantages and disadvantages and, most important of all, not being overly dismissive just because there are some hurdles to overcome.

[Carlton Banks]

....which means zero.

The inherent consequences of the proposal to the Bitcoin network is what matters, not only paying PR-like lip-service to the principles of good design methodology.




It's been said in this thread at least twice now, you must be blind:

If this proposal uses the fullness of blocks (and/or the fullness of the mempool) to determine blocksize changes, flooding the network is the attack vector.


Please, suggest something that will actually work in practice. Saying "let's all think of mitigations to the latest flawed design" doesn't help, it's your pet cause, you should be presenting something concrete, instead of wasting everyone's time.