pull down to refresh

I saw some buzz about this on X and even skimmed the repo, but have not had the time to go in deep.
The author's Github account was created a day prior to its posting on the mailinglist. The BIP was assigned BIP-Number 444 by Dashjr shortly after publication. The BIP has since been marked as "too heated" and consequently locked by Core developers, limiting the discussion to contributors.
The softfork proposal aims to invalidate scriptPubKeys exceeding 34 bytes and OP_Return to 83 bytes, invalidate certain OP_PUSHDATA with payloads larger than 256 bytes, invalidate certain undefined witness (or Tapleaf) versions and witness stacks with a Taproot annex, invalidate taproot control blocks larger than 257 bytes, invalidate tapscripts including OP_SUCCESS opcodes anywhere, and invalidate tapscripts executing the OP_IF or OP_NOTIF instruction.
442 sats \ 0 replies \ @BeeRye 11h
this is an utterly bat shit proposal, regardless of perceived merit or moral high ground.
reply
Genuinely can't understand why anyone is even entertaining Luke and his proposals. I suppose the fudsters, news outlets, influencers and anti-Bitcoin crowd need to play off something? I don't know.
Soft fork? No thanks. I'll hard pass on this.
reply
80 sats \ 1 reply \ @d01abcb3eb 9h
sigh Why does everything just spiral out these days? What concrete problem does this actually solve?
reply
0 sats \ 0 replies \ @BeeRye 6h
the introduction of ChristCoin
reply
Although I dislike the choices of Core v30 and have been running Knots for a while, I feel like things are getting out of control. Pushing a soft fork without consensus and due diligence would be extremely risky, as the consequences would be unpredictable. Now this goes beyond technical reasons, and the legal arguments are confusing and nuanced. The lack of honest dialogue between developers is also appalling, and the debate is becoming increasingly heated.
reply