Bitcoin Forum

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/ (https://np.reddit.com/r/btc/comments/43h4cq/they_coreblockstream_fear_a_hard_fork_will_remove/)

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.  :D

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?

I've been saying this for 6 months now. 

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

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  :)

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.

https://i.imgur.com/gTKTSus.png

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... :P

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 (https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112) 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

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 (https://blockchain.info/block-height/115000) 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.

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.

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

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)

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.

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. 

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.

^ 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)

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.

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?

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.

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.

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..

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.

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..

No. 226 is actually the _median_ transaction size.


In [46]: pp = AuthServiceProxy("http://bitcoinrpc:password@127.0.0.1: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.

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

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.

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.

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

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"

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?~)

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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!

Sorry guys, Greg not interested.

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)

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

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.

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

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

Correction: A block size limit increase is dangerous and unnecessary.

I have no idea why you would pull me into this one. I have used various average TX sizes when doing some basic calculations in regards to capacity, and have even used sizes larger than what franky is showing here today. It comes down to the nature of the use. My transations are is closer to the median in size than to the average.

Rofl "You are all blockstream shills!!!" Is the best thing ive read all day. I can finally go to bed 😊

.                 ~Paid for by Blockstream~

Assuming the original topic was also on the forum or some other public space, a link to said original topic would be really useful here...

this is because lauda only has a couple addresses and only pays one person at a time. so his experience is limited to his own usage..

however people that have re-use addresses where funds are spread over multiple addresses, have larger txs
however exchanges batching customer withdrawals together so there are multiple outputs have larger tx's
however pools splitting up the block reward to pay the many individual miners have larger tx's
however merchants, services, businesses who collect or spend from or to multiple parties have larger tx's

so trying to brush the average transaction to be "just like lauda's" is a mindset of someone who cannot think beyond themselves.

i find it funny that lauda tries to say bitcoin is great most transactions are 226bytes..
and then.. he says this..


its either he never believed his own stupidity of the 226byte sales pitch.. or he is finally wising up and being honest to people.
if its the second one. then well done lauda you have finally said something correct.. please continue and be honest from now on.

There was no real 'topic' here. You can only find a few individuals failing with their ad hominem attempts. It usually just proves to be a waste of time to interact with them.

I always suspected that you were paid by them!

Ok, so the median tx is 226 (and never seems to change)
But the average tx is twice that? (and varies)

I am asking 21.co why they use median tx size to calculate fees.
Their first reply said "Median is the same thing as Average." !!!
(which we all now know it isn't)
Goes to show what the general perception is I would think.

Greg say's about median, "It's a great statistic if you're talking about typical transaction fee,"
How so?

If average tx is twice median tx, will this not lead to under paying tx fees?
(i am asking 21.co also)

Franky, are Core saying segwit will handle 7200 tx per block? (link please)

it depends on which variant you read.

for instance if we naively go by the every tx is 226byte right now..
1mb block= ~4400tx so segwit would be 7920(4400*1.8 )

then others say that the average is 400bytes but core will eventually allow 2mb in 2017
1mb block = 2500tx so 1mb segwit would be 4500tx(2500*1.8 ) and 2mb segwit 9500

then others say that the average is 500bytes but core will eventually allow 2mb in 2017
1mb block = 2000tx so 1mb segwit would be 3600tx(2000*1.8 ) and 2mb segwit 7200

but remember a 2mb segwit is not actually 2mb of real data.. its actually 3.6mb where 1.6mb is still there but blockstream wont talk about it because "there is no witness"
also remember there are extra bytes being added for the other features, flags, etc.. so the blocks would actually be much higher then 3.6mb when a block is 'full'.

but seeing as Gmaxwell has withdrawn his plan to add CT to bitcoin(instead trying to promote his zerocoin, monero and elements). the bloat wont be as much as the over 5mb from the original plan.
so lets just take the stats of
3.6mb(real data) for 7200tx as a guideline expectation if there is 2mb blocklimit included in 2017..
1.8mb(real data) for 3600tx as a guideline expectation if there is 1mb blocklimit remaining in 2017..

Compare apples to apples and oranges to oranges, the closest your quoted post provides to such a comparison is as follows:
15400tx (blocksize 3.5 mb) @ vs 15840tx (segwit w/ 2mb)
It's not accurate since 3.5 mb < 2mb segwit, but none of the other numbers line up at all.

To be clear, I'm in the hard fork camp.  I'm not 100% pro or anti regarding segwit or blocksize, but I am anti regarding a soft fork for a major change.  However, I'm calling you out because you shouldn't be playing their game.  It isn't right when they're playing it anti blocksize, and playing the same game anti segwit doesn't make it any better.

But " I propose we work immediately towards the segwit 4MB block soft-fork" (Gmax)
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

segwit is 4mb.

yea i noticed that. so edited to be easier to comprehend

that was when Gmaxwell thought the plan was 2mb blocklimit AND segwit.
in the same paragraph he said

which is where he got the 4mb number from. but more recently its suggested to be only 1.8x capacity... hense new numbers are 3.6mb(real data) for 2mb block limit,
also when using the 1.8x in combination with the average tx size brings out the 7200tx a block everyone is throwing around as segwits promise..

yet listening to Gmaxwell and Luke JR in the last month.. it looks to be 3600tx for 1.8mb(realdata) while sticking with just 1mb block limit

Is that the median tx size you mean here?
Average is (you calculated) over 500 byte.

its the AVERAGE lol
as explained

Yeah, "others (you and me) say" average 500 byte.
But segwit supporters say "1.8x in combination with the average "median" tx size brings out the 7200tx..."
They wouldn't say "average" in this context would they?, as according to your own (seemingly correct guesstimates) that would be a lie confusion on their part.

Sorry, I'm not trying to be an idiot. It is important (to me) as who is claiming what, and why median is used.
I will reread!

As you know I have asked Greg if he knows the average tx size, and why the median, not average tx size, is such a great fee size indicator.
Still waiting.
Even 21.co seem a bit flummoxed.

edited

Things gmaxwell may be hoping you ignore in this post:

- Gregory Maxwell greg at xiph.org, [bitcoin-dev] Capacity increases for the Bitcoin system., https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html)

The 'average' tx mostly doesn't exist. The sizes of transactions are highly multi-modal. There are a whole lot of small ones (most ones people make) and a decreasing number of larger and larger ones that drag up the average. If you're joe-schmoe and make a transaction, it's most likely you'll make a median sized one.

It's like saying the the average number of testicles an American has is 1... and yet relatively few people have exactly one testicle, even though it's the average.

[In no case should fees be under-paid... in competent wallets fees are configured per unit size and set accordingly. :) ]

Another way to think about it is that "a transaction" isn't really a great unit of capacity. Consider, what if everyone started using 4-party non-amount-matched coinjoins for all their transactions. We'd end up with 1/4 the number of "transactions" each of 4x the size. Would it be right to say that suddenly the Bitcoin network had 1/4th the capacity because now the tx were 4x larger?  No-- they're also doing 4x as much.

You could say this only if you know the characteristcs of the tx size distribution (of the future!) or at least the first moments. the average or mean as you know is a very good estimation while the median is just the mid of all sizes and a just bit more stable against outliers. And the density is highest where?

IMHO

If it aint broke, dont fkkn fix it.

What's the median number of testicles?

Median transaction size is now 327 332
44% increase.

https://bitcoinfees.21.co/