Gold collapsing. Bitcoin UP.

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
I think it is quite shortsighted to equal civilization with the mafia. The government equaling a/the mafia, maybe.
Approving/accepting/advocating getting civilized (= becoming or remaining a nationalized human who is forced to earn and pay protection money = homo oeconomicus) is the same as approving/accepting/advocating to be a member of the mafia. How does that taste to you? It's grosso modo the same. Good luck to everyone who is trying to formulate a rebuttal:

https://de.scribd.com/document/2846173/Tilly-War-Making-and-State-Making-as-Organized-Crime

http://othes.univie.ac.at/9223/1/2010-03-29_0407888.pdf

"I pay you to protect me from intruders" (division of labor) is not quite the same as "give me your money, or else" (threat of violence).
Yes, that wouldn't be the same. But the mafia and the state threatens their members with violence if they refuse to pay. Q.E.D.
 
Last edited:

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
Things are not perfect.
Yes, but you actually seem to believe in an orwellian manner that things are better in an artificial environment that destroys the environment with exponentially increasing speed until everything collapses (again). It's not just the belief of capitalists. The communists believe the same. It's just the anarchists who have a different view.

Edit:

Great description of the so called civilization on Wikipedia. Amazing that it didn't get vandalized by non-anarchists (collectivists):

A civilization or civilisation (see English spelling differences) is any complex society characterized by urban development, social stratification imposed by a cultural elite, symbolic systems of communication (for example, writing systems), and a perceived separation from and domination over the natural environment.[1][2][3][4][5][6][7][8]

Civilizations are intimately associated with and often further defined by other socio-politico-economic characteristics, including centralization, the domestication of both humans and other organisms, specialization of labour, culturally ingrained ideologies of progress and supremacism, monumental architecture, taxation, societal dependence upon farming and expansionism
 
Last edited:

Richy_T

Well-Known Member
Dec 27, 2015
1,085
2,741
I believe it because it's measurably true. There's some room for improvement in the measure of liberty we have but I always believed Utopianists were nutso anyway.

Actually, that's not quite true. I used to be a Utopianist back in my nutso days.
 
  • Like
Reactions: Norway

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797

SPAZTEEQ

Member
Apr 16, 2018
40
24
Sorry if I have missed something here in this thread, I have been going back to the op codes stuff in February. A couple members made observations between priorities and sound money, and it made me wonder if Roger had weighed on related concepts in any way.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
I think it's time to revisit the question:
Should the max blocksize cap be removed?

If it's safe to remove it, we should do it in the november 2018 fork.
If it's not safe to remove it, we shouldn't do it.

What is the scenario where it's unsafe to remove the max blocksize limit? What bad things can happen? Can these bad things destroy bitcoin (BCH), or are they just small bumps in the road?

I prefer a 24 hour crash of the system to a two year choke on capacity.
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
BU is resilient to excessive block attacks because it has Parallel Block Validation and a setting that ensures you always follow the longest chain (Acceptance Depth)

In my mind, we are not ready to remove the limit entirely until BU has the majority hashrate or competing implementations implement Parallel Block Validation.

I'd support removing the limit when the majority hashrate has a parallel block validation mechanism in place. Followed by parallel transaction validation.
 

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
I have no idea, but someone is going to attempt some attack, be it a big block, convoluted script os some crazy code (developers have claimed to be able to make a block that would take over 10 minutes to validate) .
Being able to validate blocks in parallel, means you don't have to concern your self with the jamming block, you can just orphan it if it takes a long time to validate.

Parallel Validation is a free market enabling mechanism to encourage miners to optimize their blocks for maximum efficiency and punish those who don't.
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,695
Because the Bitcoin Cash development community have initiated regular HF protocol upgrades, there is flexibility to do exactly what @Mengerian suggests.

It was only because getting the 1MB changed in BTC became such a nightmare that we slipped into the mindset that we had to solve the problem permanently in one step, e.g. like using the EC logic with the excessive block size and acceptance depth variables. Another very good permanent solution is Jeff Garzik's collaboration with XT (i.e. 50th, not 80th percentile) BIP100 miner voting.
 

imaginary_username

Active Member
Aug 19, 2015
101
174
Or a formal way (BIP100-style block voting?) to raise blocksize cap can be implemented, then miners can do it without "hardforking" to new code whenever the need arises after debate - and merchant nodes can accept the new cap without upgrading too.

If you remove the cap altogether we don't know what happens at the extreme end of things - what if an attacker rent hashrate and send out multiple blocks that are followed by endless transactions?

On the other hand, keep the current system and there's bound to be paralysis every time the cap's raised, especially as the ecosystem becomes more entrenched. We are only capable of hardforking so often and without fuss because the ecosystem's still young.

If a formal procedure is in place, the usual debates can still take place among everyone before a decision is made by miners. The debate can close at some point though, no new code is needed (no upgrade fuss for everyone), and everyone can see the outcome well beforehand. Clean, preserves permissionlessness (since we don't have to poll all the friggin' big miners via chatroom), and limits risk as far as miners have the appetite for it.
 

Tom Zander

Active Member
Jun 2, 2016
208
455
Should the max blocksize cap be removed?
According to my reading of the UAHF spec, it has been removed since August 2017.

See; https://github.com/bitcoincashorg/spec/blob/master/uahf-technical-spec.md

REQ-4-1 (require "fork EB" configured to at least 8MB at startup)
If UAHF is not disabled (see REQ-DISABLE), the client shall enforce that the "fork EB" is configured to at least 8,000,000 (bytes) by raising an error during startup requesting the user to ensure adequate configuration.

Now, if you ask BU, since years the abbreviation EB is described as being a replacement of the blocksize cap. The usage of EB implies that the consensus rules no longer apply to the blocksize. This is enforced by the wording that specifically states this is a user configuration.

This is just my reading, and I guess the ABC client still has code that implies the max blocksize is a consensus rule. But Flowee and BU don't. They see the 8 (and soon 32MB) as just a default for the EB setting (called blocksizeacceptlimit in Flowee).

[doublepost=1526117007,1526116385][/doublepost]
If you remove the cap altogether we don't know what happens at the extreme end of things
In my opinion the ideas behind EB / blocksizeacceptlimit stay valid and are actually used. Miners decide to reject blocks above a certain size. In the Tuesday upgrade miners agree to collectively move their blocksizeacceptlimit to 32MB, while keeping their generation size at 2MB or so.

Which means that the extreme case of an evil miner creating a 50MB block, that will just get rejected.

I want to add that I don't see any inconsistency between the miners using the EB concept on one hand and our communication being based on "max blocksize" on the other because the AD concept was never liked and the collective agreement on the max block size has been an effective way FOR MINERS to get this set for the entire time of the Bitcoin ecosystem.
Using the 2-anual upgrade cycle to set a new limit is just a continuation of this.
 

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
It can be bumped up every 6 months in scheduled upgrades.
Famous words:
It can be phased in, like:

if (blocknumber > 115000)
maxblocksize = largerlimit
But I am honestly not too worried. BCH has the thorn of adding value compared to BTC in its side. And years of history on this issue.

Which makes me ponder about my pet theory once more: That Satoshi introduced the limit with full knowledge of what would happen, sneaky bastard that he was. To lure out the bad actors.

Because it is just too damn funny: He was talking about and defending Bitcoin for its on-chain scalability all the damn time to all kinds of people. And then he silently introduces a limit that is squarely in the way of Bitcoin's success? No f'ing way :)