BUIP101: (closed) Set the default value of max blocksize cap (hard limit) to 10 terabyte

[awemany]

@Norway: I like to point out that instead of setting a default of 10TB, which can introduce a "crash the node" attack vector, just requiring the limit to be explicitly set by the user, without any default given, would be just as effective in getting your point across and would have fewer downsides.

 

[Norway]

@awemany

I considered 0 bytes, 1 byte, infinity (no limit) as default values, as well as no default before I ended up with 10 terabyte as a default.

The "crash the node" attack vector is overrated and the fear of it is much more destructive.

We should also support an environment where pools compete to have the best transaction capacity. We will not get this environment if we babysit the weakest pools.

 

[Christoph Bergmann]

Isn't that exactly @Norway's goal? To force the ecosystem to find an emerging consensus without the help of the 'Politbüro'?

Imho raising default to terabyte is just the termination of the limit. I fully agree with pushing the user harder to set the limit by itself, and with announcing explicitly that this or that is a developer's suggestion. Maybe you can call this BUIP102.

Imho the whole discussion is stupid. The limit of BU is already ~300x bigger than real traffic, and the EB/AD mechanism makes it absolutely a non-issue to raise it, when it is needed and safe. BU devs are not the problem, nor the 'politbüro'. They already created the solution to never again care about the blocksize.

This whole discussion is a deflection from the real 'politbüro' mentality that kicked in again in Bitcoin Cash. Real issue, wrong target. That is why I think it does more harm than good.

 

[Norway]

 

[reina]

Wow, I too am surprised at how many people vote no on this. I wonder at the reasoning.

Would it be different if it said, set the default value to 2 gb, which is something that can be set right now? Knowing that it is also "bigger than we currently support", what is the diff if its 2gb or 10tb?

Isn't that the main point?

It's maybe a philosophical BUIP. The people who answered no, do they have an answer to "why not?"

 

[freetrader]

https://bitco.in/forum/threads/buip101-set-the-default-value-of-max-blocksize-cap-hard-limit-to-10-terabyte.22424/page-2#post-81691

Please, no-one get stuck in an infinite loop.

 

[freetrader]

Here here.

Time for BU to actually live up to its name. Unlimited.
If you want to keep your node from falling over, set it to something that you think appropriate. Programs running on our computers assume “unlimited” memory and don’t cap themselves. Bitcoin nodes shouldn’t be any different.

Waiting to hear when the public nChain / BitcoinSV supporters who voted Accept on this are going to put in a request for SV to set its default to 10TB as well.

The github is here: https://github.com/bitcoin-sv/bitcoin-sv

You can put in an issue to ask for the default to be set according to BUIP101. Some among you are coders, you've little excuse not to put in a PR.

If this proposals fails BU voting, you should submit it to Bitcoin SV if you believe it is good and important.

Not submitting it to SV would make me question your motives with this BUIP.

If it is accepted in BU voting, you should submit it to SV even more, to dispel any idea that SV is trying to control the block size limit by limiting it to 128MB...

 

[AdrianX]

Waiting to hear when the public nChain / BitcoinSV supporters who voted Accept on this are going to put in a request for SV to set its default to 10TB as well.

The elephant in the room is the hashrate that is oblivious to the consensus rules changes, just follow the ABC scheduled for obscure reasons like, they are the implementation that defines Bitcoin Cash.

SV is a minority implementation and of little influence.

So the straw man aside. More relevant are the ABC developers who voted yes for BUIP101 as they dictate the defaults for +51% of the BCH hashrate.

 

[Norway]

@Norway, given that voting on BUIP101 is fairly split up to now, and it might not pass, have you considered submitting your 10TB change proposal to Bitcoin SV ?

Their github has 'issues' enabled, so you could submit it to them as an enhancement proposal.

If BUIP 101 gets a majority vote, I will submit this to SV, ABC, XT and other implementations. But I need help, because I don't know how Github works.
[doublepost=1539113698,1539112897][/doublepost]

 

[AdrianX]

I've found, Github works like an autocratic dictatorship if you're not part of the relative Github hegemony.

 

[freetrader]

@Norway, all you need to do is signup to Github's (all you need is an email for that).

Then you can raise an issue on a project, suggesting them to implement BUIP101. You can put a link to this BUIP in the issue so they know how to find the details.

https://help.github.com/articles/creating-an-issue/

If BUIP 101 gets a majority vote, I will submit this to SV, ABC, XT and other implementations.

Why the condition? I thought you believe this is a good thing for clients to implement.

I've found, Github works like an autocratic dictatorship if you're not part of the relative Github hegemony.

Up to the project. You'll find out by doing.

 

[AdrianX]

Up to the project. You'll find out by doing.

My interaction with Core and BU, both support this experience.

However, my general experience has shown this is true for any organization. Before you can affect change you need to build trust with the other members. Typically Members with a low participation score are inevitably sidelined.

Greg Maxwell is an expert hacker in this regard.

 

[Norway]

 

[Griffith]

I'd first like to state that I am 100% for the eventual removal of the block size limit in a responsible manner and would like the remind everyone that in the BU articles (section 2.4, see below), it is required that the implementation of a BUIP meets some basic standards.

If the BUIP does NOT contain a patch but suggests technical changes, it is the responsibility of the Proposer or any other party to produce this patch. After the patch is produced, the Developer reviews it as suggested in the preceding paragraph, except in the "as is" case, the normal BUIP schedule and process must be followed.

(and the relevant part of the preceding paragraph in the articles)

If a BUIP contains a patch, the Developer may review the patch for acceptability (including but not limited to bugs, tests, coding standards) AFTER BUIP acceptance.

That being said... Of the group of people who contribute to BCH, I by no means consider myself a top tier developer and definitely consider my opinions outranked by others with more technical merit. I see that some of the leading ABC devs voted yes to this proposal so maybe there is something others know that i don't. I wish they would share. Although i did vote no because i do not think this BUIP works on a technical level, I have no problem with being proven wrong and am very excited to see the tests and data to show that a 10TB limit doesnt have any adverse affects.

 

[Christoph Bergmann]

Now I understand ...

On the Bangkok meeting Amaury explained an attack: flood nodes with an infinite number of transactions, and as long as they have no blocksize limit, they don't know when to end and will consume all their memory.

With a terabyte limit as proposed with this buip, the node could be pushed to consume one terabyte of ram. If you don't have it, you'd need to reboot and change the limit.

There might be methods to get a rough blocksize from merkle tree and coin base transaction, but it is not implemented yet and it is unclear how concrete the estimation is.

More important at the moment: deadalnix and micropresident voted with 'yes' on this proposal - clearly knowing that it introduces an exploit in the bitcoin unlimited software delivered as default - clearly knowing that this will harm bu adoption with miners, exchanges and everybody, and that this will strengthen abc's position as the dominant bch client.

Therefore deadalnix and micropresident voted with the intent of harming bitcoin unlimited. They proofed hostile abuse of bu's voting system. I demand that their voting rights are suspended immediately.

 

[Griffith]

@Christoph Bergmann yes, that is one of the issues with it but not the only one. To formally remove a BU member if their membership is still valid you need to submit a "no confidence" BUIP. see section 2.9 and 2.10 of the BU articles

 

[digitsu]

The thing is that sort of attack is easily defeated by simply setting the cap of how much txn data you will download depending on how deep the coinbase txn is in the merklebranch.