Thursday, February 8, 2024

Discussion on implementing a more dynamic blocksize limit because ord/LTC20 congestion is still a very real threat.


full image - Repost: Discussion on implementing a more dynamic blocksize limit because ord/LTC20 congestion is still a very real threat. (from Reddit.com, Discussion on implementing a more dynamic blocksize limit because ord/LTC20 congestion is still a very real threat.)
I'm admittedly out of my depth and I'll need to convince many people to help on this, but I want to start by making the case that something like this needs to happen soon. This my first attempt, to be revised hopefully with your feedback. The Problem: Peak CongestionWe watched Bitcoin choke on ordinal congestion. At times, more than at others. I remember fees getting as high as $30, wouldn't be surprised if it was higher than that, they're back down considerably now. BTC decided to leave the burden of that peak congestion on users, higher fees, longer waits. This likely led to some users moving to LTC. We're watching DRC20s congest dogecoin right now. Second link from Dogecoin foundation on the topic. I wondered for a while if we'd dodged a bullet ourselves, we've seen lots of inscriptions, we haven't gotten the congestion, but that hope doesn't appear to be the case. Apparently Litecoin has been spared because so much of our ordinal marketplace infrastructure wasn't work or wasn't trusted. Go to this hyperlinked spaces and the litecoin portion starts at about an 1hr 33m, it goes on for about 10 minutes or so but ltc comes up again closer to the end as well. Long story short, we appear to have gotten lucky as some of the ordinal adjacent infrastructure crapped out before we could be flooded with far more activity than we've already gotten. When LTC20 infrastructure heats up, we could be faced with much higher peak usage than we can handle. I'm glad we have MWEB, but that won't help with exchange withdrawals, depositions or use of infrastructure like payment processors. This is where Litecoin excels. Adoption by users and infrastructure is our best quality. If they see congestion and high fees, there is no guarantee we won't lose that edge, possibly forever. The TradeoffsSomeone will bear the burden of peak use. If we change nothing, users bear the burden, and they might respond by shifting adoption to other chains. Considering our ability to add infrastructure is driven by our outsized userbase, this might hurt future infrastructure adoption as well. We don't have a loud investor base or big entities to speak for us like other chains. Only our users speak for us. If we increase blocksize, or even as I'm about to suggest, timeshift the limitations, nodes pay the price with higher storage costs. As much as many want everyone to run a node, afaik, there are less than 1000 nodes, which has been pretty consistent over time. I suspect most of these are either mining nodes or infrastructure provided. They can bear the costs better than small scale Litecoin users. And what are the costs? The current chain, even after a lot of incription driven bloat, according to blockchair is 143GB. A 256GB microsd card from samsung costs $25, from Silicon Power (I've never had a failure from this lesser brand) is $16. The cost per gb gets much lower if you go to larger spinning hdds. Bitcoin doesn't care about users. Loud bitcoiners have made this abundantly clear. They say you should never use your btc, hodl only. We're not going to compete with them as SoV chain. We are competitive with them and everyone in one area, medium of transaction. We need to prioritize our users and network effects because they're our only real differentiator, and it could cost our noderunners almost nothing to focus on users. We could burden potential inscribers instead by trying to banish them. Monero managed to do so. BTC seemed to give up on trying. But we're a permissionless, decentralized architecture. If we were going to find a way prioritize blockspace for sound money and financial transactions, that would be more complex and a much longer argument. Adjusting block limit policy could be done much more proactively, with less controversy or complication and more directly address the urgent issue at hand: peak demand. Proposed Conservative Tradeoff: Higher Block Limits During Peak UseI'm open to lots of solutions, but let me suggest the following conservative one first. Despite our high use, we do have partially empty blocks. Why should we have the same block limit during offpeak transaction times as during onpeak times? Even before exploring raising block limits on an absolute basis, I think there's a clear reason to timeshift the use of past unused block space to prevent congestion and high fees that might inhibit our continued adoption drive. Would it not be possible, without actually increasing the yearly block limit total, to have a rolling average block limit that allowed for peak congestion to be dealt with much more gracefully than we've seen from BTC and some other chains that have fallen prey to inscriptions mania? Instead of a hard limit, we could set an ideal limit. We could track the past usage over a rolling period and adjust the actual limit for future blocks up as block space goes unused. If we use above the ideal limit, the actual could start to fall for future blocks. This could be calculated on similar terms to readjusting hashrate difficulty, it needn't be done too constantly. In this way, we don't require nodes to store anymore than the previous potential total block usage, but we do allow for normal organic use, which comes in peaks and troughs, to more fairly access the total yearly block limit. Every Market Has to Accommodate Peak UsageImagine an electricity market that assumes the same usage throughout day and night. Some people live in such markets. It's not a great UX. But it's much easier to shift your use to a competing blockchain than it is to put a house on the market, find a buyer who has to go through the lending process, then move all your stuff into another house that you have to find in a better electric market. Yet despite having a somewhat captive market, even most utilities assume electric use will be higher during certain peak times, usually business hours in the afternoon, and they build capacity that's capable of ramping during that time. They might also raise rates during peak use periods to discourage use that can be timeshifted. We can do that too, but I'd hate to see our fee markets ever become what BTCs are, so I'd like to see a more orderly fee increase if necessary. It would be far better to acknowledge our transaction market will rise and fall in demand and allow capacity a little flexibility on a block by block basis. Let's keep our user base happy and let them keep growing. The Benefits of Prempting CrisisWe might find, as BTC has, that the flood isn't permanent. BTC median fees at a glance are back at around a couple bucks. We might not need something more drastic like a permanent block limit increase if accommodating peak use works. In the long run, a little foresight could prevent any real burden on any participant, even nodes might still have the current block limit protecting them. But wait, there's more! If we can head off this issue by increasing peak capacity before congestion hits us, before LTC20 trading frenzy takes off, or some other frenzy does, we might accomplish more than merely not losing users. We might gain some reputation among tastemakers and attention from developers. People might see Litecoin in a new... well, light. Where other chains clogged when the full weight of the inscribers befell them, we can do better. The market broadly might start to see us as a nimble, flexible chain that can handle the high burden of becoming the digital money layer of the internet. They might want to do more development around Litecoin. I love our devs, losh and david are awesome. I don't know Hector at all, but I love anyone who helps build out LTC, thanks hector! If I've missed any devs, my apologies, please let me know so I don't miss them in the future. But LTC has always had issues attracting developers. I've seen discussions about that difficultly going back many years. Our current devs could use some help. And there are investors who follow developers as a matter of course. Cathie Woods of Ark Invest often echoes this idea of following the developers and many more share her view, right or wrong. I personally prefer to follow the users, but my portfolio doesn't compare well to even investors much less prominent than Cathie, so it's worth considering what they value. Litecoin has the opportunity to prove itself to be nimble and ready to rumble, at the cost of a very small policy change that I hope could be accomplished with very little code. There are other larger policy changes that could definitely require less code (for example, just a straight up block limit increase). Feedback WelcomedI'm a nobody with no technical skills to offer and limited ability to even persuade anyone about this. But this is a decentralized space and perhaps even a dullard like myself can help by kicking off a conversation so we can start to coalesce around a solution. I suspect there are a lot of potential ways to address this, but I'd hate for us to have so much time to see the problem barreling towards us and still not choose the ounce of prevention and get stuck paying for a pound of cure that leaves us remembering our user adoption advantage fondly, wishing we hadn't let it slip away. LTC beating even BTC on so many use metrics makes me proud. We should keep winning. We have an opportunity here to make a stitch that in time saves nine. I particularly welcome comments from our developers and more technical users on the best technical solution that's the least controversial. But once a solution is coded, there's the much bigger issue of getting community consensus around it. Better, smarter, more connected users who can spread a message are needed.


Mining:
Bitcoin, Cryptotab browser - Pi Network cloud PHONE MINING
Fone, cloud PHONE MINING cod. dhvd1dkx - Mintme, PC PHONE MINING


Exchanges:
Coinbase.com - Stex.com - Probit.com


Donations:
Done crypto



Comments System

Disqus Shortname

Disqus Shortname

designcart
Powered by Blogger.