Asymmetric Moving Maxblocksize Based On Median

Consensus
#41

Yeah, about that.

Miners have repeatedly shown over and over and over and over again that they will run just whatever software the leading stables (the leading implementation) produces: meaning Bitcoin Cash Node at this moment.

Miners will not “vote” for anything. Miners voting for changes in protocol is a pipe dream that we hoped would happen in reality since 2015, but it never did.

Miners are people. People follow the herd (community consensus) or the alpha (BCHN), just like any other animals in nature [for more details see my human herd theory, also shorter version]. Believing and thinking anything else is just highly unrealistic. And miners have indeed shown that they follow and dont care very strongly.

So getting an automated default blocksize increase into the leading implementation(s) is a great idea. It will basically cement the consensus to steadily increase blocksize with demand for decades, because miners will just run it and dont care about details, like they always did (and will probably always do, from the looks of it).

#42

Fun fact, the BIP9 setup of miners voting for upgrades was never marketed as “voting”, it was nothing but an indication that miners had upgraded to compatible software.
So, yeah, the only real vote we ever saw was the Segwit2X one, and I think we know that that was also really not avote.

But you realize nobody was making the argument, right?
Maybe that wasn’t clear, but the list which you quoted from was a list of options for the mining community to get inspiration from. If you think they won’t pick that, then sure. Maybe you want to help miners with a better solution.

As long as such a solution doesn’t involve a consensus rule. Because that just sets us up for a new lock-in where developer consensus is needeed and the only way out is a hard fork. Never again.

What miners have done quite well over the last almost 15 years is set the block size. We are quite happy with this, the mining community has been very responsible in this regard.

#43

I don’t think anyone is proposing a hard coded block size algorithm, only a soft coded algorithm where it defaults to it, but can be selected off and adjusted.

#44

Nah. Everybody was making all kind of arguments.

In the ends, the outcome was not dictated by arguments, but by psychomanipulation, propaganda, and, ultimately: Following.

People (especially miners) follow the herd or the alpha, rational arguments have nothing to do with anything. Or at least it happened in the BTC/BCH split.

Luckily in the next 2 splits (BSV/BCH, ABC/BCH) the enemy did not manage to corrupt/take over enough alphas (which is partially thanks to me, because I was very vocal about the manipulation and then became a moderator).

Dude, do you realize that Bitcoin Cash is “hard-forking” every year, right?

The proper term is “split”.

The network splits only when there is a major disagreement in the community, miners have nothing to do with it, basically.

The split never actually happens because of the miners. The split happens because of

  • Propaganda
  • Politics
  • Brainwashing of Community
  • Exchange policies

I have lived through this and I took part in it 3 times so believe me, I know.

Huh? Are we living on the same planet?

The miners have never set the blocksize. Ever. This never happened.

In any of the splits that happened, the blocksize was ultimately decided by developers and community leaders (meaning very often Twitter trolls) who rallied against any increase or they rallied to increase blocksize in a dumb way like they did in BSV.

Dude, BTC/BCH miners do not follow reason, logic, arguments or anything like that.

What they follow in their sheer mass is the “leading implementation”, the twitter herd and the alphas who dictate the price.

Whatever code the leading development project produces, miners will run. That is all.

I mean it’s not like I do not have a lot of proof. I have fuckton of proof. Me being right is absolute and undeniable at this point.

Miners – will not vote – to decide the parameters of the network, ever - with very high probability. You gotta Deal with it.

#45

PS.

And because miners will never vote to choose a leading implementation, the leading implementation has to decide for them.

And we - developers, politicians, influencers, moderators and all other people who have any kind of power - it is our role to make sure that the leading implementation(s) runs good, working code. Everybody else will just follow.

This is unfortunately how humanity works right now.

So the decision to make an automated algorithm that decides blocksize in the leading implementation(s) is a good decision.

#46

There are places where you can post a bunch of nonsense and expect to be corrected ad nauseam. Called the Bitcoin Up, Gold Down thread. Check it out. You’d love it.

1 Like
#47

Offtopic ramblings, ignored as usual.

Try to stay on topic, this is not reddit. We actually solve problems here.

#48

It helps if you learn your history. The current miners are not mining 32MB blocks, right? That is because they set a max blocksize. The same has happened all the way back to the 250KB blocksize in the early years.

Miners have always been the one to set the blocksize. Until they couldn’t due to the maxblocksize limit (1MB).

ps. the initial 8MB limit that BCH split with, was also at the request of miners.

#49

I just noticed I am talking to Tom Zander.

Yeah, Tom - we both know the history. You were there too.

Do you remember a large miner ever saying

  • “We will not run Bitcoin Core because it has 1MB blocksize only, instead we will run Bitcoin Unlimited/Classic/XT” or
  • “We will not run BSV because having unlimited blocksize without performance improvements is dumb” or
  • “We will not run Bitcoin ABC, because giving out 8% of block reward to random person seems like tax” ?

No, you don’t because it never happened. Miners never made the decision.

The miners never set that. They were running on default settings most or all of the time.

What miners have done is running the reference implementation on default settings. Always. They never run anything else, actually.

You have never heard a large miner say that they will not run something because of blocksize issues and you (most probably) never will.

I don’t remember this request.

What miners requested this and when? Can you link me the source?

1 Like
#50

This is the second time but in a different thread where you have just declared yourself correct. This is why I stopped engaging you before and can’t take you serious here. It looks like a complete waste of time to correct you or talk to you in any manner. I imagine you have held a lot of incorrect beliefs for a long time (making it even more difficult to unlearn) because you don’t accept feedback, which is crucial to learning.
“Me being right is absolute and undeniable at this point”.
You solve problems in your own fantasy land.

#51

Yet another irrelevant offtopic ad-personam attack.

Ignored.

Thank you for your participation, have a good day.

#52

The idea of this topic (Asymmetric moving maxblocksize based on median) can be completely implemented in an advisery method only, where the miners adjust their max-block-size (EB) on such advice and a simple check of the blockheaders can show it being safe to increase created blocksize.

Having a blocksize cap formula doesn’t preclude miners from hard-forking an additional increase (or soft-capping it lower), it just makes the cap adjust slowly upwards in the meantime, potentially making blocksize hard-forks unnecessary (but still possible).

The idea I outlined records the state of blocksize cap in every block and uses the state of the last block to determine allowed size of the next one, and so on. This would make it possible for miners to get together and record an arbitrary number into the blocksize cap state, and then formula would resume its work from there (take whatever value was recorded in the last block, compare with threshold, and either keep it the same or adjust slightly upwards). Difference is in the effort required to increase… hard-fork override (which is what we’re currently doing anyway but the value remains fixed till the next one) requires a consensus upgrade, while formula lets us automatically creep upwards according to user demand (miners could still soft-cap it lower).

Having a formula in reduces the risk of lock-in by not being able to gather consensus for a hard-fork upgrade, but still allows for a possibility of having such an upgrade.

1 Like
#53

The current situation is that miners can change the blocksize to anything. No software developers need to have any consensus on that. This is the extreme opposite of lock-in. From todays baseline of zero the suggestion that we can reduce (needing less than zero software developer consensus) is not possible.

#54

It may be a configurable option, but if blocks will be rejected by nodes based on the option (or hardcoded value) then you’re changing blockchain consensus specification you’re running and result is a fork - unless done by ALL - including economic nodes (exchanges, wallet backends, indexers etc.).
What if all exhanges and some 40% miners had the config at 8MB and 60% miners set it to 10MB and started mining? The 60% would have more PoW but they’d live in separate reality with no place to sell their forked coins. If the configuration option is changing the consensus specification without ecosystem consensus - splitting hard fork. It’s not in devs hands, but they’ve historically took leadership role to help everyone upgrade to the same specification. It doesn’t mean the ecosystem needs their permission.

Miners didn’t need developer consensus to change a constant in the code and recompile either, anyone can do that without permission. Having to change a line of code and recompile just makes it more cumbersome than having it as configurable option but the effect is the same - a hard fork, because changing it is changing consensus specification and to change it without making a mess consensus among most nodes (mining and non-mining) is required.
Having to gather such consensus is a burden, and having a formula means the blocksize cap can adjust on auto-pilot, hopefully without a “coordinated configuration change” or whatever you want to call it being ever required, but still being available as fallback.

1 Like
#55

There are many ways to ensure a steady block size increase. We should distinguish between two ways of coordinating that, though. One is any method that involves asking the software developers in order to make changes. Another are methods that do not require consensus from the software developers on such decisions at all.

The first is creating more lock-in. A consensus between software devs would be needed and capture and lock-in like Core has seen can be re-established. Never again.

The second is what we have the opportunity to do, find a way to nicely adjust the two variables to never get too close: the accepted-blocksize and the created-blocksize. Those can be adjusted by the market at will as they are configurable in software today (and have been since Aug 2017). Avoiding a capture like the one that led to the Core team being stuck at 1MB.

#56

Completely wrong.

The lock-in is only in place because of the nature of the population (I willl repeat this again: ESPECIALLY miners).

No matter what happens, miners just run the default software with default settings. There is no thinking process involved here. Only following.

The actual real reason why miners dropped BSV and followed BCHN instead is only because Craig did not manage to convert enough influential people (again: partially thanks to me). If they succeeded and converted thought leaders of /r/btc to their side, Bitcoin would be obliterated and Bitcoin Cash would either stop being relevant or even cease to exist.

At most of points of history, majority of miners were Chinese. This is most probably still the case today. Let me remind you, chinese culture has inherently no place for individual thought, freedom of will, individual liberty. It’s an authoritarian country with fully authoritatian culture. If Chinese people do not understand the concepts of

  • Individual Choice
  • Ability to select one’s leader
  • Individual freedom
    It’s really no wonder they would prefer to follow instead.

It really boggles the mind as to why somebody would not understand this at this point of history.

Asking software developers every time is sure a way to create potential political issues that can be utilized by our enemies leading to contention, which then can cause a split.

We already have proof of this, the blocksize issue is being used to cause conflict practically every time BCH is attacked.

Adding the increases into the software is a sure way to eliminate at least some of contention. If it ever becomes a problem (very doubtful), then we can raise the issues to the developers and make a hard-fork which tweaks it.

This is the wisest option, the max blocksize limit based on median should make it into the code of leading BCH node software.

#57

Also:

This is spot on.

Because of miners are not making conscious thought-over strategic decisions, but they instead choose to follow thought leaders and social consensus (which often basically means Twitter consensus), having automated maximum blocksize increase removes the political points leading to contention, not creates them.

Max blocksize increases in default node software === less contention and less contentious splits in general.

#58

Actually, this has worked just fine many times in the past (from 250kb blocks back then) and there have not been any points brought forward why this would not work in the future.

In Bitcoin Cash the miners have always been our partners. They have always cooperated and there is no infighting of significance. Don’t mistake their ways of working as anything other than being good partners in building up this ecosystem.

Putting back into the protocol the one exact thing that is killing BTC is not something that you do to equal partners.

#59

Yeah, that was before-2015 era, pre-blockstream. This is completely different.

This is a dirty trick, Tom - you know very well what I mean.

It’s like you’re talking “Listen, we have been working with Russia and buying oil from them many times and they did not murder innocent people - remember January 2014?”

Yeah, “Russia - then” and “Russia - now”, is completely separate topics. Just like “Bitcoin - pre 2015” and “Bitcoin - past 2015”.

You cannot have any discussion about blocksize without politics and influences anymore, which is a problem and this topic is a proof. The proposal in this topic aims to eliminate such discussions and such contention as this altogether - which would be excellent.

We all pretty much agree that in the next years Bitcoin Cash will either significantly increase usage (and thus blocksizes) or die. It is economically not possible for BCH to survive many more halvings without massive usage happening.

I (and probably almost everybody else here) would very much prefer Bitcoin Cash not dying. So it makes absolute sense to include max possible blocksize increases in the hard-coded consensus to cement this political stance of BCH supporters.

#60

@tom

PS.

I will address your second and third arguments later, I am busy now.