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

It's a great statistic if you're talking about typical transaction fees, which I believe was the original topic.

^ I would mock too, but I suspect you are here for that. I do laugh at your ridiculous insistence on remaining ignorant.

I think your right.

But when you tell us Greg laugh's. Then Icebreaker mock's. Carlton mock's and finally Lauda mock's.
I wanted Greg to answer, as he was bothered to laugh at you.

easy maths
average blocksize
https://blockchain.info/charts/avg-block-size?timespan=30days

divided by average transactions per block
https://blockchain.info/charts/n-transactions-per-block?timespan=30days

10th may: 721,200byte / 1543tx = 467byte/tx
11th may: 772,400byte / 1725tx = 447byte/tx
12th may: 792,500byte / 1642tx = 482byte/tx

then ill skip a few to highlight the high of that data
19th may: 951,900byte / 1728tx = 550byte/tx

and the low of that data
23rd may: 587,600byte / 1095tx = 536byte/tx

on a previous post i also done some maths on 10 blocks based purely on the time of posting.. rather than the generalised numbers of blockchain.info daily stats

nowhere was i seeing any pattern that related to 226-250 transaction averages.
and no where in the reality of real people making real transactions does 226-250 have any big correlation

It would put bitcoin on a different path, maybe.
segwit is dangerous and unnecessary at this point.



It doesn't matter. It is not eternal. The sudden hard fork option is always waiting.
A hard fork should not be taken lightly, ergo will take time but is unstoppable and sudden(ish) when achieved. (predictably out of desperation)

Sorry guys, Greg not interested.

They don't want to do both. It's Blockstream's way or the highway. If something goes wrong, they will just declare "Bitcoin can't scale" and blame it all on bitcoin. Wow. Amazing leadership guys!

Long reading - one meaning: WE NEED BOTH (and  more for sure in new Releases)

Still  2MB  HF  would just do fine - but it's  toooo   easy and nobody gets the cheers & credits for implementing.

So than do BOTH and mess up the code a bit and get the merrits.

why do you think the blockstreamers are monero obsessed.. such as gmaxwell and the other REKT spouting clan.. they love altcoins.
why do you think bitcoin-devs are now concentrating on sidechains.. even gmaxwell has turned a proposed CT from being in bitcoin to now being just a sidechain thing.. even luke JR spends more time with the sidechains project then he does on bitcoin. luke Jr is literally salivating at the chance to merge mine lots of sidechains and grab all them rewards

side chains would be useless if bitcoin had the capacity it needed so its not hard to see why blockstreamers are so against logical capacity increases and instead want to twist bitcoin into being expensive to use unless you stop using traditional bitcoin features.

Blockstream needs to go, they are not competent. Solving scaling is easy. Raise the blocksize, as Satoshi intended. If they can't get segwit to work right or to be adopted, then bitcoin will never scale under the failed leadership of these fools, as they will never in a million years raise the blocksize. That will basically guarantee another coin to pass up bitcoin.

everyone can remember the promise that hard fork (everyone upgrading) was not needed because softforks dont need consensus, that segwit can be "compatible" with old nodes. and everything was honky-dory with fluffy clouds and unicorns flying to the moon.. and everyone gets to still be a full node and a free chocolate cookie

but here is a blockstreamer admitting that a softfork is not as soft as they first said.. if it was soft it could get activated with out any adoption.. which was the whole point of why people first loved segwit instead of hardforks
but now its actually admitted to require adoption just to activate, making it actually a harder-than soft fork.

now people are wising up that it need consensus and a high percentage of adoption to activate.... just like a hard fork

so here is a radical thought... you may need to sit down and take a few minutes to think about it..
wait for it..
here it comes..

include the block limit increase with segwit....

but before you cry your wet dream admiration's for blockstream.. remember this.. read it, sit back have a coffee and think outside of the box about what im actually about to say.. take a few minutes to let the thought settle in your mind before you shout out your blockstream admirations about why not to do it.

just because the blocklimit will be 2mb.. there is nothing in the rational world of reality that suddenly causes a block to bloat to 2mb in size instantly after activation just because the new limit exists....
the block limit is not a rule to say 'this is the the amount of data needed before we do anything'.. instead its about allowing anything from 0-2mb.
again for emphasis.. its not a rule that says only accept 2mb blocks.. but anything under 2mb(meaning 0-1mb can still be accepted)

EG in 2013 when blocks were finally allowed to surpass the 500k buglimit(related to databases) to then fully embrace the 1mb blocklimit.. blocks were not instantly 1mb in size.. miners were not ejaculating happiness that they can now bloat blocks instantly with 1mb of data..
instead it allowed a couple years to naturally grow at a natural pace..

so while we are now seeing that segwit actually requires people to upgrade, not just out of personal choice, but as a vote/consensus just to activate it.. (finally blockstreamers are starting to admit it) you might aswell increase the potential blocklimit tooo...thus allow for potential growth without needing the constant oliver twist tactics every couple years of "please sir can i have some more".

as for the proposal of just 1.05mb or 1.25mb.. that is also a short term thing that wont deter the oliver twist scenario for as long

but i can already predict 4 responses.
1. gmaxwell admitting all his code and features are meant for sidechains and he doesnt see the need to expand bitcoin or include features he is coding for bitcoin, things like CT wont even be in bitcoin... thus pretend bitcoin issues are not even in his remit to be involved in,
even if he has previously highlighted his features in context of bitcoin by mentioning the words bitcoin more often then his sidechains coin names while talking about his features.*
*https://people.xiph.org/~greg/confidential_values.txt  - mentions(bitcoin:20 zerocoin:1 elements: 4)
2. luke pretending he is not part of the core-devs and his agreement to code the hardfork was not meant to be part of core, but he did enjoy the free vacation in asia.
3. lauda replies with some insult and not actually address the issue.
4. other blockstream fanboys, if not insulting, will atleast try to suggest that hard forks should only be about "classic" debate and not even consider core including a hard fork, followed by those same blockstream fanboys using buzzwords like bigblockers, gavinistas, and maybe even use some latin rhetoric they learned from each other without even checking the context of when or how it should be used.. before ofcourse running back to go play with their monero

Median exists for a reason.

Well, obviously. If the Segwit soft fork does not get activated then there can be no adoption. However, I don't see a reason for which it should not get activated.

Yes, that is the median TX size.

Oh yes, sorry for the shabby punctuation. It made you read it wrong, which in turn caused you to dismiss me as irrelevant and illogical. My fault.

Re read to understand my points, now you see it is logical.
But with no activation there is no adoption.Is that correct?


(bitcoinfees.21.co also quote this 226 "median" number?)

I still don't get it. Why would anyone waste any time calculating "median"? It's completely worthless.

Well then that is something else entirely. Posts that have weird formatting and/or punctuation can end up being interpreted wrongly. Are you talking about adoption (i.e. users) or activation (as in the Soft fork itself)? Because in the first case that assumption will never become true. In order for zero adoption everyone would have to move away from wallets that incorporate Segwit. What are the odds of that happening?

Because franky has been chasing both Maxwell and me (among others) around with his nonsense when he didn't even understand what median meant in the first place.

So why are you talking about the median? It is a completely worthless statistic with regards to this topic.

I'm sure you just read it wrong.

I mostly said segwit will take a long time to have any effect on block space.
but I did also say segwit will have no effect in the event it never gets adopted.
That is a possibility. It is not logically wrong. It maybe against your opinion.

It doesn't matter whether you have a opinion or not when it is logically wrong. Saying that Segwit will never make a difference is wrong. As soon as we start seeing Segwit transactions (i.e. we reach any kind of improvement, e.g. 1.05MB), we will notice the improvement.

Yes. That's what the last calculations done by aj (IIRC) on the mailing list show.

What is this even supposed to mean?

It has been in testing for more than 5 months now.

The go ahead and propose a properly designed BIP and not something improperly designed with added limitations such as the one that Gavin proposed.

Who was ever abused for disagreeing with staff members? I don't recall any examples of such.

There is no such thing as a "staff opinion". This is solely Lauda's opinion and is in no way related to the opinion of any other staff member or the forum itself.

Yup, "I don't see blocks with 4000+ transactions as the median 226 would imply."
But, as pointed out it does appear to be the median.

I have asked Greg if he knows the average transaction size as that figure would indeed be more relevant here.

So Core claim 7200(?) median, mean or maximum transaction per block with segwit?
(compared to 4000(?) today, median?~)

translation
"Q:guys how do we hide the fact that transaction sizes will bloat when people do calculations of the potential blocksize vs potential transactions per block after all the proposed features are included..?
"A:dont talk about averages, dont use 'mean', we can manipulate numbskull opinion by talking as if we are suggesting average but actually quote a median number.
"Q:how does that work
"A: well if we had 0,1,2,226,227,228,229 the median is 226.. if we have 0,0,0,226,5000,10000,500000 the median is still 226... if we have 0,226,1023435453 the median is still 226
"Q:so why should we pick 226 as a special number..
"A:because that is a safe minimum transaction size, its not the absolute minimum, but its a safe minimum people expect to see.. and if we try to talk about this minimum in a way that makes people presume 226 is expected atleast 50% of the time. or the majority of the time.. we dont have to explain real data because then it is revealed that us blockstreamers are actually the "bigblockers".. where we offer less transactions per megabyte then the simple blocksize increase alone
Q:so 226 is useless as a relevant number for people who actually want to do multisig, or LN lockins/settlements or numerous other things like paying more then a couple people..
A:yea 226 has nothing to do with what a person should expect on average.. its just a arbitrary number to shift the debate away from real maths of real data and peoples real expectations of reality.. but dont tell anyone.. lets keep misleading people and then insulting those that do show real averages to make them sound like they are wrong and we are right"