diff --git a/ch10.asciidoc b/ch10.asciidoc
index bc3ceca7..e5ec9159 100644
--- a/ch10.asciidoc
+++ b/ch10.asciidoc
@@ -2392,28 +2392,6 @@ is a soft fork because a transaction that is valid under BIP65 is also
 valid on any client that is not implementing (ignorant of) BIP65. To
 the old clients, the script contains an NOP code, which is ignored.
 
-===== Other ways to soft fork upgrade
-
-The reinterpretation of NOP opcodes was both planned for and an obvious
-mechanism for consensus upgrades. Recently, however, another soft fork
-mechanism was introduced that does not rely on NOP opcodes for a very
-specific type of consensus change. This is examined in more detail in
-<<segwit>>. Segwit is an architectural change to the structure of a
-transaction, which moves the unlocking script (witness) from inside the
-transaction to an external data structure (segregating it). Segwit was
-initially envisioned as a hard fork upgrade, as it modified a
-fundamental structure (transaction). In November 2015, a developer
-working on Bitcoin Core proposed a mechanism by which segwit could be
-introduced as a soft fork. The mechanism used for this is a modification
-of the locking script of UTXO created under segwit rules, such that
-unmodified clients see the locking script as redeemable with any
-unlocking script whatsoever. As a result, segwit can be introduced
-without requiring every node to upgrade or split from the chain: a soft
-fork.
-
-It is likely that there are other, yet to be discovered, mechanisms by
-which upgrades can be made in a forward-compatible way as a soft fork.
-
 ==== Criticisms of Soft Forks
 
 ((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft