At some point, a soft fork has to be implemented, I'm not sure if that fact is even being debated at this point, but what year would you consider it to be 100% critical to do it by, and if you don't think we need one, why not?
Also, is there a general consensus on SN about OP_CAT vs OP_CTV vs OP_CSFS
As far as I know OP_CAT is the only one that would solve the L2 scaling issue, the security budget cliff, and the quantum threat, but I'm getting a little too deep in the weeds to figure this out completely without talking to somone with more of a technical background.
I'd challenge that. The only reason to have to do a softfork is vulns. Instead, follow the money and you'll see why
OP_CATgot so much attention when it did. When it failed to get momentum, you'll see that the same money source shifted to something different.You see, the real issue that either
OP_CAT, orOP_CTVsolves is that someone's bridge that does work on Ethereum does not work very well on Bitcoin without a softfork for some enhanced script primitives. I'm quite sure they would love aOP_CHECKZEROKNOWLEDGEPROOFVERIFYtoo. And that will solve the problems you list too, according to them.I've extracted the following "problems" from your post:
Do you have for each of these:
OP_CATBecause without that, it is impossible to even start validating if what you claim is true. So what problem definitions, and which explanation that
OP_CATsolves all this, inspired you to post this?L2 scaling issue, only perhaps 10% of the global population can be onboarded onto L2s right now. There's not enough theough put on L1 to handle L2 channels at scale.
The security budget cliff. You can do the math, if you look at the halving schedule and the amount of transactions per second that L1 can handle, there's a maximum amount of capital you'll be able to extract from transactions, and it is much less than there is today to pay the miners and secure the network. The only way to have enough transaction fees in the future is to have covenants or something similar. That way you can have massive LN channels that carry the economic weight of thousands of transactions. That would make high L1 fees meaningless.
The quantum threat, should be obvious to anyone who has been paying attention.
Everything I've said is verifiable, there's no legitimate challenge that a soft fork is going to be eventually needed IMO.
I'm sorry, was it rude of me to challenge a premise? I'm sorry I wrote anything...
Let me go through it regardless, because you were complaining you're not getting answers:
1. L2 Scaling1. L2 Scaling
First off, I think what you mean is L1 scaling, not L2 scaling, per your explanation:
How does
OP_CATfix this? Is it needed for Channel Factories (multi-party LN channels)? From what I understand, there are protocols proposed that don't need any covenant, but noting that if you were for example to use Ark (the protocol) withCTVyou'd be able to in theory get a more efficient factory.Maybe, but I don't remember seeing a single definitive work on this (do you have it?),
CAT + Schnorr trickscan help with this? But then, is that a real long-term solution and does it actually get resistant to Shor's (your third topic, PQ)? I'm not convinced of either.Another question to ask yourself is: if
utreexobecomes widely used, is there a reason to keep the L1 throughput low? In fact, I don't see how 10% of the world can non-custodially interact with Bitcoin without utreexo: L1 sync (of your txs and their recent ancestry) is always a must-have. You cannot operate without it. What you can do without is the archive of every L1 tx ever made.2. Security budget cliff2. Security budget cliff
Fee pressure rises as people get priced out of L1. Isn't it therefore logical that for this you don't want to solve the previous item too well? If the capacity equals the world population, then everyone will get their tx in at base fee, and fee would only rise when there are events where either everyone wants to close their channel at once, or there is some new kind of spam and then we get another 5 years of Luke & co drama. Hardly a good income source for miners.
As you note:
The problem is demand, of value, so my question about this topic is different: which demand of value will
OP_CATunlock? I mean it like: if it gets activated, who will now start making transactions that didn't before and the best test for it is: what will you do with Bitcoin that you aren't doing now? If you hadOP_CATtoday, what would you be using Bitcoin for?But why
OP_CAT? Why notArk+CTV? What makes you so sure thatOP_CATfixes this?The quantum threatThe quantum threat
It's not obvious. What is obvious is that Shor's algo is a potential threat to anything depending on the Discrete Logarithm Problem not being broken. This has been obvious since 1992. So I agree, it would be prudent to find a solution that doesn't depend on DLP.
You are 100% correct that
OP_CATdoesn't depend on the DLP. It is literally an instruction to do byte concatenation:0x13 0x37 OP_CAT => 0x1337. It also doesn't solve "the quantum threat", but it could enable some rather complicated scripts that do 32-bit arithmetic. These scripts will always introduce byte overhead, which goes immediately against your issue #1 and #2, because overhead means lower tx throughput, and it means the same value of sats is extracted more fees from, making transacting less economical.Yes, I do understand the zk-rollup idea. But then how much is going to the sequencers and how much is really coming back as L1 fees? Are the ZK sequencers going to pay 2 coins fee for every mainnet tx they make even if they can get away with maybe 10-50k sats and still be sitting on top of the mempool under current fee pressure levels? What does that mean for the fees paid on their rollup? If you overprice, you will lose demand?
I appreciate your detailed breakdown and challenging the premise, it's exactly why I posted it in the first place.
You definitely make a fair point about CTV vs CAT, and i definitely haven't made a firm opinion on either yet. My main argument for CAT is that it's more general purpose. I'm open to the idea that maybe that's a bad thing though.
I also 100% agree that you don't want to solve the fee problem too well. If you have infinite block space, there is no fee market, and no amount of throughput will fix that. I got into a disagreement with a shitcoiner that thinks their protocol "fixes bitcoin" by having nearly infinite block space, and to me, that just sounds like a ticking time bomb.
I also agree that using CAT for quantum resistant scripts introduces massive byte overhead, I'm currently not sure of any solution to quantum that wouldn't do that though.
Sorry if I sounded standoffish in my original reply, tjst wasn't my intention, I actually really appreciate your effort.
@k00b thanks for giving your opinion on SN live. I was bummed that I didn't see you in here and wanted your opinion.
My bad. I spend most of my time on SN doing customer service. I need an alt so I can let it rip.
Hmm I meant to respond to the main body of the post, not randomly in the middle of the thread, either way, im sure optimism doesn't mind being tagged in.
I honestly do like hearing the opinion that a soft fork isn't even necessary from somone I consider to be extremely knowledgeable on the subject. I'll keep diving into different solutions, but are there any BIPs that you currently like, or do you just think these issues are overstated/solvable with the current state of things.
I definitely like your stance that a fork will happen if it NEEDs to happen, and that that preempting possible issues isn't completely necessary.
Is fine, plus you got zaps on comments that otherwise would have been unlikely for me to have seen.
No worries.
I was and still am interested where you got the impression that
OP_CATfixes everything, and I still don't know, haha. Yes, it's a powerful primitive to have, also if you look at the greater set that is being proposed for restoration inBIP-441, but it has a lot of tradeoffs if you're actually going to use it to permanently solve problems and I don't think that it will concurrently solve all 3 of the problems you mentioned; maybe it could help solving each individually, in a quirky and expensive way, at the cost of the other 2.That's what bothers me about most of the discourse that say "it's either
xoryand it has to happen"; it's a lot of repetition of narratives that magically lost all sense of tradeoffs and caveats. But despite all the remarkable conspiracy theories, I'm rather confident that if there was a solution to all 3 your criteria without any tradeoffs at all, it would have been PR'd and merged by now.I'll ask my last question: if you had to choose between your 3 problems and you could only solve one, which one would you pick, and why?
So this is just my understanding.
It allowes for Hashed based signatures which would mitigate the quantum threat. It would introduce covenants, which solve the scalability issue, and my theory is that by solving the scaling issue, the security budget gets solved at the same time with adoption.
I know there's a large data weight involved, but it's my thought that CAT will allow that extra weight to be absorbed.
I'm definitely not calling CAT a silver bullet, and I understand that there's other friction involved, but, that's the fun of having these conversations.
As far as which of the three, if I had to pick one, it would be the quantum threat. You could reduce the hashrate of the entire network by 50% and still have practically zero threat of a 51% attack. I think there's a fairly large runway, and I also think it's actually possible that some level of homeostasis occurs and the network just finds a natural balance that maintains a high level of security.
Right, so your assertions are:
OP_CATwhile at the same time using it with Schnorr-tricks to get covenants. I don't think this would be very efficient, but it may be possible to hack a thing here and there.OP_CATwill turn 4MB into 400MB? Must be my fever making me dumb haha.Ahh, I think maybe we crossed some wires. I don't necessarily think covenants will create demand. I think we will need them to meet the eventual demand. As it stands right now, I don't know that we would need to soft fork this exact instant.
As far as absorbing the extra weight, a ZK roll up can take 100,000 data heavy transactions and process them off chain. It then uses a much smaller mathematical proof of that batch on L1. So it takes 400mb of transactional data, and compresses the settlement proof into a few kilobytes. So, to your first point, that's why unlocking layer 2 roll ups is important. We wouldn't need to do all of the work on layer one, so the efficiency isn't as big of a deal.
As far as pricing out 99 of 100 bitcoiners goes, you and I wouldn't be paying the massive fees. The roll up sequencer pays the fee, and because it's batching 100,000 individual transactions our cost on the l2 is .005c and the miners still get the big pay out.
And it limits who can afford to run a node
Have you looked at mandacaru (#1466811)?
No, but I looked at utreexo.
My understanding is that with utreexo, instead of storing the utxo set in GBs (~/.bitcoin/chainstate), you can store it in a few MB with a merkle tree. You verify transactions with inclusion proofs for the outputs they spend. If you want to be a node to help other nodes sync, you would still need to store the blocks (~/.bitcoin/blocks).
Is that wrong?
One angle that does not get enough attention: the legal and regulatory risk of not forking.
If quantum computing reaches the point where it can crack ECDSA (even in a limited, expensive way), every bitcoin sitting in a p2pkh address with an exposed public key becomes legally ambiguous property. Courts will have to decide whether coins moved by a quantum attacker constitute theft or something more like an exploit of a known protocol weakness that the network chose not to fix. That distinction matters for insurance, for custody agreements, and for the fiduciary duties of anyone holding bitcoin on behalf of others.
The longer the network waits to implement quantum resistance, the stronger the argument that the vulnerability was accepted rather than unaddressed. That shifts legal risk onto custodians and institutional holders in ways they may not be pricing in yet.
On the OP_CAT question specifically: covenants will attract regulatory attention because they enable more complex on-chain conditions, which regulators will read as programmable compliance (good) or programmable evasion (bad) depending on the application. But that regulatory interest is coming regardless of what Bitcoin does. Better to have the tools and face the scrutiny than to lack the tools and face the same scrutiny anyway.
So, you would say that you're in support of OP_CAT? I know there's been some talk that it would open up some ability to hack or exploit L2, but I don't know how credible that risk is.
Cautiously. The exploitation scenarios I've seen discussed mostly assume conditions that make them impractical. The cost of standing still seems higher to me than the cost of careful progress.
why force people to have an opinion?
in most softfork scenarios, if you're not a miner nor an economically active node, you can abstain from expressing an opinion, keep your coins on both sides if there actually is a chain split, and decide after an indefinite amount of time spent observing the outcome rather than buying into either side's propaganda.
You certainly dont have to have an opinion. I personally would like to have an informed one. To each their own.
sometimes, the only winning move is "Insufficient data for meaningful answer".
I don't disagree with that either. I'm not trying to push people into a camp. I am openly admitting that I don't understand a lot of this stuff and I'm looking for input from people who know more than me.
By the way, the more times I read this reply, the better I like it. You've brought up a lot of things i haven't considered.
Thanks, appreciate it. The fiduciary angle is the one I keep coming back to.
Per your other post, this post should be flamed.
There's no scaling issue in the throughput sense, nor solutions in the distribution sense.
Scaling talk is moron-scammer talk.
Same for quantum, it's not real.
some people don't understand that Bitcoin's long-term survival does not require all individual people to have active wallets.
even if you think for some ideological reason that all people should use Bitcoin for their long-term savings, most people could get by with far less than one transaction per week, if all they're doing is topping up a "rainy day fund".
I also believe that requiring everyone to actually use Bitcoin themselves, independently, is delusional. Humans are social animals and delegation of responsibility is efficient. Having the right and freedom to use Bitcoin doesn't mean you also have an obligation to do so.
Hipsters virtue signal without thinking much, their entire identity is wrapped in larping with a hardware wallet because they have nothing else
is that really the problem here?
I think the problem is a much larger one, that is very common in economics and probably any scientific discipline, maybe even most human endeavors... people have difficulty imagining just how different an equally valid lifestyle could be.
Yea they're related, since hipsters identity is wrapped up in one aspect, anyone placing value in a different place along the surface is inherently invalid
Many such cases
you might be more familiar with individual personalities or stereotypes here on SN; however I've been "out of town" for a while, so I'm less eager to dismiss people's concerns, even if I agree with you that they are misguided in some way.
I'm just asking questions and voicing concerns in a corner of the internet that I respect, and consider the best place to find legitimate, well thought out answers.
I'm not sure where he's getting his ideas about me from, and he's welcome to have his own opinion about me, but I don't think anything I've said counts as an attack on bitcoin, or is overly alarmist.
I also know there are people here that actively develop for bitcoin, so I'm asking for expert opinions.
Simple as that.
You're asserting things as true that simply are not, that's not asking questions. You're presupposing.
Linked you to 3 different long posts that break it down, and referenced papers from peter gutmann... and all you got is "agree to disagree"
You're not looking for answers, you're looking to confirm your idiotic presuppositions.
All you're asking for is to be flamed by posting nonsense as fact: #1468593
Without a soft fork, roughly only 10% of the population can be on boarded to lightning. This isn't some imaginary made up number, it's a fact.
If you don't think quantum will ever be a threat, then I doubt there's anything I can say to convince you otherwise, so we will just have to agree to disagree.
The number of people that can be on boarded is a function of supply distribution
Your fact is retarded, made up by scammers.
So, unless you're talking about a supply increase, which is never going to happen, there is no solution
There's literally not enough Bitcoin, has nothing to do with throughput.
Read the Gutmann papers, quantum is another hoax by scammers, stop being so gullible.
To open a non custodial lightning channel, you must execute a layer 1 transaction. Layer 1 makes out at 7 tps, which is 220 million per year. If the entire population wanted to open just 1 channel and the network did literally nothing else, it would take over 36 years.
This isn't weird fud or doomerism, this is just math. I also don't think that bitcoin is under any threat whatsoever, there's already proposed solutions, and the whole point of this thread is to discuss which solutions are best, and when people think they should be implemented by.
As far as quantum computing being a hoax, shors algorithm is mathematically proven to break ECDSA. Whether you think it takes 10 years or 50 years to create the hardware ignores the proven mathematical vulnerability.
Your math is retarded for a number of reasons that have already been laid out time and again
You think only 10% of the world can onboard? Wrong, it's more like 2%... and that's more than enough.
--Thomas Sowell on Bitcoin Scaling and Fake L2's
#999080
#1278098
#1278098
Fortunately quantum computing is as much science fiction as a time machine, the odds of an AI going back in time to wrench attack your mother before you can buy coins are higher than a quantum computer cracking keys
How many quantum proof shitcoins do you own? Man you're gullible.
If your stance is that 2% of the world being onboarded is enough to sustain the network indefinitely, and that quantum is just a fairytale then we will just have to agree to disagree.
As far as what I own goes. I have a nearly 100% allocation to bitcoin in cold storage, and about $12,000 in fiat that I use to trade options as a hobby. I don't own any shitcoins.
Good talk.
Because you don't know what you're talking about. You're just panic posting because scammers got to you.
👍
There will likely be many.
The next one I think will be for moving into quantum resistant address types and how we deal with Satoshi era coins. Some of us will want to keep everything as it is while others might want something like an hour glass to mitigate it.
Bitcoin will remain volatile for decades.
I think developing quantum resistant addresses is the priority. As for the satoshi era coins, the best is to leave them as they are. Having abandoned utxos liberated is way lesser evil then freezing balances.
I did read about putting a time cap on spending coins "mined" by quantum computers like you mentioned. I think how those get delt with will be a very large point of contention in the community. I'm not even sure you can do much about them without a hard fork.
It's going to be interesting to see how it plays out.
I would like to see post quantum cryptography at least being discussed here. What post quantum crypto alogorythms can be theoretically implemented for starters. Which is a lomg long way from making an actual proposal.
Here are all the posts about quantum computing since April 1 (with a few unrelated quantum posts weeded out):
Hey thanks for posting this list. It reminded me I had to respond to a bot hallucination too, haha.
I belive post quantum cryptography already exists. Quantum doesn't just threaten bitcoin, it threatens every single financial institution on the planet, so there has already been a fair amount of effort thrown into it. So, it's not a matter of developing the cryptography at this point, it's a matter of implementing it.
As far as my understanding goes. There would need to be a soft fork, and then your bitcoin would need to be transferred to a new wallet prior. In order to protect any bitcoin that isn't moved, you would require a hard fork.
I may be mistaken, but that's my understanding. A soft fork seems way more likely at this point.
The problem with bitcoin is different from the problems with other systems for the following reasons:
So I would love people to take this seriously. I don't understand cryptography, but people who do need to think specifically in the unique context of bitcoin. I hope good post quantum addresses will be implemented in bitcoin.
(BTW even a small probability that quantum computers can break the cryptography in the near future warrants an action. Being prepared for a possible threat that does not materialize is OK. The danger is enough to take action. You don't really know for sure whether quantum computers will be ready in two years, 10 years or 100 years.)
I absolutely agree that this should be taken seriously. That's why I'm asking when people think a fork needs to be implemented by. I'd prefer if the community was proactive about some of these issues.
I am skeptical of phrases like “security budget cliff”. I am not saying there won’t be a problem (maybe a big problem), but the impending doom around Bitcoin’s security budget is typically peddled by shitcoiners who want to sell you their coin instead or by Bitcoiners who want to scare you into whatever proposal they prefer.
I don't consider it to be an immediate threat, but the math is there. Layer 1 doesn't handle enough transactions per second, and you can't onboard enough people onto L2 to pay miners for ever. If absolutely nothing is done, the security budget will decrease over time.
I'm not a doomer though, there's people who are way smarter than I am thst already have solutions. It's just a matter of getting consensus on which one to implement.
I think the security budget talk projects the current state of mining, fees, onchain activity into the future and I think that is somewhat of a fools errand. It's impossible to know what any of these things look like say a decade from now.
Not saying it is not worth considering but free markets and incentives tend to be great problem solvers.
As it currently stands, you can onboard approximately 10% of the global population onto layer 2's until the base layer can't keep up with channels opening and closing. You can pretty much map out a decent estimate of where it just becomes unsustainable. With the addition of covenants though, you can literally onboard the entire population, and do so quickly. A full layer one won't be an issue, because the massive fees from opening and closing channels won't matter. Each channel will hold the aggregated weight of thousands or millions of transactions.
So we can map out an approximate maximum level of activitiy or fees if nothing changes. None of which matter, because the solution already exists, and there's just about a zero percent chance that people allow the network to die instead of implementing a soft fork.
Unfortunately the demand for actual Bitcoin is quite low. Most people want (or at least accept) claims on Bitcoin. Claims on Bitcoin are infinitely scalable until too many get redeemed at once. Hopefully as it becomes more of a medium of exchange this will change. I think the demand, the infrastructure build and protocol changes to meet the demand all kind of develop in unison over time. I see that as more likely than some tipping point where suddenly 1B people need to be onboarded with a few months. I could be wrong though.
It has been odd to observe this ideological shift in Bitcoin as new folks have entered the space and been totally ok with or even preferred claims on Bitcoin.
I agree that the change will meet demand way before something even remotely catastrophic happens, although I assume people will wait until after the problem already begins. It won't be a matter of needing to onboard a million people in a week, but it may be that layer 1 needs to get a lot more expensive to transact on before a solution is implemented.
As far as claims go, I think people are just lazy. It's easier to buy an ETF and let your brokerage deal with it than to buy the coins and self custody. I have no doubt though, that things are going to get a whole lot more intuitive over time. It seems like a self correcting problem.
I do think it is a self correcting problem but it might be a multi decade self correcting problem.
I don't doubt that one bit. There's a lot of hurdles between now and then, including a de mininus tax rule.
The average person isn't going to use bitcoin as a means to avoid taxes and they don't want the headache of filing a million little transactions.
I'm very glad you are bringing this up!
I have a feeling that many people on SN don't feel like they understand the details and trade offs of the various covenants soft fork proposals well enough to have a strong opinion.
At least, this is how I would put it in my own case -- and this is despite the fact that I've done a fair bit of reading about them and paying attention to the conversation on the Mailing List and on delving.
I suspect the problem is that a lot of the trade-offs are pretty nitty gritty. It feels like what we want is some champion who will tell us what to do...but unfortunately, it's Bitcoin and we don't like champions.
Also, any champion who emerges, is usually flawed in some way and so we obviously cannot trust them. (we probably shouldn't be trusting anyone!)
But where does that leave people like us?
Either we are going to have to really put the time in and educate ourselves, or we are going to have to wait for "the devs" to present some semi-unified front.
I'm a fan of the former. I'll try to write a post about covenants this week.
That's what I'm trying to wrap my head around. I'm trying to get educated enough to form a solid opinion, that way I can make a case for whatever I think the best solution is.
The bottleneck is consensus, so I should be trying to convince people to reach one, and I can't do that unless I know what I'm talking about lol.
I agree. The covenants soft fork support wiki is a site I visit with some regularity:
https://en.bitcoin.it/wiki/Covenants_support
There is also this covenants page: https://covenants.info/
But I definitely have a similar feeling to what you are expressing here: I don't know how to make up my mind about it, but it feels like if I don't have a single strong opinion -- if a lot of us don't have single strong opinions -- nothing will happen.
There has been a bit of movement recently though: BIP 54 (Great Consensus Cleanup) while not a covenant proposal, is a soft fork that maybe has the most cohesive narrative around it. It has a signet (#1428059) and there have even been some BIP 54 compatible blocks mined on mainnet (#1442475).
BIP 440 and co aka The Great Script Restoration is another soft fork proposal that is starting to get some momentum -- at least it has BIPs that are published.
A number of the other proposals on the wiki I mentioned above have also published BIPs that are now included in the BIPs repo, including BIP 346 - OP_TXHASH, BIP 448 - Rebindable Transactions, BIP 446 - OP_TEMPLATEHASH, and BIP 442 - OP_PAIR COMMIT.
But maybe this proves the point: there are so many proposals out there, it is difficult for a non-expert to develop a strong opinion about which one should be advocated for.
I think this means the answer to the question in your post is: No. there is not consensus on SN about soft fork proposals.
I don't think any of those address the quantum threat, but if bitcoin needs ro take baby steps, it's fine. So long as those steps are actually taken in a timely manner. Looks like I have a lot of reading to do though.
I would certainly be interested in any learnings you have from your reading. I think others would too. I'll definitely zap.
I'm going to keep at it until I've made up my mind what solution I want to champion lol. So I'll make mu case eventually.
That's an interesting way to put the question.
I was wondering recently if bitcoin's culture of resisting change will mean we don't upgrade most of the network until we're into that riskier-avoiding-it side.
Just looking back at how taproot was implemented, it seems like the community is likely to be more reactive than proactive.
So far that hasn't been an issue, but if they were to wait until after the quantum threat already happened, it would be too late.
It sounds like there are things individuals can do to safeguard their stacks, prior to one of these forks, so I don't necessarily agree about there being a discrete "too late" moment.
I don't want to sound like an alarmist, so right off the bat, I agree. I don't think BTC is under any direct threat, and "too late" in that case would be part of the population loosing trust in BTC, not an end to the network itself.
I also think L2 scaling and the security budget will force the communities hand well before the quantum threat.
I hadn't thought about that.
It would be funny if quantum was addressed almost incidentally because it was included in something more pressing.
It depends on what gets implemented. As far as my understanding goes OP_CAT allows all three to be solved with a soft fork, but I honestly need to talk to someone with a way better grasp on it than I have.
2067
You may be a bit more optimistic than I am lol. I'm thinking 1 or 2 halvings max.
i think the question isn’t a calendar year, it’s the point where the cost of not upgrading starts compounding faster than the coordination cost of upgrading.
taproot showed the social part is the hard part. the technical part can be solid and still take years because consensus moves when the pain becomes hard to ignore.
NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
at ih (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:97196)
at ib (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98700)
at iw (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:101122)
at ib (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98826)
at iw (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:101122)
at ib (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98826)
at iw (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98948)
at ib (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98826)
at iw (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98948)
at ib (https://a.stacker.news/_next/static/chunks/framework-76894e138009602c.js:1:98826)
Component stack:
at button (<anonymous>) at div (<anonymous>) at k (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:387:534) at w (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:387:749) at div (<anonymous>) at https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:143:75358 at Q (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:3755:150827) at div (<anonymous>) at https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:143:74046 at https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:143:75981 at nav (<anonymous>) at https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:172:174273 at div (<anonymous>) at https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:398:101836 at div (<anonymous>) at eB (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:3755:159896) at l (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4252:399) at ej (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:3755:161135) at tI (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:3761:25663) at u (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:172:3301) at m (https://a.stacker.news/_next/static/chunks/pages/items/%5Bid%5D-e0629ef7d1a1cfb8.js:1:253) at h (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:164:67) at d (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:673:28809) at m (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:668:48240) at G (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:975:8980346) at N (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:1294:26618) at h (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4275:187394) at c (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4275:184534) at m (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4275:186939) at y (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:387:185) at F (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4255:31700) at g (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:435:20944) at u (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:4275:180681) at F (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:6:28993) at B (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:6:29054) at E (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:6:28724) at c (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:142:19692) at l (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:143:76554) at c (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:1:120119) at m (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:1:120368) at h (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:164:67) at P (https://a.stacker.news/_next/static/chunks/pages/_app-bd35b2fde5cf5f32.js:6:654) at _ (https://a.stacker.news/_next/static/chunks/main-1f20e6116d2e2bf0.js:1:16244) at q (https://a.stacker.news/_next/static/chunks/main-1f20e6116d2e2bf0.js:1:34771) at V (https://a.stacker.news/_next/static/chunks/main-1f20e6116d2e2bf0.js:1:36128) at ef (https://a.stacker.news/_next/static/chunks/main-1f20e6116d2e2bf0.js:1:38838)