The rush is to make it usable in a high fee environment, not to enable eth use cases. The risk of not changing it is high if L2s break and L1s are too expensive to use.
Discussion
I understand the motivation. I’m upset with high fees too.
However:
+ There is a concept of “induced demand”. It’s like when they add new roads to decrease traffic. It never works for long because people end up moving to the area because of the lower traffic and traffic returns to the original level, or worse.
+ Once we realize high fees will be with us forever, we should realize that we don’t need to rush out a solution to “solve the problem”. We’re not going to actually solve the problem of high fees, except temporarily, and we risk making something worse. We need to be strategic and think long term.
+ In any event, we should NEVER change the protocol in powerful ways where we don’t know how it will be abused. We should limit the scope of new functionality as tightly as possible to reduce the attack surface.
We need to ask ourselves:
1) Can the issue be solved in any other way, other than a change to the core protocol? Have we waited long enough for other solutions to emerge?
2) If we must change the core protocol, what is the most limited change we can make that actually solves the problem?
You’re making it sound like we don’t change the core protocol. We already did this with segwit and taproot. Taproot enables safer ways to soft fork script versions. script was gimped from its original version, we can leave that broken or we can continue to fix broken things so that we can make onchain more efficient for L2 protocols.
I never understood why people are against efficiency gains and fixing broken things. If you are against that you should try to run older versions and see if you can even sync the chain.
Rusty is not proposing anything crazy, it’s simply restoring the original opcodes that satoshi added, in a safe way.
dont understand it still
or 'you never understood' but now you
do?
do you or dont you, will
cos if you still dont idk
doesnt bode well
gotta understand to actually disagree or ya dont know what you are disagreeing with
I’m all for making efficiency changes, fixing bugs, etc.
However, I don’t think we can claim that the missing op_codes are “broken” functionality or alternatively that those codes were blessed by Satoshi. We actually have no idea why Satoshi removed the codes.
If you recall Livera’s podcast, Rusty only considered the CPU and memory impacts of adding back the codes. He never once turned his mind to the potential for more MEV and miner centralization, or any other 2nd or 3rd order effects. I was shocked when he basically said that he didn’t care about how they might be abused.
If we’ve learned the lesson of inscriptions, we should realize that protocol changes can inadvertently change incentives and encourage centralization.
Bitcoin is our hope for the future. I believe that it’s highly resilient but not invulnerable. Mistakes introduced to the core protocol are one of the few ways that can disrupt it. We need to be careful.
How can anyone say these changes are “safe” if nobody knows how they will be used (or abused)?
I believe that we need to ask ourselves:
1) Can the issue be solved in any other way, other than a change to the core protocol? Have we waited long enough for other solutions to emerge?
2) If we must change the core protocol, what is the most limited change we can make that actually solves the problem?
Do you agree that these are the important questions? If so, I would be interested in your answers to them.
Devs should focus building software specifically for high fee environments