Do you know any details of how this soft fork would be applied? Would we just have to update to a new knots version?
I support this softfork.
https://github.com/bitcoin/bips/pull/2017
This was such a good read.
To see so many good people acting in good faith and collaborating to find a solution of a major attack / problem is a nice feeling.
I love real Bitcoiners.
Of course in the comments there are bad actors whose comments mostly troll and try to muddy the water and introduce confusion and mess. That is expected with the current stance of some of the Core devs. But I hope majority of Node runners and even Miners are good actors.
https://github.com/bitcoin/bips/pull/2017/commits/3c718237072c107ced8c3531a487354fbdae55df
Further reading on that topic is here:
https://gnusha.org/pi/bitcoindev/aN_u-xB2ogn2D834@erisian.com.au/T/
Discussion
Yes, I think so that we will need to run a new Bitcoin Knots version which will be released on the agreed timing of the start of the soft fork and majority of the network would need to run it to be effective as it seems it is User Activated Soft Fork (UASF)
From AI:
How a Bitcoin soft fork is executed
1) Proposal & specification
Developers write a Bitcoin Improvement Proposal (BIP) that defines the new, backwards‑compatible ruleset and activation method (commonly BIP‑9, BIP‑8, or a modern variant).
2) Code, review, and client releases
Changes are implemented in node software (e.g., Bitcoin Knots), reviewed by maintainers, tested, and released as new client versions for node operators, wallet authors, services, and miners.
3) Signalling / activation method
An activation method coordinates deployment. Common methods:
BIP‑9: miners signal support by setting a version bit in block headers during defined windows; if signaling ≥ threshold (historically 95%) within the window, the change “locks in” and activates after a follow‑up period.
BIP‑8: similar but can include a mandatory activation at timeout (user‑activated optionality).
UASF (User‑Activated Soft Fork): nodes enforce a new rule from a chosen activation time regardless of miner signalling (relies on majority of hash or economic nodes to avoid chain split).
Miner‑Activated Soft Fork (MASF): miners adopt and mine under new rules; nodes follow the longest valid chain.
4) Lock‑in and enforcement
Once activation criteria are met (e.g., lock‑in threshold reached or activation time passes), upgraded miners and enforcing nodes begin rejecting blocks/txs that violate the new rules. Older nodes still accept blocks that conform to the new, stricter rules, so the change is backwards compatible.
5) Post‑activation monitoring
Node operators, exchanges, wallets and miners monitor for unexpected issues, soft‑fork compliance, and any reorg or split risk. Further patches or opt‑in changes may follow.
Notes / risks
Soft forks are safer than hard forks because old nodes remain compatible, but risk remains if a large portion of miners or economic nodes do not adopt (possible temporary chain splits or replay/withdrawal issues for some services).
Well‑known examples: SegWit (activated via BIP‑9/BIP‑148 coordination), Taproot.
More relevant info here:
https://www.bitstack-app.com/en/learn-bitcoin/understanding-bitcoin-fork-activation-methods
Timing: Users must upgrade before the activation point. Nodes that fail to upgrade will continue following the old rules and may end up on a different chain if a split occurs.
