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 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.
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.
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.
No, not expected! BIP 347 is a soft fork. Fortunately the spend tx does show up 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.
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.
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.
Confirmation latency is the real variable.
In my runs, commit->reveal was short, but reveal->confirm dominated and reached ~3.9 days.
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.
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.