Quote from: DooMAD on December 17, 2017, 11:38:16 AM

Quote from: Elliander on December 16, 2017, 05:57:51 PM

Quote from: DooMAD on December 15, 2017, 06:32:08 PM

Ever since BIP106 was first proposed, I've been a fan of the idea of dynamic scaling. Although shortly after that, I decided that the original concept was far too unrestrictive and had the capability to result in dangerously large size increases if it was abused. So over time, I've been looking at different tweaks and adjustments, partly to curtail any excessive increases, but also to incorporate SegWit, limit the potential for gaming the system and even prevent dramatic swings in fee pressure. So far, that's where I've got to. Still hoping some coders will take an interest and get it to the next level where it might actually be practical to implement.

My opinion is that an open cap is too unrestrictive, but a solid cap is too restrictive. That's why I think we need a way for the network to raise the cap on it's own within a set of limitations so that it can't bloat.

EDIT: I took a look at your thread, which looks similar to the first part of what I suggested here, but what's to stop the block size from increasing too fast for the network to handle? I think dynamic scaling needs to focus on both the needs of the network as well as the capability of the network with two distinct scaling solutions used together. The first adjusts the network according to the needs of the network, and the second adjust the network according to the capabilities of the network. Together, it allows flexibility, but there would have to be some incentive for the node operators to be willing to expand to handle the increased traffic.

And therein lies the rub, there's currently no way to forecast or determine the limits when it comes to the capability of the network, other than asking nodes directly to set their own individual preferred caps. Somehow I doubt many people on these boards would consider implementing ideas borrowed from Bitcoin Unlimited. Cheesy

Joking aside, combining algorithmic blockweight adjustments with the allowance of each node to set an upper limit to the size they'd be willing to accept would work if it weren't for the fact that it could easily force nodes off the network in a hardfork if they set their own personal limit lower than that of the majority of other participants, so even if people were willing to take ideas from BU, it still has some pretty serious shortcomings. If anyone can come up with a solution to that conundrum, I'm eager to hear it. Until then, it's a sticking point. Which is why all I could really do is make any increases as small as possible and allow the network to undo the increase if and when the demand isn't there anymore.

In essence, any attempt to place any hard upper limit inevitably results in hardforks at some point in future, unless you're an absolute genius and manage to find a workaround or hack to implement it as an opt-in soft fork.

To add to this, it would also be extremely vulnerable to bad actors, potentially with agendas favoring altcoins such as Bitcoin Cash which seek to become the "main" Bitcoin. For instance, a malicious user could start up thousands of nodes which would all attempt to bloat the block size as much as possible every block for Bitcoin's scaling to become unsustainable. This would mean, effectively, that there would be no limit to the growth of the block size because one malicious party decided to ruin the fun for everyone else. Danny suggested something similar to this, where the system has to take into account that users in the network can (and will, if permitted) take advantage of it and abuse it for their own benefit. We cannot depend on the network users to be benign.