Every BTQ spend type, live on-chain.
A Field Guide to BTQ Transaction Types tours the ten address and spend constructions BTQ ships — the ECDSA family Bitcoin users already know, and the Dilithium P2MR family that keeps custody post-quantum. Every type comes with a real, confirmed testnet transaction to open in the explorer.
Two families. One ledger.
BTQ keeps the ECDSA address types Bitcoin users know — legacy, P2SH-SegWit, bech32, Taproot and wsh multisig — so existing wallets, exchanges and tools can move value from day one. Alongside them runs the post-quantum family: Dilithium signatures inside BIP-360 Pay-to-Merkle-Root outputs, where a 1,312-byte public key stays hidden behind a 32-byte Merkle root until the moment it is spent.
For each of the ten types, the guide covers what it is, why BTQ includes it and who it is useful for — then points to a mined testnet transaction to inspect: inputs, outputs, script types and witnesses, right in the explorer. Learn by clicking, not just by reading.
Ten types. All with receipts.
Every address and spend construction BTQ ships, from legacy ECDSA compatibility to Dilithium post-quantum custody. Each row links to a confirmed testnet transaction.
| Type | Family | Why it's here | Live example |
|---|---|---|---|
| Legacy P2PKH | ECDSA | Classic Bitcoin compatibility | 8491a822…104d629f ↗ |
| P2SH-SegWit | ECDSA | Bridge for older SegWit wallets | 2c9af353…0594e330 ↗ |
| Bech32 (P2WPKH) | ECDSA | Default modern SegWit receive | 559e061b…bb1d54e5 ↗ |
| Bech32m / Taproot | ECDSA | Advanced ECDSA script trees | 5ed561a6…ed489a22 ↗ |
| wsh 2-of-3 multisig | ECDSA | Shared ECDSA custody | 7b07314d…6e1fee94 ↗ |
| P2MR single-key | Dilithium | Standard post-quantum receive | 18bd0dc8…4209f4c2 ↗ |
| P2MR OP_TRUE leaf | Dilithium | Demo of the P2MR script-path layout | a0a068b8…3b218daa ↗ |
| P2MR multisig 2-of-3 | Dilithium | Dilithium multisig custody | 3301fec1…db75ab9c ↗ |
| P2MR threshold 2-of-3 | Dilithium | The same 2-of-3 rule, threshold-script style | d1b26028…1f7415c4 ↗ |
| Legacy Base58 Dilithium | Dilithium | Historical format — where BTQ came from | 665eb4ac…a7c14ba4 ↗ |
Four side-by-side tours.
The guide's suggested path through the explorer — open each pair in two tabs and compare what you see.
Same send, different witness
An ECDSA bech32 spend next to a Dilithium P2MR spend: the same “send coins” idea, very different witness weight.
Same custody, different cryptography
The ECDSA 2-of-3 next to the Dilithium CHECKMULTISIG 2-of-3: the same approval rule, different signature algorithm.
Structure first, signatures second
The bare OP_TRUE leaf first, then a real Dilithium leaf spend: P2MR structure, then Dilithium authorization.
One rule, two script styles
CHECKMULTISIG Dilithium beside the threshold accumulator: the same 2-of-3 rule expressed two different ways.
Why P2MR is the Dilithium home.
BTQ does not sprinkle Dilithium across every script type. It lives in one place — Pay-to-Merkle-Root, witness version 2 — for four practical reasons.
- One address type — one Dilithium look (tbtq1z…), not a pile of similar-looking formats.
- Room for scripts — single-key, multisig and custom leaves live in the same tree model.
- Cleaner upgrades — Dilithium opcodes belong in P2MR tapscript, not mixed into ECDSA-era witness-v0 shapes.
- Easier ops — mining, wallets and explorers can all treat one Dilithium receive type as the default.
A Field Guide to BTQ Transaction Types
The complete 9-page community note by Oscar and Barney Chambers — what every type is, why BTQ ships it, and where to see it live. Written against the public testnet, with all ten transaction identifiers in the appendix.
The chain behind the guide.
The guide (PDF)
The full 9-page document — read it inline or download it for offline.
Open PDF →ExploreBlock explorer
Every example in the guide links straight into the live testnet explorer.
Open explorer →ArchitectureProtocol
The UTXO model, signature scheme and network parameters behind these types.
Read the protocol →ImplementationBTQ Core
The full-node implementation that validates every one of these spends.
View source →