@d01abcb3eb posted about this yesterday (#1264865) but it didn't get much attention, and it really should have.
You can read the full BIP here.
From the mailing list here's a brief outline:
- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem terrible. UTXOs are a huge cost to nodes, we should always keep them as small as possible. Anything else can be hashed (if SHA256 is broken, we need a hardfork anyway).
- Limit script data pushes to 256 bytes, with an exception for BIP16 redeem scripts.
- Make undefined witness/taproot versions invalid, including the annex and OP_SUCCESS*. To make any legitimate usage of them, we need a
softfork anyway (see below about expiring this).- Limit taproot control block to 257 bytes (128 scripts max), or at least way less than it currently is. 340e36 scripts is completely unrealistic.
- Make OP_IF invalid inside Tapscript. It should be unnecessary with taproot, and has only(?) seen abuse.
From the Activation section, which I should have included in the OP, but hadn't read it yet.
This sound like a proposal of any other shitcoin except bitcoin and it’s crazy for anyone to take this seriously or even propose it.
source
I don't understand this. Why
are they optimizing Bitcoin for the state's approval?
source
If you are proposing an emergency fork that you want to activate petty much immediately and that fork probably confiscates funds...you don't understand Bitcoin.If you are proposing an emergency fork that you want to activate petty much immediately and that fork probably confiscates funds...you don't understand Bitcoin.
Even worse: if your justification for such rash action is merely to make people do something in a slightly different manner to create a legal excuse:
source
I don't think you are even talking about Bitcoin anymore. Go use Visa.
They are really working themselves into a moral panic. The psychology of this is fascinating.
Real life coins that would be frozen by this fork:
source
mass psychosis
mailing list thread: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/FUbFjHYZAgAJ
we got PREDICTION MARKET UP, @Team_Predyx @mega_dreamer
https://beta.predyx.com/market/will-the-reduce-data-temporary-soft-fork-be-consensus-enforced-on-the-most-work-bitcoin-chain-tip-by-march-1st-2026-1762275376
If this is such an emergency, why weren't they concerned about such transactions being mined before? It was possible, and yet no one was running around screaming about it.
Unless I'm mistaken, a user could have configured datacarriersize to be 100kb in many prior versions of Core. Also there was Libre relay, which I think would have relayed such transactions. Why wasn't this an emergency last year or the year before?
I don't like being pressured into doing things because people falsely claim it's an emergency.
It’s probably because the only miners / pools creating their own templates and not having human staff doing content moderation would be much more likely to be using the core defaults, if not knots, so if they upgrade to v30 the door is open I.e. some miners will mine big op_returns without checking what’s in them. It’s not known but the assumption is that direct submission also evolved for this reason. The large pools would never blindly include images coming to them via libre relay. We need to consider such possibilities; I see them disregarded in most of the anti-filter argumentation.
Yeah I’m also confused of framing it as an emergency
Or maybe I’m not, because it’s straight out of the playbook of how to manipulate people
Very much seems like it.
What's also quite telling is how fresh many of the GitHub accounts are from most people interacting on that PR.
Thanks, @Scoresby! :)
I think a couple of things raises questions, in addition to the BIP giving the impression of being hastily written and not thought through. Like:
I also wonder about the implications of future developments. Like, say a node runs this BIP, and we get a new versions of tapleaf or segwit. What will happen to these nodes assuming they do not upgrade the node software they are running?
Disclosure: I am unfortunately not funded by any side of the spam "war", and so am just trying to understand what to do to avoid shooting myself in the foot.
I think you got this the wrong way around. You meant to ask: what happens to those people that activate this. We will call them shitcoiners.
Very good questions I unfortunately cannot answer.
Also thank you for originally sharing the link! Very sorry that it went under, not sure why. For me, this is easily the most important link in a long time about Knots vs Core.
Oh and welcome!
source
source
source
source
I wonder how this will affect potential double spends. One could publish some child porn at the same time of paying for a service and then activate this invalidation mechanism to recover the funds. How many descendants before a block is considered irreversible? Who decides what is considered not to Luke's liking? There will be edge cases that one does not think about now. There are always edge cases.
Putting aside my own position on this debate, this all seems poorly thought out.
Yeah, the potential double-spending issue is interesting. But so is the apparent clumsiness of the proposal - and the path that has lead here. Whatever game theoretic play the spam team is playing it's obviously working.
would you be willing to hazard a guess as to what the goal of a soft fork like this is?
Not really. From my vantage point there seems to be nothing positive in it for the "Knots-side". I think, to hazard a guess one would need to have some understanding of the target audiences here - for which I have none... To me it simply does not make much sense. Perhaps needless to say, I'm impressed by neither the new relaying defaults nor core's ability to make it harder to spam the blockchain.
Although I still do not want to hazard a guess, the question did cause more curiosity to arise. I came to think about the implications of having a system for local filtering what one stores and not having one. IANAL and I do not keep up with legal developments around the world - or at all really -, but the Compuserve case came to mind (think it was Compuserve?). Anyway, the point from that thing was that there seems to be different culpability scenarios depending on if there are attempts to filter, where not attempting to filter seems to be the better choice - on the local level. I'm mostly thinking about filtering what is permanently stored. Changing the rules for everyone to make it harder to publish junk is still a good idea.
From the discussion under the BIP proposal:
Wait, is this proposal going to solve Blockchain's oracle problem?
/s
@BitcoinErrorLog comes out swinging:
source
Preach, brother!
source
Does this SF affect LN ?
Depends on what chaintip your counterparty will force close you on.
Good question, I asked
Now github asks for login to read inside it?
great, thanks
.
In response to this post and your subsequently posted replies containing screenshotted reactions, anyone still calling Blockstream Coin "Bitcoin" at this point is an absolute fucking retard.