These include a new segwit version, different length segwit v1 public keys, a new segwit v1 script version, and additional opcodes. The writer proposes a number of changes to the SegWit v1 proposal. These changes include introducing 33-byte v1 witness addresses that encode a secp256k1 ECC point. This can be spent either by a direct Schnorr signature (s, R) on that point or a script (s), the witness data for the script (wit(s)), with a Taproot/Merkle path to the script (P, path(S, s)). The Taproot scripts should get a version, and new Schnorr ops should be used to replace the ECDSA CHECKSIG/CHECKMULTISIG ops. The proposed changes are seen as modest compared to what is conceivable, such as graftroot, g’root, cross-input signature aggregation, non-interactive half-signature aggregation, and re-enabling opcodes (CAT, MUL, XOR, etc). The author notes that OP_SUCCESS upgrades could be developed and deployed independently of these methods. Furthermore, the article provides an example of how Eltoo might work in a taproot world. The author also describes how HTLC outputs could be prepared for SHA256 preimages and secp256k1 preimages. In conclusion, the article suggests that simple OP_SUCCESS upgrades could be implemented alongside schnorr/taproot/etc., while remaining an independent feature at the BIP/concept/implementation levels.