# Bitcoin Inqusition 29.2 **URL:** \ **Category:** Implementation\ **Tags:** announcement, inquisition\ **Created:** [February 7, 2026, 12:21pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236 "2026-02-07T12:21:40Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\ **Post date:** [February 7, 2026, 12:21pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/1 "2026-02-07T12:21:40Z")
Bitcoin Inquisition 29.2 is now available from > **[Release Bitcoin Inquisition 29.2 · bitcoin-inquisition/bitcoin](https://github.com/bitcoin-inquisition/bitcoin/releases/tag/v29.2-inq)** > > Bitcoin Inquisition 29.2 is now available. > It is based on Bitcoin Core 29.3rc2 and includes heretical activation of BIP 54 (Consensus Cleanup), BIP 118 (ANYPREVOUT), BIP 119 (CHECKTEMPLATEVERIFY), ... This is based on [Bitcoin Core 29.3rc2](https://github.com/bitcoin/bitcoin/releases/tag/v29.3rc2/). This includes support for the following proposed consensus changes: - [BIP 118](https://github.com/bitcoin/bips/blob/584f4a732ba94199fc097fbb9b4660db868dd712/bip-0118.mediawiki) SIGHASH\_ANYPREVOUT ([PR#84](https://github.com/bitcoin-inquisition/bitcoin/pull/84)) - [BIP 119](https://github.com/bitcoin/bips/blob/584f4a732ba94199fc097fbb9b4660db868dd712/bip-0119.mediawiki) OP\_CHECKTEMPLATEVERIFY ([PR#85](https://github.com/bitcoin-inquisition/bitcoin/pull/85)) - [BIN-24-1](https://github.com/ajtowns/binana/blob/8264328e6c7fd9e9f30efb8273fb94700f001454/2024/BIN-2024-0001.md) aka [BIP 347](https://github.com/bitcoin/bips/blob/740e826c19391a7a290933f514c15518e00780f0/bip-0347.mediawiki) OP\_CAT ([PR#83](https://github.com/bitcoin-inquisition/bitcoin/pull/83)) - [BIN-24-3](https://github.com/bitcoin-inquisition/binana/blob/3477736b354a8523615695971c6250cc4f98d452/2024/BIN-2024-0003.md) aka BIP 348 OP\_CHECKSIGFROMSTACK ([PR#87](https://github.com/bitcoin-inquisition/bitcoin/pull/87)) - [BIN-24-4](https://github.com/bitcoin-inquisition/binana/blob/3477736b354a8523615695971c6250cc4f98d452/2024/BIN-2024-0004.md) aka BIP 349 OP\_INTERNALKEY ([PR#86](https://github.com/bitcoin-inquisition/bitcoin/pull/86)) - [BIP 54](https://github.com/bitcoin/bips/blob/ed7af6ae7e80c90bcfc69b3936073505e2fc2503/bip-0054.md) Consensus Cleanup ([PR#90](https://github.com/bitcoin-inquisition/bitcoin/pull/90), [PR#99](https://github.com/bitcoin-inquisition/bitcoin/pull/99)) The first two of these have been active on the default signet since block 106704 (2022-09-06), the third since block 193536 (2024-04-30), and the fourth and fifth have been active since block 272592 (2025-10-06). Note that transactions making use of these new features will not be relayed by nodes that don’t support these features, so if you’d like your transaction to get to a miner, you’ll need to peer with other inquisition nodes. An easy way to do this is to specify `addnode=inquisition.bitcoin-signet.net`. By default, Bitcoin Inquisition nodes will advertise themselves via the subversion string, which can be viewed with `bitcoin-cli -netinfo 3`. See the [23.0 announcement](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021275.html) for more details. BIP 54 activation has ~~not yet been signalled for on the default signet network, pending miner upgrades, but is expected to be soon~~ now been triggered for activation (as of block 290513), so should be active as of block 291168, in about five days. ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 9, 2026, 8:50am UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/2 "2026-03-09T08:50:59Z")
I’ve been running experiments on the Bitcoin Inquisition signet, starting with OP\_CAT. For this first round I built a witness-locked script: data lives in the witness, the script only verifies the hash — only the holder of part\_a/part\_b can spend. Commit tx `084d5a9c6a8c176c24edc0a8b7ce54ed65808a326367d8a9299b4460ecaada09` → Spend tx `00072d4aa354b5987eb8f2ffec440db7467b0581c5e845a6a0ef6999b2d05656` Code and full transaction details: [GitHub - aaron-recompile/inquisition-experiments: my experiments on Bitcoin Inqusition · GitHub](https://github.com/aaron-recompile/inquisition-experiments) One observation: commit transactions show up on both standard signet explorers (mempool.space) and Inquisition nodes, but reveal/spend transactions only appear on Inquisition nodes — standard nodes reject the block entirely. The two networks fork at the first block containing a new-opcode spend. Expected, but worth noting for anyone trying to verify via public explorers. CSFS, CTV, and INTERNALKEY experiments next. ---
**Author:** ![AntoineP](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/antoinep/32/483_2.png) [@AntoineP](https://delvingbitcoin.org/u/AntoineP)\ **Post date:** [March 9, 2026, 5:10pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/3 "2026-03-09T17:10:16Z")
> [@AaronZhang](#): > > The two networks fork at the first block containing a new-opcode spend. Expected No, not expected! BIP 347 is a soft fork. Fortunately the spend tx [does show up](https://mempool.space/signet/tx/00072d4aa354b5987eb8f2ffec440db7467b0581c5e845a6a0ef6999b2d05656?showDetails=true) on Signet explorers. Presumably you actually checked _before_ the spend was included in a block? It would not show up then because regular Signet nodes consider it non-standard and won’t accept it in their mempool. ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 9, 2026, 6:34pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/4 "2026-03-09T18:34:21Z")
Thanks for the correction, Antoine — and for prompting a deeper look. Verified on mempool.space/signet: the spend tx is there with 3600+ confirmations. You were right. Your correction pushed me to think more carefully about why. Non-upgrade nodes accept the block not because they understand the new rule, but because OP\_CAT is an unknown opcode in Tapscript — OP\_SUCCESS under old semantics. The “network fork” I thought I observed was just a timing artifact: the tx never entered regular nodes’ mempools (non-standard), so it was invisible before block inclusion. CSFS, CTV, and INTERNALKEY experiments coming next — this time I’ll reason from first principles before drawing conclusions. ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 16, 2026, 5:01am UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/5 "2026-03-16T05:01:11Z")
Following up on my earlier OP\_CAT note, I ran CSFS and CTV experiments on Bitcoin Inquisition and tracked timing end-to-end. CSFS pair: - Commit: 96df453d9e9ce50fdfca063528b03e3310033c3a61818bbe30e7fab5c61133e3 - Reveal (final, RBF replacement): 32fa307f3a570cfe93ebf7c101dba9ee8f289a5ca926dfed8baca92bb196e36b CTV pair: - Commit: 2378642548c7f86472d3998a0fcb2d364084783e487dd87c1e1020684aed51de - Reveal: 9ccbce8ad87f0f94632119245a42537c9fbd2c8f706621f76f513339f220d55c What I learned: 1. Visibility is layered (policy vs consensus). Before confirmation, reveal spends may be missing from standard signet mempools due to policy. After mining, they are visible on public explorers. So “not seen yet” != network fork. 2. Confirmation latency is the real variable. In my runs, commit-\>reveal was short, but reveal-\>confirm dominated and reached ~3.9 days. 3. Acceleration depends on script constraints. - CSFS: a higher-fee replacement reveal confirmed quickly (~113s after replacement broadcast). - CTV: parent template constraints make direct replacement less flexible; CPFP is the practical accelerator. 1. Methodologically, recording reveal-\>confirm is essential. If we only record tx creation times, we miss the most interesting behavior. Happy to share raw RPC snapshots / watch logs if others want to compare miner policy behavior. ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 25, 2026, 3:10am UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/6 "2026-03-25T03:10:26Z")
Following up on my earlier CAT/CSFS/CTV runs, I tested an **IK + CSFS** composition on Bitcoin Inquisition. This uses OP\_INTERNALKEY to source the pubkey from Taproot execution context rather than witness. Commit: [9930e922…0ea8](https://mempool.space/signet/tx/9930e922036a80d04a96a4b08f15838bcb880ce2a4be91da0b24af1484e10ea8?showDetails=true) Reveal: [8d0b2156…dd8f](https://mempool.space/signet/tx/8d0b2156e9425afe64cabf3c906da255b6b86c51cb8968f828d5253fc261dd8f?showDetails=true) Script: OP\_INTERNALKEY OP\_CHECKSIGFROMSTACK (cbcc) Witness: [sig, message] — no pubkey in witness Observation: - Pubkey is no longer caller-supplied - It is sourced from Taproot execution context (internal key) This shifts authorization from “who provides a key” to “who created the UTXO”. However, since the message is fixed, the (sig, message) pair is replayable across UTXOs with the same internal key. Full breakdown (stack / control block / derivation): details: [https://medium.com/@aaron.recompile/op-internalkey-op-checksigfromstack-on-signet-identity-bound-authorization-04f0440557bc](https://medium.com/@aaron.recompile/op-internalkey-op-checksigfromstack-on-signet-identity-bound-authorization-04f0440557bc) ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [March 27, 2026, 10:58pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/7 "2026-03-27T22:58:37Z")
Following up on my earlier CAT/CSFS/CTV runs, I tested a **CAT + CSFS** composition on Bitcoin Inquisition. This combines OP\_CAT, OP\_SHA256 and OP\_CHECKSIGFROMSTACK. Commit: [926c40c1…008f](https://mempool.space/signet/tx/926c40c1b72edb904a3bb7bf96795f351a6be597fc1aeab1390c15e0133b008f?showDetails=true) Reveal: [75db54de…65ca2](https://mempool.space/signet/tx/75db54dea1f125174699710bd5b517ae13b6e09b3293a0b0f463ea5561a65ca2?showDetails=true) Script: OP\_CAT OP\_SHA256 \ OP\_CHECKSIGFROMSTACK (7ea820…cc) Witness: [sig, part1, part2] — message not provided directly Observation: - Message is no longer provided as a single item It is assembled on-chain via OP\_CAT (part1 || part2) - Signature is over SHA256(part1 || part2) but concatenation happens during execution - Signature does not commit to transaction data - The (sig, part1, part2) tuple is replayable across UTXOs with the same script (same oracle pubkey) Full breakdown (stack / witness / tapscript / control block): [https://medium.com/@aaron.recompile/op-cat-op-checksigfromstack-on-signet-dynamic-message-oracle-authorization-8c73e1ef5353](https://medium.com/@aaron.recompile/op-cat-op-checksigfromstack-on-signet-dynamic-message-oracle-authorization-8c73e1ef5353) ---
**Author:** ![AaronZhang](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/aaronzhang/32/1823_2.png) [@AaronZhang](https://delvingbitcoin.org/u/AaronZhang)\ **Post date:** [April 24, 2026, 5:52pm UTC](https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236/8 "2026-04-24T17:52:41Z")
Following up on my earlier CAT/CSFS/CTV/IK+CSFS/CAT+CSFS runs on Inquisition, I tested SIGHASH\_ANYPREVOUT (BIP 118) the same way. Funding A: [4b64…344a](https://mempool.space/signet/tx/4b6451082fe4349fdb2acad6bf0964c6cfd8c9cbf5161806fc342b051dee344a?showDetails=true) (50,000 sats) Funding B: [543c…a5eb](https://mempool.space/signet/tx/543c97f777ea04624392f6a1547146d6e98996b38aec0794f6b79e3275f6a5eb?showDetails=true) (50,000 sats) Spend A:[03c0…f3a4](https://mempool.space/signet/tx/03c0577c1d47da32804d098187644d0eee18b448aded2f427cd02193c070f3a4?showDetails=true) (signed) Spend B: [4609…1a43](https://mempool.space/signet/tx/46091190c74d8fd4b39be67a2e945a19b021850e7f8d9e378f5eb11722ae1a43?showDetails=true) (same witness, no re-signing) Script: \<0x01 || xonly\_pubkey\> OP\_CHECKSIG (35 bytes) Witness on both: [sig (65B with 0x41 sighash byte), leaf (35B), control\_block (33B)] Two observations: 1. The 0x01 pubkey prefix is the only opt-in trigger. The Inquisition node sees it and switches to Msg118 / Ext118 instead of standard BIP 342 SigMsg. Existing tapscripts unaffected. 2. Msg118 omits sha\_prevouts, so cross-prevout reuse falls out of which fields are missing. Same amount + same scriptPubKey → same digest → same signature works. Under SIGHASH\_ALL (0x41), sha\_outputs is still committed, so modifying outputs still fails verification. Full breakdown Blog: [https://medium.com/@aaron.recompile/sighash-anyprevout-on-signet-when-signatures-stop-binding-to-utxos-eed4fc475668](https://medium.com/@aaron.recompile/sighash-anyprevout-on-signet-when-signatures-stop-binding-to-utxos-eed4fc475668)