Blocksize

[spazzdla]

It's been awhile since blocksize has been talked about.. curious to everyones opinion.

[1713561105]

1713561105

[1713561105]

1713561105

[eddie13]

I'm not 100% convinced that it is necessary.. I just hope they don't go and screw it up..

[spazzdla]

I'm not 100% convinced that it is necessary.. I just hope they don't go and screw it up..

Then vote stay the same.

I think a move to 8MB and hold is a safe move.

[mexxer-2]

Eh I'm fine with whatever bitcoin currently is. And I think most opinions about blocksize are still unchanged, you might wanna check the old threads.

[emelac]

I choose 8MB because I think that's what the Chinese miners favor. Without their agreement it's pointless changing the block size, and they don't want anything bigger than 8MB as far as I know. The block size argument is damaging bitcoin's image, and I hope it gets resolved before next year.

[Carlton Banks]

I'm not 100% convinced that it is necessary.. I just hope they don't go and screw it up..

Then vote stay the same.

I think a move to 8MB and hold is a safe move.

Lol what's wrong with 4. I'm not sure that the 4MB option is getting a fair hearing  


(tip: split "miners decide/dynamic" into separate categories, both have separate BIPs that could arguably represent each voting option)

[oblivi]

2 MB so we have extra time to work on the Lightning Network. 8 maybe is a good idea too, but it may be too much of a hardcore step of a sudden that may bring some problems. If there is an huge adoption all of a sudden, its not like 8 would be enough anyway, we need LN.

[spazzdla]

I'm not 100% convinced that it is necessary.. I just hope they don't go and screw it up..

Then vote stay the same.

I think a move to 8MB and hold is a safe move.

Lol what's wrong with 4. I'm not sure that the 4MB option is getting a fair hearing  


(tip: split "miners decide/dynamic" into separate categories, both have separate BIPs that could arguably represent each voting option)

Didn't know 4mB was a thing.. lol.

I am lazy and didn't want to change the poll opitions lol.

[spazzdla]

Hum.. lots of different opinions... complicates things greatly this does.

[eddie13]

I'm not 100% convinced that it is necessary.. I just hope they don't go and screw it up..

Then vote stay the same.

I think a move to 8MB and hold is a safe move.

Sorry for being such an ignorant noob but how exactly do you place your vote? There is nothing to click.. ??

[Carlton Banks]

2 MB so we have extra time to work on the Lightning Network. 8 maybe is a good idea too, but it may be too much of a hardcore step of a sudden that may bring some problems. If there is an huge adoption all of a sudden, its not like 8 would be enough anyway, we need LN.

/thread

(not saying I support 2MB, but even the over-baked BIP101 schedule isn't enough for worldwide levels of adoption, at least according to it's author)

[Lauda]

Modest increase or a dynamic block size (BIP100 isn't the only proposal that has this feature). As long as we don't try predicting the future, we should be fine. Also "miners choose/dynamic" doesn't have to necessarily be true. The block size can be dynamic without the miners choosing anything.

[oblivi]

I don't know how the dynamic blocksize BIP works, it sounds too good to be true. If it was that easy, we would have selected that method a long time ago, but im sure there are some underlying problems with it.

[Lauda]

I don't know how the dynamic blocksize BIP works, it sounds too good to be true. If it was that easy, we would have selected that method a long time ago, but im sure there are some underlying problems with it.

Every single proposal that has been made has issues and every single proposal that is going to be made in the future will have it's own issues as well. Nothing is perfect, and we can't just rush into unexplored territory. A dynamic block size system like the one in the BIP100 could possibly be cheated for an example (this is just one of the problems that has to be dealt with before one could even consider its implementation in the main chain).

[spazzdla]

I don't know how the dynamic blocksize BIP works, it sounds too good to be true. If it was that easy, we would have selected that method a long time ago, but im sure there are some underlying problems with it.

Every single proposal that has been made has issues and every single proposal that is going to be made in the future will have it's own issues as well. Nothing is perfect, and we can't just rush into unexplored territory. A dynamic block size system like the one in the BIP100 could possibly be cheated for an example (this is just one of the problems that has to be dealt with before one could even consider its implementation in the main chain).

This is my issue with dynamic... The ability to move the fee around to advantage certian parties...

That is why I am in agreement with 8MB.  I don't see it bloating the blockchain too much and the Chinese farms have agreed to 8MB. 2MB just seems so small.

[Lauda]

This is my issue with dynamic... The ability to move the fee around to advantage certian parties...

That is why I am in agreement with 8MB.  I don't see it bloating the blockchain too much and the Chinese farms have agreed to 8MB. 2MB just seems so small.

Exactly how do you think that could happen if the dynamic system is based on the size of the previous block (for example)? That's not directly possible. As I've already said dynamic != miners voting. Miners voting is just one option of a dynamic block size.

[Carlton Banks]

Every single proposal that has been made has issues and every single proposal that is going to be made in the future will have it's own issues as well. Nothing is perfect, and we can't just rush into unexplored territory.

Exactly.

The choice is not to pick the "perfect" solution, it is to pick the best compromise. In practice, that means picking the most tolerable imperfection, as perfection is not an available option. Or, at least not so far.

[spazzdla]

This is my issue with dynamic... The ability to move the fee around to advantage certian parties...

That is why I am in agreement with 8MB.  I don't see it bloating the blockchain too much and the Chinese farms have agreed to 8MB. 2MB just seems so small.

Exactly how do you think that could happen if the dynamic system is based on the size of the previous block (for example)? That's not directly possible. As I've already said dynamic != miners voting. Miners voting is just one option of a dynamic block size.

Miners with the ability to upload 100mb/s might pump the blocks to their limit until the block size is so large the miners with crappy interwebz can't win a block due to their inability to propegate it.

Although a range of 1MB to 32MB would prevent this or even 8MB top.

[unamis76]

I still have pretty much the same opinion: the best way to please everyone is a dynamic blocksize. Not sure what it should depend on, but it's a more flexible solution that may come across almost every user out there.

[spazzdla]

I still have pretty much the same opinion: the best way to please everyone is a dynamic blocksize. Not sure what it should depend on, but it's a more flexible solution that may come across almost every user out there.

My main concern is security of the blockchain.  No matter what security is #1, IMO we should always be growing in hashing power.