Block size poll: Which do you prefer?

[BitcoinXio]

Take the poll and cast your vote!

[rogerver]

I'm a big fan of a flexible cap.

[BitcoinXio]

I'm a big fan of a flexible cap.

Same here as well. It's a real shame there have been so many great solutions that have been presented to the community but yet nothing is being considered. I'm overall just in astonishment, which I think many feel the same way (and why others are working on Classic, Unlimited, etc). I'm hopeful still that we can get past and move forward and on to bigger and greater things. There are so many genius minds in bitcoin, and I hate to see so much time and talent wasted on this.

[harrymmmm]

I'm a big fan of a flexible cap.

Same here as well. It's a real shame there have been so many great solutions that have been presented to the community but yet nothing is being considered. I'm overall just in astonishment, which I think many feel the same way (and why others are working on Classic, Unlimited, etc). I'm hopeful still that we can get past and move forward and on to bigger and greater things. There are so many genius minds in bitcoin, and I hate to see so much time and talent wasted on this.

I'd be in agreement with a dynamic cap, but it gets complicated to make it ungameable, and we probably don't yet have the information/experience to come to a consensus on the parameters needed.

I find myself unable to vote in the poll because it's not asking the right questions.

I'm astonished that the whole debate is framed in block size terms when what everyone wants is transaction rate increases. Even core now has to state rate increases in terms of 'effective' block size increases. That's just stupid, but the politics are forcing it. I'm scared when politics starts making technical decisions and you should be too.

You say 'nothing is being considered'. What do you mean? See the roadmap below to see how wrong that statement is.
The truth is that the debate comes down to a choice between a rushed hard fork now, or a segwit non-hardfork approach which can yield transaction rate improvements safely, sooner than a safe hard fork, and almost as quickly as the rushed hard fork. Segwit has many other benefits (even classic agrees with that statement); for example an end to transaction malleabilty.

https://bitcoincore.org/en/2015/12/23/c ... eases-faq/
The first question there shows approximate expected dates for capacity increases on the core roadmap.
.

[BitcoinXio]

I'm a big fan of a flexible cap.

Same here as well. It's a real shame there have been so many great solutions that have been presented to the community but yet nothing is being considered. I'm overall just in astonishment, which I think many feel the same way (and why others are working on Classic, Unlimited, etc). I'm hopeful still that we can get past and move forward and on to bigger and greater things. There are so many genius minds in bitcoin, and I hate to see so much time and talent wasted on this.

I'd be in agreement with a dynamic cap, but it gets complicated to make it ungameable, and we probably don't yet have the information/experience to come to a consensus on the parameters needed.

I find myself unable to vote in the poll because it's not asking the right questions.

I'm astonished that the whole debate is framed in block size terms when what everyone wants is transaction rate increases. Even core now has to state rate increases in terms of 'effective' block size increases. That's just stupid, but the politics are forcing it. I'm scared when politics starts making technical decisions and you should be too.

You say 'nothing is being considered'. What do you mean? See the roadmap below to see how wrong that statement is.
The truth is that the debate comes down to a choice between a rushed hard fork now, or a segwit non-hardfork approach which can yield transaction rate improvements safely, sooner than a safe hard fork, and almost as quickly as the rushed hard fork. Segwit has many other benefits (even classic agrees with that statement); for example an end to transaction malleabilty.

https://bitcoincore.org/en/2015/12/23/c ... eases-faq/
The first question there shows approximate expected dates for capacity increases on the core roadmap.
.

I'm a fan of SW, but what's the realistic throughput that we get out of it to increase transactions rates? From my understanding it's going to be somewhere in the vicinity of a 1.75MB block size capacity (we are at 1MB now). This is not scalable long term. I am thinking longer term than just the next 6-9 months. What happens then? What's the plan? SW isn't a scaling solution, it's an optimization which gets us somewhere short term but doesn't scale over time. We need a solution that incorporates a capacity that allows for growth over time plus SW on top of that for maximum optimization.

[Acidyo]

Although 2 MB should be enough for a while, I would prefer the flexible one instead so people don't have to go through this drama again later.

Any cons out of having the flexible cap?

[LiteCoinGuy]

Same here as well. It's a real shame there have been so many great solutions that have been presented to the community but yet nothing is being considered. I'm overall just in astonishment, which I think many feel the same way (and why others are working on Classic, Unlimited, etc). I'm hopeful still that we can get past and move forward and on to bigger and greater things. There are so many genius minds in bitcoin, and I hate to see so much time and talent wasted on this.

I'd be in agreement with a dynamic cap, but it gets complicated to make it ungameable, and we probably don't yet have the information/experience to come to a consensus on the parameters needed.

I find myself unable to vote in the poll because it's not asking the right questions.

I'm astonished that the whole debate is framed in block size terms when what everyone wants is transaction rate increases. Even core now has to state rate increases in terms of 'effective' block size increases. That's just stupid, but the politics are forcing it. I'm scared when politics starts making technical decisions and you should be too.

You say 'nothing is being considered'. What do you mean? See the roadmap below to see how wrong that statement is.
The truth is that the debate comes down to a choice between a rushed hard fork now, or a segwit non-hardfork approach which can yield transaction rate improvements safely, sooner than a safe hard fork, and almost as quickly as the rushed hard fork. Segwit has many other benefits (even classic agrees with that statement); for example an end to transaction malleabilty.

https://bitcoincore.org/en/2015/12/23/c ... eases-faq/
The first question there shows approximate expected dates for capacity increases on the core roadmap.
.

I'm a fan of SW, but what's the realistic throughput that we get out of it to increase transactions rates? From my understanding it's going to be somewhere in the vicinity of a 1.75MB block size capacity (we are at 1MB now). This is not scalable long term. I am thinking longer term than just the next 6-9 months. What happens then? What's the plan? SW isn't a scaling solution, it's an optimization which gets us somewhere short term but doesn't scale over time. We need a solution that incorporates a capacity that allows for growth over time plus SW on top of that for maximum optimization.

the plan is, that we are still working on the baselayer and have to build on top of that to scale. much like the internet did. but SW gives some nice goodies:

https://www.youtube.com/watch?v=kSq-58ElBzk&feature=youtu.be

for scaling there is LN and more that will follow.

also read:
https://de.reddit.com/r/Bitcoin/comment ... cket_with/

in the longterm, there still has to be a bigger blocksize i guess but core does not talk about that.

although i would prefer 2MB blocks and then everything else iam okay with cores roadmap. what would be the alternative? 1-2 unknown coders of classic with no plan for development and consensus finding?

[BitcoinXio]

I'd be in agreement with a dynamic cap, but it gets complicated to make it ungameable, and we probably don't yet have the information/experience to come to a consensus on the parameters needed.

I find myself unable to vote in the poll because it's not asking the right questions.

I'm astonished that the whole debate is framed in block size terms when what everyone wants is transaction rate increases. Even core now has to state rate increases in terms of 'effective' block size increases. That's just stupid, but the politics are forcing it. I'm scared when politics starts making technical decisions and you should be too.

You say 'nothing is being considered'. What do you mean? See the roadmap below to see how wrong that statement is.
The truth is that the debate comes down to a choice between a rushed hard fork now, or a segwit non-hardfork approach which can yield transaction rate improvements safely, sooner than a safe hard fork, and almost as quickly as the rushed hard fork. Segwit has many other benefits (even classic agrees with that statement); for example an end to transaction malleabilty.

https://bitcoincore.org/en/2015/12/23/c ... eases-faq/
The first question there shows approximate expected dates for capacity increases on the core roadmap.
.

I'm a fan of SW, but what's the realistic throughput that we get out of it to increase transactions rates? From my understanding it's going to be somewhere in the vicinity of a 1.75MB block size capacity (we are at 1MB now). This is not scalable long term. I am thinking longer term than just the next 6-9 months. What happens then? What's the plan? SW isn't a scaling solution, it's an optimization which gets us somewhere short term but doesn't scale over time. We need a solution that incorporates a capacity that allows for growth over time plus SW on top of that for maximum optimization.

the plan is, that we are still working on the baselayer and have to build on top of that to scale. much like the internet did. but SW gives some nice goodies:

https://www.youtube.com/watch?v=kSq-58ElBzk&feature=youtu.be

for scaling there is LN and more that will follow.

also read:
https://de.reddit.com/r/Bitcoin/comment ... cket_with/

in the longterm, there still has to be a bigger blocksize i guess but core does not talk about that.

although i would prefer 2MB blocks and then everything else iam okay with cores roadmap. what would be the alternative? 1-2 unknown coders of classic with no plan for development and consensus finding?

Well, that is part of the problem. Core does not talk about any block size increase in their road-map outside of SW which gives an optimum capacity of 1.75MB. So Core is developing for scaling off chain using sidechains and LN but what about the bitcoin blockchain? Are we left in the lark with a max cap of 1MB where we are in a fee war with others to get our tx's confirmed unless we move over to sidechains?

Core doesn't want to budge beyond 1MB and has made that very clear, essentially terminating growth of the bitcoin blockchain to further advance sidechains. I think sidechains and Lightning and great developments but Core shouldn't be stopping the bitcoin blockchain in order to make that happen.

[harrymmmm]

Same here as well. It's a real shame there have been so many great solutions that have been presented to the community but yet nothing is being considered. I'm overall just in astonishment, which I think many feel the same way (and why others are working on Classic, Unlimited, etc). I'm hopeful still that we can get past and move forward and on to bigger and greater things. There are so many genius minds in bitcoin, and I hate to see so much time and talent wasted on this.

I'd be in agreement with a dynamic cap, but it gets complicated to make it ungameable, and we probably don't yet have the information/experience to come to a consensus on the parameters needed.

I find myself unable to vote in the poll because it's not asking the right questions.

I'm astonished that the whole debate is framed in block size terms when what everyone wants is transaction rate increases. Even core now has to state rate increases in terms of 'effective' block size increases. That's just stupid, but the politics are forcing it. I'm scared when politics starts making technical decisions and you should be too.

You say 'nothing is being considered'. What do you mean? See the roadmap below to see how wrong that statement is.
The truth is that the debate comes down to a choice between a rushed hard fork now, or a segwit non-hardfork approach which can yield transaction rate improvements safely, sooner than a safe hard fork, and almost as quickly as the rushed hard fork. Segwit has many other benefits (even classic agrees with that statement); for example an end to transaction malleabilty.

https://bitcoincore.org/en/2015/12/23/c ... eases-faq/
The first question there shows approximate expected dates for capacity increases on the core roadmap.
.

I'm a fan of SW, but what's the realistic throughput that we get out of it to increase transactions rates? From my understanding it's going to be somewhere in the vicinity of a 1.75MB block size capacity (we are at 1MB now). This is not scalable long term. I am thinking longer term than just the next 6-9 months. What happens then? What's the plan? SW isn't a scaling solution, it's an optimization which gets us somewhere short term but doesn't scale over time. We need a solution that incorporates a capacity that allows for growth over time plus SW on top of that for maximum optimization.

Let's be clear that a 2MB block size limit doesn't offer any long term scaling either.
At least segwit does offer options for the future, and IBLT and weak blocks that come next help a bit more. Not sure why it's not mentioned on the roadmap, but I know the core devs are pretty much all in favor of a hard fork at the end of that roadmap to clean up some stuff and maybe increase the block size cap.

I'm going with the core devs who have a long history of implementing scalability improvements already, compared to a couple of guys doing complex systems by 'democracy'.

[harrymmmm]

Although 2 MB should be enough for a while, I would prefer the flexible one instead so people don't have to go through this drama again later.

Any cons out of having the flexible cap?

Segwit offers almost the same as 2MB in almost the same time frame as the rushed hard fork, and certainly much sooner than a safe (consensual) hard fork. It also opens the door to other scalability options.

A dynamic cap makes long term sense, but it's not so easy to ensure it's not gameable. There are also some magic numbers required so far - it would be preferable to get those out and then leave it alone forever, free of political influence. Not sure if that's even possible tho.