Implicit Blocksize Limit

[adamstgbit]

Problem:
BUIP038 outlines an attack in which BU's flexibility is exploited in order to inject arbitrarily large blocks, unwanted by the majority of nodes.
the attack is performed as follows:

- with 40% hashrate the cost of the attack is minimal ( any amount will do, but the higher the hash rate the less expensive the attack is ) and will probably prove profitable once mining rewards are negligible and including as many paying fees as the network will allow you too, will be the name of the game.
- create an excessive block
- create AD confirming blocks,
- well done you've introduced a VERY VERY large block and made mad profits including the entire TX backlog of paying fees. effectively you steal potential fees from other miners.

one BUIP solves the problem by saying AD is proportional to the EB weight, thereby making it more expensive to pull off the attack. this BUIP is just a another option.

Root of the problem:
The root of the problem here is that nodes all act independently when it comes to enforcing blocksize limits. There is no universally accepted and known blocksize limit, only individualistic limits set by individual nodes. This means that AD is required, since a node will never be able to orphen a block and know for sure if the rest of the network will do the same, and so if AD is reached the individual's attempt at enforcing his individual limit has failed, and at a cost! ( i think its likely that some mining nodes will not be willing to orphan blocks without any guarantee that the rest of the network will also orphan that block, these miners will set AD at 0 or 1? )

Solution:
Introduce a new concept called "Implicit blocksize limit". every block has with it the miners MG, EB, and AD settings (Slush signals /MG1.0/EB16.0/AD4 ViaBTC signals /EB1/AD6/) with that info nodes can calculate an "Implicit Blocksize Limit". This IBL would be used by all nodes as an upper limit which if violated all nodes will simply orphen the block no questions asked.

the calculation would be some variation of : " highest EB value from the bottom 50% of EB values set on the last 1000blocks "

with the current BU nodes (Slush signals /MG1.0/EB16.0/AD4 ViaBTC signals /EB1/AD6/) "Implicit blocksize limit" (IBL) would probably be 16mb thanks to Slush.

ViaBTC would still be able ( and probably end up winning the fight ) to orphan this block, but worst case the attacker can not ever produce a block so big that it would violate >50% of EB values.


Notes:
I chose the calculation " highest EB value from the bottom 50% of EB values set on the last 1000blocks " so that BU's Emergent Consensus isn't compromised and miners can still choose to individually defened what they consider EB. they simply have an added guarantee that if the block has a size > IBL, there's no point worrying about anything futher ALL nodes will orphen this block.

I am open to any other type of IBL calculation, the basic idea is that the nodes require a way of knowing what the network itself considers EB, and thats what Implicit Blocksize Limit IBL is meant to provide.

highest EB from bottom 50% was chosen for the following reasons.

1) pissing off >=50% of hashing power is clearly an attack.
2) minners looking to"game the system" and set a very high IBL would require 50% hashing power.
3) if it was any more inclusive( like 15% ) it would render AD totally useless

 

[theZerg]

Adam, as I know you know, Bitcoin itself expects that 51% of the hash power is "honest".

If not, 51% of the hash power has an attack that can take all of the transaction fees and all of the block rewards. Just orphan every one of the 49%'s blocks.

So yes, 51% of the hash has broad powers, and I'd say producing a huge block to deliberately screw up the network is the least of our worries...

The idea of posting a BUIP is that its meant to be a formal statement. You are asking the entire membership to pay attention to your idea.

Since you've crossed a lot of your BUIP out, I'm thinking that you haven't really spent enough time thinking about this yet. Can we remove the BUIP designator, and just make this a normal thread until you are ready? If so, edit the title yourself, or post a reply here so I can do so.

 

[adamstgbit]

i'm refining the idea ( and trying to fix my unbelievable grammar ), yes i agree worrying about 51% isn't worth it, i've changed my BIP to avoid talking about that aspect, mostly because my new solution does not consider it a problem anymore lol

i think having some kind of well understood upper limit might be advantageous, so i think its worth bringing this idea some formal attention. but for now i'll just remove BUIP from the title.

 

[theZerg]

I think that the problem with such a limit is that N years down the road we get into the exact same situation we are in now. Let's let the "future us" pick that limit using EC.

Also what should the limit we pick today be? Why 16MB? Why not 50MB, 100MB? I managed to do over 60MB IIRC a few months ago with just a few fixes to the code. Many regions have internet that is capable of these levels. What I'm trying to say is that for any upper-upper limit we choose today, there are places where just below it would be painful, and other places where above it would be no problem.

 

[adamstgbit]

@theZerg

the limit is dynamic.
its said to be an implicit blocksize limit, because it's kind of implied, if the majority thinks its excessive, is there really a point in allowing a "AD fight" over this? I think honest miners will be way more conservative then this, when choosing their MG, is any honest miners really going to attempt to create a block they know only a minority will not contest?
I would imagine that in the future EB values reported by nodes will have grown very closely with the hardware and software tech improvments which allow for bigger block, and so this IBL will grow along with it.

what limit do we pick today?
well that shouldn't be up to you or any one person / group should it....

if we dont do this, miners will do this themselves in a softfork / unspoken agreement type thing...
this formalizes this agreement, and makes it a hard rule, which makes miners lives easier.

this might actually allow miners do more freely choose there EB, because without this they will be tempted to sortof collectively agree on a EB setting and pressure each other to use that setting.

Lets say:
a miner can handle say 50MB easily
but if he actually puts 50MB EB while vast majority of the network sets <8MB he will find himself defending blocks which will for sure get orphaned.
so altho he wishes to express his willingness to accept 50MB he is forced put a value of <8MB.

 

[Christoph Bergmann]

I like the idea.

Blocksize-explosion is a thing a lot of people seem to worry. And the possibility of it alone is reason for headaches, misunderstandings and more complexity.

Last weeks, with the complex game-theoretical scenarios, what happens when and so on, I realized that 1) it is hard to understand, 2) the outcome of scenarios can't be determined. The strong limit of core gives people an understandable sense of security, that regarding the blocksize, there will be no explosion and no system-breaking. A sense of security is trust, and trust in the system not breaking is essential for a currency. Completely Unlimited leaves a door open, that if something with game theory goes wrong, everything could go up in flames.

I don't discuss this as a technical thing. This is not my job. I

I just have the feeling that some kind of "hidden" / "hard" limit, some kind of ceiling, something in the range of 32 or 100 MB, maybe something floating, would be helpful to create some sense of security.

Maybe it would be a good idea to revive old Hardfork-BIPs, like 101 or BitPay's idea, and combine them with Unlimited. Maybe this could be an approach to find consensus.

Edit: Would it be possible to implement several Blocksize-BIPs "underground", let the miner vote about it, and when it has 2,016 blocks with some kind of majority, it is enforced forever?