BUIP102: Set the default value of max blocksize cap (hard limit) to infinity

[torusJKL]

BUIP102: Set the default value of max blocksize cap (hard limit) to infinity
Date: 27 August 2018
Proposer: torusJKL

This BUIP is inspired by BUIP101 but instead of defining a new limit (which could be reached at some time in the future) this BUIP wants to remove the limit completally.


Motivation
(copied from BUIP101)
The motivation of this proposal is to move the judgement of what max blocksize cap is safe from Bitcoin Unlimited to the individual miners.

The size of how large blocks a miner will or can accept should be a matter of competition. Not a green light from developers for what's safe for everybody, no matter how little you invest in hardware and network connections.


Development task
Define a value for accepting a block of any size (e.g. -1) and define this value as the default for future releases.

 

[torusJKL]

@solex please assign a BUIP number (is 100 still free?) and add this to the list. Thanks

 

[theZerg]

I'm not releasing this into general discussion yet. Two comments:

@torusJKL @Norway, to be respectful of BU member's and voter's time why don't you two duke it out to decide whether you really need two separate BUIPs on this topic?

BU doesn't have an explicit limit (but note that we do have a point beyond which we have no longer recently tested).

The maximum message size is 32 (IIRC) times the configurable "excessive block size". One prior problem was how large the largest RPC call could be because we needed to send this block to miners via a JSON RPC API. However, this is fixed in the 1.4.0.0 release via new RPCs that don't pass the entire block.

So I'm not sure what I'd do with this BUIP if passed. Perhaps you'd want to add/change some wording, request QA python test code up to a certain amount, etc.

Also note that passage of a BUIP means I'll merge code if it appears, it does not force BU devs to run off an implement your BUIP. For example, if you request testing up to 10TB, IDK how to even start that given my resources. So you'd have to do the testing and provide the PR for the test and any necessary code changes.

 

[Norway]

@torusJKL
Could you please postpone your BUIP 102 to the next voting after we have voted on BUIP 101? There are two reasons for this:

1) A tangible number like 10 TB is easier to accept / understand than no limit at all.
2) The voting process will be less messy.

We're certainly on the same page here, and my BUIP is just a softer step in the same direction.

 

[torusJKL]

I have no issue postponing it.
This BUIP is still a draft and I don't feel comfortable to open it up for a vote at the moment.

 

[Norway]

Ping @solex .

 

[Norway]

Ping @theZerg too. We sorted it out, like you suggested.

 

[AdrianX]

1) A tangible number like 10 TB is easier to accept / understand than no limit at all.

LOL, "A tangible number like 10 TB" I was thinking like 1GB, but may entertain 1 TB given there is a presentation that brings this number into a framework I can comprehend 1TBbeing approximately 50 transactions per person per day.

FT;FU

We're certainly on the same page here, and my BUIP is just a softer step, in the same direction like a little more realistic.