How are the features going to "mess with the capacity promises of blockstream?" Any math to go along with these silly claims, other than the impressive argument that "1.5mb is just a stupid low amount?"
Which is it? Because I hear all the time that a block size increase is urgent, and that Gavin is "compromising" because he feels that 2MB is "absurdly small." Now suggestions to increase capacity via segwit and a 50% block size increase to accompany it is "stupid low?" Hit me with the math, Franky.
I hate to say it, but it sounds more and more like you take issue with any resolution suggested by Core devs, regardless of the substance of those suggestions and without any evidence to back your claims.
your about as narrow minded as Lauda.
where is your maths?
so here goes
1mb can on AVERAGE hold 2500tx(400bytes each).. and a sig is average 71bytes
segwit proposes shifting the sig, so initially you would think that average tx goes from 400bytes to 329bytes average.. but no, because there are flags which add a couple extra bytes. so lets say thats 69 bytes saving (331bytes/tx) =3021 average tx thanks to segwit (warning: temporarily)
now lets pretend blockstream increased it to 1.5mb
4531 tx average.(warning: temporarily)
but lets now add on the extra 40 bytes atleast needed for the payment code (opreturn that was 40bytes for some time, but will be 80 again) and the other little bytes here and there for all the other features like lightning network and sidechains..
guess what that 69byte saving in the mainblock is now no saving at all.
so with all these updates and tweaks changes and forks and increase to 1.5mb.. all we have gained at most is not 2031tx extra transaction average(4531 tx average total per block) but 1250 tx extra average(3750tx average total)
So let me confirm one more time. You are judging Classic's proposal based on 2MB with no conditions... You are then judging Core's proposal based on 1MB vs. all optimizations that would be built into the code anyway. That is called "comparing apples with oranges."
Or are you suggesting that no layers should ever be built on top of the blockchain? That, of course, is not up to you.
Again, this is no different than you complaining about the size of multi-sig transactions. Your comparison is basically saying "Core uses multi-sig transactions, which take up more space. So any capacity increase is bullshit. Classic doesn't use multi-sig transactions and never will -- and no other features or layers can ever be built onto Bitcoin. So you can't count any of that stuff against Classic's 2MB limit."
You can complain about Confidential Transactions and Lightning all you want. People are going to use them because they are useful. That is not your choice to make. You can choose to accept that multi-sig transactions (along with future features of the protocol) exist and that people will use them (thereby adding "little bytes here and there) ....or you can deny it. But if you choose the latter, don't expect people to take your fuzzy math seriously.
In the end, you never even showed the math for 2MB blocks. Your math errs on the conservative side for signature size, and does not account for growth in the use of multi-signature transactions. I.e. a 1.6MB block of standard transactions = a 2MB block of 2-of-2 multi-sig transactions. Do you expect use of multi-sig to decrease?
Ignoring your conservative numbers for signature size and your lack of accounting for growth in the use of multi-signature transactions, your numbers imply less than 10% difference between 2MB vs. 1.5MB+segwit. I think a more thorough analysis would reveal that this is being overly generous to Classic. I find it sufficient for now that for such a small difference, Matt Corallo's suggestion of 1.5MB is still a "slap in the face." I think it's clear who is being reasonable here, and who isn't.
but wait.. why 1.5,,, why not 2mb.. seeing as there is going to be a block limit increase and all this change. lets make it 2mb.. and then we can have 5000 tx, with all the extra data that blockstream added aswell..
You're not giving any reasoning. If 1.5MB, why not 2MB? That's your logic. Fine, if 1.5MB, why not 8MB? Why not 32MB? Why not 4GB? Why not 8GB? Why not 32GB? Cuz Franky says, "We can haz more tx!!!11!!!11!"
more then enough buffer space to grow and have some room for peace of mind. just like in 2013 when people were not worried about the 1mb limit because miners were making 1200 tx(half a meg) and had plenty of room to not even think back then that the block limit would cause months and months of debate.
Debate is good. Pushing a contentious rules activation at 75% miner agreement, and then rolling out a hard fork after less than a month will likely break bitcoin's ledger forever. On that note, I noticed you stopped responding to our argument about why Group C would never have its blocks orphaned, and why multiple blockchains would result. That isn't "peace of mind."
a 1.5mb is just a gesture of crappy non reasoning increase that does not really provide enough buffer room for miners to expand in their own time.. with a 1.5mb increase we will just be debating the block limit again within 12 months.. so lets increase it to 2mb so that it gives developers a couple years(hopefully) of headbreathing room to have calm and peaceful time to work on more things. instead of forever chasing their own tail endlessly every year.
"Does not really provide enough buffer room for miners to expand in their own time?" What the hell does that even mean?
Again, debate is good. And a minimal block size increase that can be more realistically simulated (i.e. a testable regime) then rolled out in a far less controversial hard fork initiated by a much more established and experienced dev team via an update -- like any update before it -- sounds great. That sounds better than a small minority of inexperienced devs pushing a hard fork as a takeover, without miner consensus and with minimal notice for nodes to update.
i personally think that people can handle more then a 2mb+segwit limit. without being a data center..
but the majority of people think that 2mb is a good enough MINIMAL number that gives enough breathing room without the arguments of doomsday datacenter theory.
but 1.5mb.. thats just a slap in the face small increase that is not helpful to ease the issues. and is just proposed mainly to keep the debate running nonstop.
Remember, your argument is that "Core=Blockstream." You compare 2MB vs. 1.5MB+segwit. (We know that Classic is 100% dependent on Core to implement segwit compatibility in Classic, so there is no basis for talk of 2MB+segwit to begin with -- it's not clear whether Core devs are willing to do the work for Classic or not)
Please provide evidence that 2MB blocks put no pressure on bandwidth requirements of nodes. If not, suggest what degree of negative effects on node health is acceptable under your proposition. Or do you believe that node health is not an issue at all?
It's funny to me that 1.5MB is a slap in the face, yet 2MB (as long as Gavin pushes it) is acceptable.
