Why Blockstream is against "contentious" hard forks - Control

[chopstick]

So the real reason why Core prefers soft-forks over hard-forks has now been revealed.

They don't want to lose control of "their" project to free market forces.

They want to be able to push through whatever change they want without anyone else being able to have a say in it.



https://np.reddit.com/r/btc/comments/43h4cq/they_coreblockstream_fear_a_hard_fork_will_remove/

    A primary benefit of running a full node is to gain full validation of all transactions.

    In the event of a hard fork that has activated the node is disconnected from the network and it is immediately obvious that no validation is taking place.

    When the same change is done with a soft fork the node is deceived into believing that it is validating transactions when it is not.

~ /u/tl121

https://np.reddit.com/r/btc/comments/4mmfoh/segwit_is_not_2_mb/d3wtnmp

    Simple use case, by running a node I want to be sure that when I see transaction on the network I can be sure that it is properly signed with correct key.

    With introduction of segwit as a softfork all new type transactions (segwit) - will be ok for me, as I won't be able anymore to validate signature.

    This is what I call a zombie node.

~ /u/chakrop

https://np.reddit.com/r/btc/comments/4mmfoh/segwit_is_not_2_mb/d3wqh6h

    "They [Core/Blockstream] fear a hard fork will remove them from their dominant position." ... "Hard forks are 'dangerous' because they put the market in charge, and the market might vote against '[the] experts' [at Core/Blockstream]" - /u/ForkiusMaximus

https://np.reddit.com/r/btc/comments/43h4cq/they_coreblockstream_fear_a_hard_fork_will_remove/

    The real reason why Core / Blockstream always favors soft-forks over hard-forks (even though hard-forks are actually safer because hard-forks are explicit) is because soft-forks allow the "incumbent" code to quietly remain incumbent forever (and in this case, the "incumbent" code is Core)

https://np.reddit.com/r/btc/comments/4080mw/the_real_reason_why_core_blockstream_always/

[Wosterlee]

The owners of Blockstream are spending $75 million to do a "controlled demolition" of Bitcoin by manipulating the Core devs & the Chinese miners. This is cheap compared to the $ trillions spent on the wars on Iraq & Libya - who also defied the Fed / PetroDollar / BIS private central banking cartel.

https://www.reddit.com/r/btc/comments/48vhn0/the_owners_of_blockstream_are_spending_75_million/

[Lauda]

Just another day of fear, uncertainty and doubt. I'm not surprised by any of these statements as I've read a lot of more in that subreddit. Maybe you should try again with the next controversial HF, 'Bitcoin Coinbase' or something.  

[alani123]

Why are you in support of them? Is bitcoin in such a dire situation that hardworking with a vastly developed fork is so urgently needed?

[jonald_fyookball]

So the real reason why Core prefers soft-forks over hard-forks has now been revealed.

They don't want to lose control of "their" project to free market forces.

They want to be able to push through whatever change they want without anyone else being able to have a say in it.


 

I've been saying this for 6 months now. 

How sad that there hasn't been a blocksize increase yet.

[chopstick]

Yep, and thanks to the level of FUD that has been employed by blockstream now every idiot on r/bitcoin thinks hard forks are somehow "dangerous" and "contentious", despite having no real understanding of the subject.

What a laughable state of affairs.

We have a bunch of greedy idiots who just want to maintain their control over the bitcoin protocol at all costs, who have now taken over bitcoin development.

Core has employed massive amounts of FUD, disinformation campaigns, smear campaigns, paid hundreds of thousands to DDoS nodes of competing implementations, censored all the main communication hubs and filled them with their trolls... and the list goes on.

You'd really have to be an idiot not to see what's happening here.

[mayax]

Yep, and thanks to the level of FUD that has been employed by blockstream now every idiot on r/bitcoin thinks hard forks are somehow "dangerous" and "contentious", despite having no real understanding of the subject.

What a laughable state of affairs.

We have a bunch of greedy idiots who just want to maintain their control over the bitcoin protocol at all costs, who have now taken over bitcoin development.

Core has employed massive amounts of FUD, disinformation campaigns, smear campaigns, paid hundreds of thousands to DDoS nodes of competing implementations, censored all the main communication hubs and filled them with their trolls... and the list goes on.

You'd really have to be an idiot not to see what's happening here.

this is Bitcoin. where is the surprise? where "money" are involved, disinformation campaigns, smear campaigns appear. nothing new. the BTC gangs(cartels) are fighting each other in order to take the control 

[yayayo]

Another thread by the big block Gavinista fan club... seems like after the initial FUD campaign didn't work out as planned it's time for another laughable attempt to discredit Core developers.

Do you remember the shiny diagram circulated months ago? It depicted an extrapolation of block filling with everything painted in alarming red, suggesting total network breakdown since the beginning of this year. Why are bigblockers not posting this original diagram again? Are they afraid of admitting being wrong?

I'm really happy that Core developers did not give up despite the FUD and hostility directed against them by the big-block ideologists. Core continues to innovate in the best possible way and the developers behind it have all my support.

ya.ya.yo!

[jonald_fyookball]

Another thread by the big block Gavinista fan club... seems like after the initial FUD campaign didn't work out as planned it's time for another laughable attempt to discredit Core developers.

Do you remember the shiny diagram circulated months ago? It depicted an extrapolation of block filling with everything painted in alarming red, suggesting total network breakdown since the beginning of this year. Why are bigblockers not posting this original diagram again? Are they afraid of admitting being wrong?

I'm really happy that Core developers did not give up despite the FUD and hostility directed against them by the big-block ideologists. Core continues to innovate in the best possible way and the developers behind it have all my support.

ya.ya.yo!

you're an idiot.

Its still a problem and just getting worse.

[chek2fire]

the reason for not fork to big blocks atm is completely technical. Every one that not understand this is simple not understand how bitcoin works. This is a fact. Everything else is a childish playground for morons...

[gmaxwell]

Things ignored by this post:

Conservationism about coersively overriding the rules of the network is a widely held view, including almost the entire technical community (which blockstream engineers are only a small part of).

Concerns about hardforks and removal of blocksize limits stem back many years, long before the creation of blockstream. I was posting in 2011, for example.

Soft-forks were a mechanism put into place by Bitcoin's creator-- and used by him several times, never hardforks--, and he also also described the initial rules as largely set in stone when the system was launched.

At the end of the day, _no one_ has the authority to push a hardfork onto other people-- to do so would require overriding their wishes and changing the software on computers they personally own and control.  Bitcoin is specifically designed to not have that kind of authority.  People who think hardforks are easy, simple, or desirable have lost the plot.

[franky1]

Things ignored by this post:

Conservationism about coersively overriding the rules of the network is a widely held view, including almost the entire technical community (which blockstream engineers are only a small part of).

Concerns about hardforks and removal of blocksize limits stem back many years, long before the creation of blockstream. I was posting in 2011, for example.

Soft-forks were a mechanism put into place by Bitcoin's creator-- and used by him several times, never hardforks--, and he also also described the initial rules as largely set in stone when the system was launched.

At the end of the day, _no one_ has the authority to push a hardfork onto other people-- to do so would require overriding their wishes and changing the software on computers they personally own and control.  Bitcoin is specifically designed to not have that kind of authority.  People who think hardforks are easy, simple, or desirable have lost the plot.

^^ said by someone paid by blockstream ^^

softforks were not "put in place" by the bitcoins creator.. softforks are utilising a tweak that can be used to make them happen.
its like saying
gmaxwell: apple trees were put inplace to make applepie and cider..
everyone: no apple trees make apples.. its only afterwards that people realised they could tweak an apple to make cider.. but cider is no longer an apple

as for talking about the bitcoin creators intentions, satoshi actually envisioned increasing the blocksize limit

https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

its just a shame satoshi disappeared a couple months later before actually coding it in. because based on the blockheight. he envisioned the code to be included before that blockheight and activated as of about march 2011 as an example

at the end of the day, _no one_ (yes i used gmaxwells failed attempt to underline) should be allowed to prevent a hardfork and make it contentious.
its only contentious because blockstream/core say no.

[gmaxwell]

Bitcoin has specific affordances for softforks which were added to enable them, things like NOPs in script-- which were added to replace an earlier mechanism that caused random uncoordinated hardforks, and transaction version numbers. Softforks were used by bitcoin's creator several times early in its existence, e.g. to do things like fix script or add height based nlocktime.

[jonald_fyookball]

^^ said by someone paid by blockstream ^^
 

The blockstream rhetoric is painfully transparent to anyone paying attention.

How easy it is to cry "but we shouldn't change anything without consensus" while
at the same time being the very impediment to that consensus.

The community has thus far been complacent enough to
accept by default the leadership of core, but in the face of continued
stagnation, one has to wonder: "but for how much longer?"

[franky1]

the main "contention" of a hardfork that blockstream defend is that it will dilute the distribution of full nodes due to bloat..

lets address the distribution debate:
yet after a softfork. those who dont upgrade are not full nodes.
yet after a softfork. those who DO upgrade but are talked into running no-witness mode are not full nodes
yet after a softfork. those who DO upgrade but are talked into running pruned mode are not full nodes
yet after a softfork. those who DO upgrade but are talked into running lite mode are not full nodes

yet mining pools have already said they wont upgrade to segwit unless certain things have been met and also their own independent tests have been done. so segwit is also contentious!!

lets address the bloat debate:
so is blockstream roadmap any better??.. if blockstream wants domination.. they should not be offering no-witness, pruned, lite modes. they should be concentrating on the full validation, full archival principal.
even gmaxwell cannot comprehend this principal because he cannot do the maths publicly to show how much REAL data will be relayed per block based on all the extra bytes that are needed for all of the features that are in the roadmap, based on the end result REAL block data bloat when the roadmap proposals are all active in 2017-18.

take for instance confidential payment codes.. or as gmaxwell calls them "Pedersen commitments", they add bytes to a transaction which obviously if you multiply that by the number of transactions.. equals a bigger block..

please gmaxwell take an example transaction from 2015(pre-roadmap).. and then re-arrange all the bytes to make it an example transaction based on   all the roadmap features included as of 2017/8.
i know temporarily you can subtract X bytes to show what would be 'visible' in the blocklimit (of 2mb when blockstream finally give in). but when you have the total amount of transactions allowed in the block.. please also include the 'invisible' bytes multiple back in.. because they are still relayed TO FULL NODES.
i guarantee you the roadmap does not lead to just 2mb of real data with the 2mb blocklimit.. i guarantee you its not even 4mb with the 2mb blocklimit..

but..
all gmaxwell can do is say segwit is fan-dabby-dozzy and wont cause bloat or contention.. (because everyone will use the pruned/no-witness modes)

[gmaxwell]

CT isn't part of Bitcoin Core's roadmap at this time; but somehow its not shocking that you're vigorously opposed to it for unexplained reasons.  There are like a bazillion people on /r/btc who would love to hear your theories that Bitcoin Core is bad because the blocks will be _bigger_ under it's plans though, I suggest you go share your theories there.

[franky1]

CT isn't part of Bitcoin Core's roadmap at this time; but somehow its not shocking that you're vigorously opposed to it for unexplained reasons.  There are like a bazillion people on /r/btc who would love to hear your theories that Bitcoin Core is bad because the blocks will be _bigger_ under it's plans though, I suggest you go share your theories there.

so no actual numbers then?
so blockstream paid coders are now backing out of CT
well we already seen the hardfork was proposed for 2017.. which you and luke JR are now pretending was also not part of the roadmap.

i wonder what else is going to be backed out of and pretend it was never a part of the roadmap.

im guessing you actually did do the maths and realised the initial roadmap which meant to be completed in 2017 had a bloat of over 5mb.. and now your back tracking and trying to bring it down to a conservative 3.6mb.. oops sorry i forgot backtracking no longer includes the 2mb hard fork.. so a conservative 1.8mb real data bloat without the hardfork included.

[Kakmakr]

We can debate this until we grow very old, but the point is this. The can can only be kicked down the road, until the road ends. At some time in the future, once everything have been tried to bypass the block size problem, it will have to be increased. Only time will tell, when this situation will be forced and not asked for by the people. ^smile^

The road will end soon, LN and side-chains will not be the ultimate solution. 

[Lauda]

The community has thus far been complacent enough to  accept by default the leadership of core, but in the face of continued stagnation, one has to wonder: "but for how much longer?"

There's no stagnation, just random fear mongering. Seeing that you listen to franky's nonsense is more than everyone else needs to know about the type of people supporting controversial HF's.

The road will end soon, LN and side-chains will not be the ultimate solution. 

The irony here is that a increase of the block size limit is no solution at all.

[franky1]

The irony here is that a increase of the block size limit is no solution at all.

^ says a blockstream devotee who doesnt know C++ or much java and has not even read a line of code.

Whoever I've asked previously (as I don't do C++ myself) said that the complexity is overblown by a 'certain group'.

if i would to rank blockstreamers out of 10, based their opinion beyong backed by first person knowledge.. 1 being dont trust and 10 being believe.
gmaxwell is a 6 but lauda is a minus 50.

lauda is clueless, he just repeats what he has been spoonfed but has never used his own mind to actually look into what he has been told.

though gmaxwell has obvious bias in regards to his opinion.. i would actually like some factual data from gmaxwell about the actual REAL bloat vs capacity ratio.

EG
blockstream (backtracked): 1.8mb for 4500tx
2mb hardfork: 2mb for 5000tx
or
blockstream (original road): 5.7mb for 7500tx
3mb hardfork: 5mb for 7500tx

note. yes im ignoring lauda and gmaxwells blind assumptions that an AVERAGE transaction is ~250bytes.
because they blindly assume 1mb gives 4000tx now, and will give 1.8x that (7200 in their backtracked roadmap or 14,400 in the original)

 when real stats that can easily be checked shows the average is 400-600bytes per tx, so a better assumption is about 2500tx for 1mb block as a safer number of realistic usage, rather than 4000(250byte) they claim now
you too can easily do the maths. i wont be cherry picking.. instead i will just grab the last 10 blocks at the time of posting

take block 415033... 988,135bytes .. 1342tx     988,135/1342 = ~744byte/tx average
take block 415032... 998,086bytes .. 2439tx     998,086/2439 = ~409byte/tx average
take block 415031... 840,904bytes .. 1391tx     840,904/1391 = ~606byte/tx average
take block 415030... 320,119bytes ..   350tx     320,119/350   = ~915byte/tx average
take block 415029... 998,221bytes .. 2600tx     998,221/2600 = ~383byte/tx average
take block 415028... 579,085bytes .. 1268tx     579,085/1264 = ~458byte/tx average
take block 415027... 436,392bytes ..   800tx     436,392/800   = ~545byte/tx average
take block 415026... 232,350bytes ..   469tx     232,350/469   = ~495byte/tx average
take block 415025... 517,189bytes ..   895tx     517,189/895   = ~578byte/tx average
take block 415024... 173,321bytes ..   349tx     173,321/895   = ~496byte/tx average

average = 563.. not 250.. the 250 is the MINIMUM not the average(median)