Dynamic Scaling?

[btcton]

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.  

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.

[1714796023]

1714796023

[Carlton Banks]

That means, yes, one transaction is needed to open a channel and another is needed to close the channel, but on-chain. That doesn't mean there's a limit to how long the channel can remain open though, so in cases of people who leave it open indefinitely that ends up being even worse for everyone else who uses on chain transactions compared to those who occasionally close the channel.

Why talk about opening and closing "for the day" then? That implies you thought there was a time limit for channels to remain open

Additionally, I never said that people couldn't pay directly. I said that people who weren't sending a large number of transactions wouldn't benefit from use of the lightning network themselves. (although I did make it clear that in the short term it has a benefit by easing congestion)

You had a whole screed of text complaining about how Lightning impedes users from paying each other directly. It does the opposite.

Are you complaining about the Bitcoin network's ability to handle transaction capacity or not? If you are, a solution allowing "sending a large number of transactions" is going to work. Why you think that only works in the short term is baffling.

In summary, you have no clue what you're talking about, despite giving the impression that you do. I'm not going to apologise for stating facts.

I'd like to add that I don't believe that Lightning Network is the best solution to scalability. While it can certainly address the currently high fees, I have some long-term concerns about relying on it. The thing is, the Bitcoin network was designed such that less coins are minted over time so that the miners can gradually transition to being paid in fees. Eventually the only financial incentive miners will have is transaction fees, which means more transactions would lead to better mining incentives.

Using the lightning network to open channels through which several transactions can flow without fees circumvents that and can actually lead to higher average fees for everyone else. At present, it would work great because that would remove from the Bitcoin network large amount of transactions that would otherwise congest the network and improves usability for smaller transactions, but that doesn't side step the need to address network scalability issues. If anything, it seems like the lightning network would be better used as a tool for decentralized exchange between cryptocurrencies, but shouldn't replace the ability of any particular coin to act as an exchange of value.

If node operators were rewarded by the network the way miners currently are according to their bandwidth they would have a financial incentive to scale up their capabilities leading to the network as a whole scaling up if dynamic scaling was implemented. That would ensure that transactions everywhere confirm cheaply, and the lightning network can still be of use for quicker in person transactions at stores where you don't want to wait more than a few moments for the transaction to confirm.

If we go the route of relying on secondary networks to exchange value, how exactly are the miners going to be paid when there are no coins to mint and no on block transactions to confirm?

Future reduction in block rewards shouldn't be a problem.

The mining market adjusts to the value of the block reward (and always has). Miners must sell some coins to pay their costs.

So

• new BTC supply always enters the market
• new supply needs an onchain transaction to use LN
• demand for on chain transactions will exist regardless of how prevalent Lightning transactions are

If you want to talk about the year 2140 (i.e. when the mining subsidy ceases altogether), perhaps the issue isn't quite the most urgent engineering challenge right now.


In short, your objections to Lighting are both moot and over 100 years too early.

[DooMAD]

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.  

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

Well, there would still be the algorithmic limit of not increasing more than 0.01MB every difficulty period (and even then, only if there were adequate fees to ensure it wasn't just spam), plus the chance the blockweight could reduce again if there were a less busy period, so it's not like the inclusion of individual node caps would make it easier to increase the blockweight.  But yes, it still wouldn't be ideal in that it's just not a particularly robust precaution. 

That said, if it weren't for the issue where it would likely cause hardforks, I'd still throw it in there anyway as an additional obstacle an attacker would need to overcome.  I'd throw in any and all additional layers of protection that make it require more effort to game the system and wouldn't result in more future hardforks.  The problem is just trying to think of practical things that would work.  But since individual node caps won't work, we need to come up with something better.

It's a weird quandary in that trying to limit an increase always sounds like a softfork in theory, but when you actually try to implement it, it tends to result in hardforks in practice.