From fb3f0840d115ab01cb4b981257bf92113e249179 Mon Sep 17 00:00:00 2001 From: ezrasisk <85811167+ezrasisk@users.noreply.github.com> Date: Fri, 6 Mar 2026 14:42:00 -0600 Subject: [PATCH 1/2] Add P2MR ScriptPublicKey for quantum resistance Introduce a new ScriptPublicKey version for P2MR that enhances quantum resistance and MAST functionality with minimal consensus changes. --- KIP22-P2MR-qr | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 KIP22-P2MR-qr diff --git a/KIP22-P2MR-qr b/KIP22-P2MR-qr new file mode 100644 index 0000000..653cd9e --- /dev/null +++ b/KIP22-P2MR-qr @@ -0,0 +1,13 @@ + The idea is introduction of some new ScriptPublicKey version that commits only to the root of Merkle trees alternative spending scripts, in MAST like structures.There is no key-path spend and no public key is ever exposed in the output itself. Spending requires a Merkle proof plus leaf script execution fully using the existing Kaspa script engine, including upcoming covenants. + +P2MR delivers, immediate quantum resistance against Shors algo on secp256k1, as there is no pubkey to attack; native MAST functionality such as privacy, efficiency and complex conditional scripts hidden until spent; with minimal consensus change: one new output version plus ~150-250 LOC. + +Shors algo renders elliptic curve crypto insecure after CRQSs materialize. Once public keys are exposed on-chain, an adversary can store the transaction and later recover the private key. BTCs legacy P2PKH already has mitigated this by hiding pubkeys until spending time. As in BIP 360 where pay to merkle root provides steps towards quantum resistant security, the goal proposed here is to follow suit and achieve even more with far less because: Kaspa has no Taproot wherein to remove keypaths; perhaps allow constant protocol incrementation via hard forks; use preexisting merkle code and KIP-10, introspectively. + +P2MR justifies minimized design change through leveraging blake2b-256, existing merkle proof verification, kip10 and bech32 addresses, introducing no new cryptography or protocol changes, resulting in quantum hardened MAST over PoW. + +Specifically this means the following: + - The new ScriptPublicKey format version chosen to be an on-wire serialization as the 2bytes version, the 8bytes script_length, and the 32bytes payload, which is the merkle root. Totalling in size 42 bytes for SPK/P2MR. + - The merkle root construction of domain separated blake hashes, or tagged hashing, where Root is the final branch hash after all pairwise combinations of leaf_hash and branch_hash; the merkle root is the single remaining 32byte hash after this deterministic reduction process: compute leaf_hash(leaf_version, script) for every script in the set, producing the initial list of all leaf nodes -> if the list contains exactly one node then that leaf_hash is the merkle root and no branch_hash is called, otherwise while there is more than one node in the current list one must walk the list in adjacent pairs and lexicograghpically sort for each pair smaller to larger; if the current list has an odd number of nodes, the final unpaired node is carried forward unchanged - as it maybe a leaf hash of an earlier branch hash -> when one hash remains, it is the merkle root. The only difference here being the use of blake and kas domain tags. + - The spending rules, which dictate that an input spending P2MR outputs must provide in-script-signatures / witness-data, which consists of the merkle proof, the leaf version byte, leaf script bytes and then the stack elements required by the leaf script, to recompute root from leaf plus proof using the aforementioned hashes that must be equal to the payload in ScriptPublicKey, and then execute the leaf script, without key-path shortcuts. + - The address format. An extended bech32 introducing another byte version "qm" (or whatever-else). Becuase no pubkey appears in the output or on-chain until leafs requiring explicitation are revealed, this is considered "quantum safe." Only the chosen leaf is ever shown and the expressiveness of leaf and silverscript are future natural inheritances, readying for post quantum signatures. From cdafc96705eb5dc619e7f8fefaaf492949d6698f Mon Sep 17 00:00:00 2001 From: ezrasisk <85811167+ezrasisk@users.noreply.github.com> Date: Sun, 8 Mar 2026 13:34:12 -0500 Subject: [PATCH 2/2] Fix formatting and clarify address format description --- KIP22-P2MR-qr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/KIP22-P2MR-qr b/KIP22-P2MR-qr index 653cd9e..03dff9a 100644 --- a/KIP22-P2MR-qr +++ b/KIP22-P2MR-qr @@ -10,4 +10,4 @@ Specifically this means the following: - The new ScriptPublicKey format version chosen to be an on-wire serialization as the 2bytes version, the 8bytes script_length, and the 32bytes payload, which is the merkle root. Totalling in size 42 bytes for SPK/P2MR. - The merkle root construction of domain separated blake hashes, or tagged hashing, where Root is the final branch hash after all pairwise combinations of leaf_hash and branch_hash; the merkle root is the single remaining 32byte hash after this deterministic reduction process: compute leaf_hash(leaf_version, script) for every script in the set, producing the initial list of all leaf nodes -> if the list contains exactly one node then that leaf_hash is the merkle root and no branch_hash is called, otherwise while there is more than one node in the current list one must walk the list in adjacent pairs and lexicograghpically sort for each pair smaller to larger; if the current list has an odd number of nodes, the final unpaired node is carried forward unchanged - as it maybe a leaf hash of an earlier branch hash -> when one hash remains, it is the merkle root. The only difference here being the use of blake and kas domain tags. - The spending rules, which dictate that an input spending P2MR outputs must provide in-script-signatures / witness-data, which consists of the merkle proof, the leaf version byte, leaf script bytes and then the stack elements required by the leaf script, to recompute root from leaf plus proof using the aforementioned hashes that must be equal to the payload in ScriptPublicKey, and then execute the leaf script, without key-path shortcuts. - - The address format. An extended bech32 introducing another byte version "qm" (or whatever-else). Becuase no pubkey appears in the output or on-chain until leafs requiring explicitation are revealed, this is considered "quantum safe." Only the chosen leaf is ever shown and the expressiveness of leaf and silverscript are future natural inheritances, readying for post quantum signatures. + - The address format. An extended bech32 introducing another byte version "qm" (or whatever-else). Because no pubkey appears in the output or on-chain until leafs requiring explicitation are revealed, this is considered "quantum safe." Only the chosen leaf is ever shown and the expressiveness of leaf and silverscript are future natural inheritances, readying for post quantum signatures.