@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.
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
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.
mailing list thread: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/FUbFjHYZAgAJ
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!
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.
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.
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.
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
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
source
source
source
source
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.
Yeah, clearly the "follow the law" freedom money fork proposal is what we should do.
The cult has lost its "community" moniker since 2017, doubling down on defending the worst possible decisions and individual "representatives."
I left the Shitereum community just to end up witnessing another form of it being birthed. No fucking thanks.
how do you feel about soft forks that may confiscate funds?
source
If this goes through, Blockstream Coin basically becomes Shitoshi's Venture with detrimentally small blocks rather than detrimentally "make them whatever size you want" blocks.
It's funny how the Cashers became vindicated in all their claims about their currency being the true Bitcoin, alongside everything else they've said for nearly a decade... all they need was lots of time for the corporate and governmental subversion to eat away at what little remained of its facade.
I don't think I understand what you are saying. There's nothing wrong with small blocks and Bitcoin is doing just fine. The only problem is people running around acting like we need an emergency soft fork.
My viewpoint comes down to seeing years of seeing ongoing efforts to sidestep the actual solution to lack of scalability (increasing the block size to 2017-19 BCH levels), and instead try to push Lightning (which Blockstream alongside other paid off and/or deluded developers pivoted towards after their forceful pushing of Liquid failed at the time) as the solution, when you'd be lucky to get even 5% of BSC users to adopt at a self-custodial level without getting wrecked at either a management or application level (bugs can fuck over even the most technically versed of users).
That's on top of disingenuous arguments claiming that raising the block size would kill decentralization (lol) of BSC despite Bitcoin having no size limits originally, and the piece of code that introduced such as a temporary fix for then-real issues around double spending and blockchain drift in 2010 (which is something I touch on in an article that'll be published When It's Ready™ to @lain)... and then raising it an entire megabyte via SegWit and Taproot later on.
When I first jumped ship from one shitcoin to what I believed wasn't another shitcoin in 2021, it was under the presumption that what I thought was Bitcoin was intended to be better money solely without any added fluff or technical excess; you can even find early comments on this account and my Lain account where I joke about not being a maxi for whatever reason(s) I'd give on a per-comment basis.
I'd never be one of any currency and/or shitcoin, but especially not BSC, because I can now see how fundamentally compromised it's been by those who have no interest in it truly displacing the banking system or fiat. No one can force anyone else to pick up on that, the cognitive dissonance has to wear off naturally.
A block size increase scales transaction throughput linearly: 10x bigger blocks => 10x more transactions per block
You think we can scale bitcoin by continuing to increase block size, for example until we can match VISA with 65,000 tps?
@BitcoinErrorLog comes out swinging:
source
Preach, brother!
source
.