P2WOTS: 64 Slot Winternitz Output Type (witness version three) #35488

This Pull Request introduces Pay-to-WOTS (P2WOTS), a new native Bitcoin output type using witness version 3 that provides unconditional post quantum security using only SHA-256. P2WOTS contains no elliptic-curve key material anywhere.

The threat: Shor's algorithm breaks secp256k1 in polynomial time on a cryptographically relevant quantum computer.

-Design- scriptPubKey 34 bytes OP_3 (0x53) || PUSH32 (0x20) || commitment[32]

In single signer mode the 32 byte commitment is a Merkle Key Tree root over 64 independent WOTS+ key pairs derived from the owner's own master secret. Each incoming UTXO is spent using an independent slot key.

Single sig spending witness (42 items) Items | Content

[0..33] | 34 WOTS+ chain elements (32 bytes each) [34] | slot_nonce, per-slot domain separator [35] | key_index, which of 64 slots (0-63) [36..41] | auth_path[0..5], Merkle sibling nodes

The k-of-n multisig uses the same 34 byte scriptPubKey format with the commitment = SHA("wots39-multisig-v1" || k || n || root[0] || ... || root[n-1])

The Sighash is structurally identical to BIP-341, reusing PrecomputedTransactionData cache = TaggedHash("P2WOTS/sighash", epoch || hash_type || nVersion || nLockTime || sha_prevouts || sha_amounts || sha_scriptpubkeys || sha_sequences || sha_outputs || spend_type || input_index)

-Deployment- Deployed as a soft fork via witness version (v3). Pre-SegWit nodes see P2WOTS outputs as anyone-can-spend. Post-SegWit, pre-P2WOTS nodes classify it as WITNESS_UNKNOWN and relay without enforcing. SCRIPT_VERIFY_P2WOTS is currently activated unconditionally in GetBlockScriptFlags(). Production deployment would use a standard BIP9 / BIP8 activation entry.

-New Files- src/crypto/wots_sha256.h -complete WOTS+ library src/test/wots_tests.cpp -C++ unit tests test/functional/test_framework/wots39.py -Python mirror, byte identical test/functional/feature_wots39.py -end to end functional tests on regtest test/functional/bench_wots39.py -Per-block verification benchmarks doc/bip-p2wots.md -Full specification

-Modified Files- src/script/solver -WOTS Witness detection at witnessversion==3 && size==32 src/script/interpreter -SCRIPT_VERIFY_P2WOTS, sighash, full verifier src/script/script_error -SCRIPT_ERR_WOTS_VERIFY src/script/sign -stub case src/addresstype -WitnessUnknown{3, ...} for bech32m round trip src/validation -IsP2WOTSOutput() flag activation

♻️ Automatically closing for now based on heuristics. Please leave a comment, if this was erroneous. Generally, please focus on creating high-quality, original content that demonstrates a clear understanding of the project's requirements and goals.

📝 Moderators: If this is spam, please replace the title with ., so that the thread does not appear in search results.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35488.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible typos and grammar issues:

• Licesnse -> License [misspelled BIP metadata field]
• thier -> their [misspelled in the abstract]
• discrete logaritm -> discrete logarithm [misspelled in motivation]
• relevent -> relevant [misspelled in motivation]
• narritive -> narrative [misspelled in motivation]
• isues -> issues [misspelled in motivation]
• compatability -> compatibility [misspelled in motivation]
• What stays hiddens: -> What stays hidden: [incorrect plural form obscures meaning]
• 10-minuteblock interval -> 10-minute block interval [missing space breaks readability]
• microsecondss -> microseconds [misspelled comment in benchmark script]

Possible places where comparison-specific test macros should replace generic comparisons:

• [test/functional/feature_wots39.py] assert an0 != an1 and an1 != an2 and an0 != an2 -> replace with separate assert_not_equal(...) checks for each pair.
• [test/functional/feature_wots39.py] assert len(sn) == WOTS_TREE_SLOTS, assert len(apath) == WOTS_TREE_HEIGHT, assert len(d) == WOTS_L, assert len(sig) == 34 * 32, assert len(c1_1) == 32, assert len(items) == ... -> use assert_equal(...) for the length checks.
• [test/functional/feature_wots39.py] assert sn[0] != sn2, assert an0 != sn[0], assert leaf != pk_a0, assert wots_merkle_node(leaf, leaf1) != wots_merkle_node(leaf1, leaf), assert c1_1 != bytes(32), assert c2_2 != c1_1, assert c2_3 != c2_2, assert c1_3 != c2_3, assert c_rev != c2_3 -> use assert_not_equal(...).
• [test/functional/feature_wots39.py] assert d[32] == 0x1F and d[33] == 0xE0 and assert d[32] == 0 and d[33] == 0 -> split into two assert_equal(...) checks so failures report the exact mismatching byte.
• [test/functional/feature_wots39.py] assert len(items) == WOTS_WITNESS_ITEMS, assert len(items) == 1 + 2 + 2 * WOTS_MULTISIG_ITEMS_PER_SIGNER, assert len(items) == 1 + 3 + 2 * WOTS_MULTISIG_ITEMS_PER_SIGNER -> use assert_equal(...) to get clearer failure output.

^{2026-06-08 20:50:17}

This is a genuine proposal for post quantum native output type using witness version 3 and WOTS+ signatures. The full specification is in doc/bip-p2wots.md included in this PR. I will be pursuing the formal BIP process in parallel. Happy to address any technical questions from reviewers!

This should be posted on the bitcoin-dev mailing list, the Delving Bitcoin forum or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on Stack Exchange. The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.

Closing, sorry I submitted to the wrong repository. This belongs in the BIPS first, will submit through the proper process.

This belongs in the BIPS first, will submit through the proper process.

Hi @opus-lux, if helpful, that process begins by first describing the idea to the bitcoindev@googlegroups.com mailing list to gather feedback on viability and community interest before working on a formal description. For more info, please see https://github.com/bitcoin/bips/blob/master/README.mediawiki (thanks!)