Topic: Why Blockstream is against "contentious" hard forks - Control - page 3. (Read 3306 times)

"Hyperbolic nonsense", yeah maybe, we all got an opinion. Some more credible than others.
(ftr not a dig at Lauda)
A realistic 180% "after some time"? if every transaction, paying less fees to miners, was segwit?
(Miners do more work for less fees. full nodes need more bandwidth than 1.8mb, think that is part of what Franky is saying?)

I am saying I don't want segwit. At least not yet, untill it can be more tested and proven.
Correct, 2 mb is not actually needed today. 1.25 would suffice.

(oh, just noticed the "hernia & co" comment. If we don't say the same thing as "staff" we are abused? shocking and ridiculous considering no thread here, discussion, goes without Laudas staff  "opinion")

Nobody said that it wasn't.

Hyperbolic nonsense, nothing surprising there. If you want additional capacity, you will try to use Segwit as soon as possible, otherwise you are indirectly stating that you don't need/want it. It is as simple as that. The calculations have been done and we can expect a realistic ~180% capacity after some time (certainly not "ages or never").

2 MB block size limit is not needed today. It has just been sold that way by Hearnia & co.

226 is the median transaction size.

I'm not surprised the confusion here.
There are no big outright lies here, just confusion (of official and officially implied?)
Franky is not wasting my time.
If clear answers as above were more commonplace...

I don't see blocks with 4000+ transactions as the median 226 would imply.
Is the mean transaction size very similar to the median do you know?

segwit will have little to no effect on Block space for some fairly considerable time after any soft fork, and that soft fork will likely take some fairly considerable time from now. Segwit release/adoption/bugs are all of an unpredictable nature.

Are we all supposed to wait as long as segwit takes to make a difference. (which will be ages or never)
Is bitcoin adoption on hold from now till then?
Or is this your idea of a fee market?

segwit maybe for the future, when it is needed, (or not) and properly tested.
segwit is not needed today. It has just been sold that way by core. Obviously.

"median" is not a very interesting number when considering blocksize. "mean" is far more useful to estimate how many transactions are likely to fit in a block.

No. 226 is actually the _median_ transaction size.


In [46]: pp = AuthServiceProxy("http://bitcoinrpc:[email protected]:8332")                                   
In [47]: txa=[pp.getrawtransaction(x,1) for x in pp.getblock(pp.getblockhash(415093),True)['tx'][1:]]
In [48]: sum([x['size'] for x in txa])
Out[48]: 999724
In [49]: numpy.median([x['size'] for x in txa])
Out[49]: 226.0


Same story for pretty much every block.

(Minimum is 189 in that block FWIW).

Franky1, in this case you were just confused-- but you've got a number of other claims like saying CT is part of core's published roadmap, that are outright lies. I think you need to stop wasting everyone's time.

Straight from the closed minded #REKT thread  of funny spelling and composition competitions.



But only just becoming noticeable to the punters.


Yeah, Core and #REKT fans always go off on this tangent. 1mb or infinity. 1.25mb will destroy bitcoin?


Completely not a fact that the block size can not be raised. Should Intergalactic Conciliator's be calling people morons?


Just for a bit longer. Core will have had their chance, and will be the next hearn.
A rapid hardfork to increase block size will likely come when the segwit reality becomes clearer, and when blocks really are at capacity and beyond.


Just waffle these days.


It is a solution to processing more transactions.


Old enough not to think i'm a Intergalactic Conciliator, represented by action men avitar.


We all f*** up sometime. I got the math point you were making.


Shitty OP. All outdated links. I was gonna let this thread pass by like that other, now very popular sig thread "My life has all been a lie" cos the twat thought he had 1000 satoshi, not 10 he really had or something like that..

It's incredible how skewed your perspective is. You got it all reversed. The maxblocksize hardforking efforts originate from a deliberate covert campaign of creating disinformation that people like you spread as misinformation. You are helping the real "bad guys" while fully believing the lies they have sold you... If you're not an idiot you will do far more research and come back with a much broader perspective.

lauda thinks MEDIAN means minimum.. wrong
he has said on many posts.. and also gmaxwell too, has stated the median transaction size is under 250bytes..

median does not mean minimum..


but gmaxwel has


again the 226byte is MINIMUM.. not median, not average.. the median is about 500.. the average is similar
median means middle number. and is usually close to an average, well atleast in the same ball park.. its definetly not the minimum or the maximum.. but the amount between the two..

Correct. While I might have wrongly used 'average' instead of median somewhere (I don't recall all of the times that I've written about this), Maxwell never did. Franky does not know the definition of median TX size which does not surprise me at all.

It was never part of the Bitcoin Core roadmap. There is (I think) only one roadmap for 2016 and it was not changed at all. The original estimates and content are still part of it. He has either gone made or thinks Core == Blockstream (which would also be wrong since he does not know the 'roadmap' of this private company).

He can't. He will do one of the following:
1) Request math (not relevant) while he provides false calculations.
2) Lauda doesn't know C++.
3) Maxwell is a liar.
4) You are all Blockstream shills.
5) Other irrelevant nonsense.

I could not agree more.

Can you link to the Bitcoin Core roadmap that included CT please ? The only roadmap I am aware of is the one linked below and doesn't mention Confidential Transactions (CT).

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

If you aren't able to provide a previous Bitcoin Core roadmap that included CT, then you should apologize to the forum participants for wasting their time and specifically to gmax for posting deceitful information.

In general, I think the moderation policy is much too lose on this forum, especially when I see energumens like you wasting everybodies time, adding negative value to the forum and generally diminishing the posting quality. Unsheathe the perma bans.

the most Bitcoin developer and the lead developer are not payed by blockstream but bitcoin is controlled by blockstream.. heh??? lol
How old are you?

It really is impressive how much time you've spent spitting out numbers and crying foul about block sizes without spending 30 seconds looking up, "median", in a dictionary. Despite how often you like to bring up Lauda not understanding C++ or Java or whatever, you don't even bother making the effort to understand the basic terms you're trying to argue about--and it's not as if this is some isolated incident. Yes, the average transaction size is greater than 250 bytes. No one ever said otherwise. It doesn't matter what accusations you levy or what numbers you cook up if it's all based on basic misunderstandings.

Sorry for this rather off-topic post... My fault for not having franky on ignore, I guess.

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

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)

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 irony here is that a increase of the block size limit is no solution at all.

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. 

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.

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.

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)

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?"

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.