Matt Corallo proposes 1.5mb blocks after segwit

[pawel7777]

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

1) The segregated witness discount is changed from 75% to 50%. The block
size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
maximum block size of 3MB and a "network-upgraded" block size of roughly
2.1MB. This still significantly discounts script data which is kept out
of the UTXO set, while keeping the maximum-sized block limited.
...

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

[BTCBinary]

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)

[Lauda]

PR stunt?

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.

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)

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

[Denker]

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)

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.

[franky1]

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

[jyakulis]

I'll see his 1.5 and raise him 1.25.

[Cconvert2G36]

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/

[BlindMayorBitcorn]

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

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

[Lauda]

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/

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

I'll see his 1.5 and raise him 1.25.

You mean lower?

[jyakulis]

You mean lower?

Whatever lol

[franky1]

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

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

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

[madjules007]

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

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.

[Tavos]

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

[franky1]

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

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.

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

[ebliever]

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.

[jonald_fyookball]

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.

[madjules007]

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

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.

you really are missing the point.

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.

people want capacity increases more then features.

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.

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

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.

[madjules007]

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.

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

[jonald_fyookball]

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.

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. 

[franky1]

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