Bitcoin Forum

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html


PR stunt or honest attempt to find compromise and middle ground?

I don't get it. Why doesn't everyone agrees on the same for once. The scalability problem will not be solved by a 2mb block increase, less with 1,5mb. I even think that we should increase the blocks to 8 mb or more because there will be another block increase demand before the next halving (2020)

I'm hoping that your assumption is a joke. Here's what we have:
1) Core doesn't propose any block size increase -> People complain.
2) Core proposes a block size limit (albeit a single developer ATM) -> People complain.

---

---

I wonder how long the grace period would be though. I would not mind this with a high consensus threshold.

You would break Bitcoin today. Please don't post suggestions without relevant knowledge/sufficient testing.

If you would have followed the debate the last 12 months you would know that such an increase would be very stupid and the worst thing you can do at the moment.

here is some PR:

50% signature discount
limited time only.*
*discount expires when features like 'confidential transaction codes' rebloat up the data in the main block.


and so 1.5mb block increase is just a laugh.. its not going to offset the new features to still give people more capacity

I'll see his 1.5 and raise him 1.25.

A PR stunt rolled out on the day that /Classic:0.11.2/ is about to take the spot of the second most common node on the network.

https://bitnodes.21.co/nodes/

You don't dig confidential transaction codes? What about sidechains?

No. There is no reliable way to measure the amount of nodes that there are. If anything we have seen that this is a very unreliable metric even though nodes are very important (IIRC there was a guide on how to setup 3000 'nodes' easily).

You mean lower?

Whatever lol
https://45.media.tumblr.com/cae96eb5cae58fc4a57d65305e3a7f1d/tumblr_mslxo4YIjv1rdutw3o1_400.gif

i dig confidential transactions and sidechains and any other little opcodes and variables they add to make bitcoin more useful.
but not at a cost of:
causing less capacity
causing people to value a sidechain more than bitcoin

so as long as they increase capacity in a real way, and not a bait and switch fake promise. and sidechains adds extra utility to bitcoin, and not take away utility from bitcoin.. then things are great.

but blockstreams roadmap for the last few months has not been consumer/community orientated. so lets hope blockstR3am change their ways and do what they should do, for the community. not their personal impulses

Multi-sig transactions take more space than standard transactions. Should we "ban" multi-sig transactions because they take up too much space for your taste? Features should be judged on their merit, too -- do they provide a service? Increased security? Privacy? Then perhaps these features can be justified. Whether these features hold merit in spite of making transactions larger is a completely separate question from whether we should increase capacity at this time.

That "multi-sig or confidential transactions take up more space" does not mean that "increasing the block size limit =/= increasing the block size limit." Either we're making room for more capacity or we aren't. People are going to use multi-sig transactions regardless of how much it irks you, Franky. So the question then becomes "how can we optimize throughput and to what extent can the system handle additional capacity?"

Unless you really think "banning" multi-sig [and confidential] transactions is a plausible or reasonable idea. :D

1.5mb is a joke, it's a fairly small increase and won't make too much of a difference with confirmation times.

you really are missing the point.

people want capacity increases more then features.
so if the features mess with the capacity promises of blockstream then blockstream wont win favours. no matter what their features are suppose to offer. and 1.5mb is just a stupid low amount just to pretend they are listening to the community without actually doing what the community want.

a 1.5mbsegwit block in 2017 WILL NOT!!! give a 50% capacity increase compared to today. 1.5mb is a pointless and fake gesture that solves nothing

A 50% increase only buys months worth of time before we go through this again. We've been arguing about it longer than that already.

Matt who works for blockstream.

What a pathetic 'offer'.

How about we just go with 1.01 mb became that should keep the big blockers happy.

Am I? Because segwit adds nearly the capacity of a 2MB hard fork. And a hard fork to 1.5MB would add 0.5MB capacity to that (plus whatever additional segwit might provide under a 1.5MB regime vs. 1MB regime given expected growth in multi-sig transactions).

You were complaining in another thread that segwit alone wouldn't add enough capacity to justify confidential transactions. Now, with an additional 0.5MB per block suggested, you are again complaining about insufficient capacity to justify confidential transactions. Can you back up your complaints with some math to justify your incessant complaints?

Am I wrong to suggest that your complaints about confidential transactions also apply to multi-sig transactions? Would you then go on to argue that Core devs optimizing bitcoin for multi-sig transactions via segwit is also some form of trickery -- to trick users into believing they are getting more capacity than they really are?

Your whole approach is fear-mongering with no factual basis.


Do they? What proof do you have? I don't. I'm more concerned about adding privacy features to preserve fungibility than I am about capacity. I transact with bitcoin several times a week and I've never had a transaction delayed beyond the next block -- I don't complain about paying a few more cents in fees, either. We all have different priorities.


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.

A 100% increase is fine, but a 50% + segwit is pathetic? Please explain.

2MB was already meager.  We were discussing 20,8,etc...
Obviously we should be increasing capacity by orders
of magnitude. When 2MB idea came out it is really
the minimum meaningful increase. Just my perception
and opinion. 

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 capacity is not 2500 to 4531......... its 2500 to 3750 and that with a 1.5mb small bump
(but remember a 2mb without segwit, without any changes or extra features would be 5000tx)..

so the community want a possible capacity of 5000x and segwit wants to stay way 2500 at 1mb or atmost 3750 if they up the block limit to a crappy 1.5mb

so why 1.5??? why not 2mb.. seeing as there is going to be a block limit increase and all this feature changes. why just increase a little. lets make it 2mb.. and then we can have 5000 tx, with all the extra data that blockstream added aswell..2 birds one stone

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.

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.

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.

If they are gonna do this it would be better to aim for a higher amount than 1.5mb :)

How about making it variable to allow blocks to be anything from 0.5Mb up to (say) 64Mb.

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.


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


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


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


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.

It's funnier than that: Matt's "1.5MB" would have 31% more capacity than the "Classic" 2MB.

what's the point to have 3mb in total, after segwit? 1 mb = almost two with segwit with 1.5, would be almost 3mb

those small increase are not that good imho, it's better to go straight to a number of mega that can welcome the future adoption, greatly

i think many have forget that the adoption it's not going to increase linearly, so having 1 mor emega will not cut it at all

If we are going to fight like this, every time scalability is needed, we will be setting ourselves up for failure. How many years are we debating this issue now? The point is, we not fighting over the actual block size anymore. The internal politics are killing the real issue.

This is getting old now, and we should have found a solution for this months ago.