Topic: Blocksize - page 2. (Read 2182 times)
is my understanding correct...is the controversy over block larger size...going from 1mb to 2mb or 8mb or even higher... due to the fact that it would be more costly to run full nodes...being that 2mb is more costly to purchase than 1 mb?
2 Mb. Just because it's politically easier to implement. It'll buy us some time.
Time to implement something different, like lightning.
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold! I think it is the perfect solution, even better than lightning, since it's not hub-based.
Time to implement something different, like lightning.
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold! I think it is the perfect solution, even better than lightning, since it's not hub-based.
This sounds like a wise plan.
I think it should be dynamic, or even just for a week, we try our am the options, and miners vote on a specific option. That way we'll get the best option possible.
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold! I think it is the perfect solution, even better than lightning, since it's not hub-based.
That's a really good idea, I wonder why that hasn't been attracting more attention? That's the first time I've heard that idea, I kind of like it.
1 MB forever
2 Mb. Just because it's politically easier to implement. It'll buy us some time.
Time to implement something different, like lightning.
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold! I think it is the perfect solution, even better than lightning, since it's not hub-based.
Time to implement something different, like lightning.
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold! I think it is the perfect solution, even better than lightning, since it's not hub-based.
Voted 2mb. Maybe more down the line.
Yes, it's been awhile since we had one of these block size increase pools! 
I say 8MB and keep it there for a while until we don't see the consequences, etc! Even Chinese miners have said yes to 8MB and they were making the most problems about this increase!
I say 8MB and keep it there for a while until we don't see the consequences, etc! Even Chinese miners have said yes to 8MB and they were making the most problems about this increase!
What about BIP 103? What about "dont care as long as O(1) propagation + LN is done" and a multitude of other options?
I dont think you can put all possible options in a vote.
I dont think you can put all possible options in a vote.
Increase it! 2MB, 4MB whatever. But decentralisation must be retained! Big blocks and centralization will make us really vulnerable and therefore is strictly to avoid!
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.
this can be translated in the fact that what will be the best choice for us, will be the perfect choice that was needed
personally i'm with the dynamic block if it can be implemented well
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.
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.
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. 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.
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.
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.
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. 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.
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.
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).
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.
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.
Jump to: