Quick status update on the taproot-only madness 😄
In short: we’re through the “big surgery”.
The codebase is now basically a
taproot-only, hex-based protocol core. Most of the classic Bitcoin baggage (WIF, Base58 addresses, P2PKH/P2SH/P2WPKH, etc.) has been thrown overboard.
Keys & addressesThe whole WIF / Base58 key & address world is gone.
Private keys and xpub/xprv-style things are now
plain binary structures that we import/export as hex strings.
No more
Base58Type, no WIF prefixes, no legacy Base58 addresses. Instead we have a cleaned-up, own prefix+payload scheme that actually fits a modern taproot-centric system.
Address handling is also much simpler now:
Only Bech32m Only taproot (v1, 32-byte witness program)Plus an “unknown witness” path reserved for future versions.
All the old stuff (P2PKH / P2SH / P2WPKH / P2WSH / multisig / OP_RETURN) is either fully removed or effectively unused.
In practice:
if this node considers something an address, it’s basically taproot.Scripts, policy, descriptorsScript and policy logic has been aligned with this: we
focus only on taproot outputs.
Plain pubkey/pkhash/scripthash/multisig/NULL_DATA types are out. Standardness checks no longer juggle datacarrier limits or bare multisig special cases.
The descriptor language got a big cleanup too. We kept the
taproot building blocks:
tr(...),
rawtr(...) taproot
pk(...)Miniscript in Tapscript context …and we dropped the classical stuff:
pkh(...),
wpkh(...) sh(...),
wsh(...) multi(...),
sortedmulti(...) combo(...),
addr(...), etc.
Address derivation is written with the assumption that it ends up with a
taproot address, not picking from a mixed legacy zoo.
Wallet sideSame philosophy on the wallet layer:
Legacy ScriptPubKeyMan is gone
LEGACY / P2SH_SEGWIT / “old” BECH32 output types are gone
All those “implicit P2WPKH / P2SH-P2WPKH” tricks have been removed
The wallet is now focused on the
descriptor-based, taproot-centric path.
The old HD chain loading model was also removed – this environment simply doesn’t need it anymore.
Signatures & quantum stuffRight now, the signing logic is
still using the Schnorr/Taproot path – but this is
only temporary.
The idea is: Use the
existing, well-tested Taproot signing mechanismGet the new core stable and well tested on top of it
Then move on to redesign the whole signing / block / transaction handling stack to be truly
quantum-safe.
On the PSBT side we’re already taproot-oriented (we care about v1, 32-byte witness programs), but the underlying cryptography is
still the same curve family as Bitcoin today.
So to be very clear:
This is NOT quantum-safe yet. Compared to original Bitcoin, it’s
not more secure (cryptographically) at this moment – what changed is the structure, not the curve.
Key parsing reflects this as well: we parse hex (compressed/x-only pubkeys, new hex-format extended keys), without Base58 – but the
signing primitive itself is still classical, not quantum-safe.
Where we are nowThe important part:
The code compiles The big structural refactor is
done This is a
working, taproot-only core, not just a design document
The signing layer is
still not quantum-safe, so right now this system is
not more secure than Bitcoin originally was, from a post-quantum perspective.
What we’ve actually done is:
Deleted tons of very old, unnecessary legacy code that only held us back
Consciously refused to keep compatibility with a bunch of old paths Opened up clean space to build something new on top of a much simpler, modern core
This isn’t a cosmetic patch – it’s a full
taproot-only protocol core.
On top of it we’re
still using the old (non-quantum-safe) signature layer for now, but the foundations are finally in a shape where we can realistically build a brand-new,
quantum-safe signing + block + transaction model without being chained to a decade of legacy compatibility code.
