{
  "txid": "1d1bd56492e1df0139c6e4381b7a467d488d906016bb610ad31946f62c9d47f7",
  "block_height": 0,
  "time": null,
  "app": "treechat",
  "type": "post",
  "map_content": "To make BSV robust against quantum computers, be aware that post-Quantum PQ exchanges are larger with a native PQ address (with integrated pubkey and PQ sig). Currently, if you decide to use a \"classic\" post-Quantum exchange with Handcash, Shua, ElectrumSV, Simply.cash, 1satordinal, Yours, and many others, you will be limited by the 10KB cap. This applies to all BSV wallets, including Metanet. There is an alternative with Runar that doesn't use a native PQ address.\r\nI propose a purely quantum protection solution using BSV scripts and smart contracts, without soft forks or protocol changes. This differs from self-spending to a new PQ address.\r\nHow does it work? Runar is a compiler that transforms high-level code (TypeScript, Rust, Go, Python, etc.) into pure Bitcoin scripts.\r\nIt natively includes verification of two post-quantum (PQ) signature schemes: WOTS+ (Winternitz One-Time Signature) and SLH-DSA/SPHINCS+ (FIPS 205, hash-based and proven quantum-resistant).\r\nWith just 4 lines of code, you can compile a quantum-resistant wallet that produces a locking script of approximately 10 KB. Minimal example (in the playground): \r\ntypescript\r\nclass QuantumWallet extends StatefulSmartContract {\r\n  // your PQ pubkey here\r\n  public spend(sig: PQSignature) {\r\n    verifyPQ(sig, this.pqPubkey);  // v\u00e9rification int\u00e9gr\u00e9e WOTS+ ou SPHINCS+\r\n  }\r\n}\r\nThe compiler injects all the verification code (based solely on existing BSV opcodes: hashes, etc.).\r\nThe result: a 10 KB locking script that any BSV wallet can handle today. The problem with the 10 KB limit and \"heavier\" PQ addresses?\r\nSolution: a native PQ address (with integrated pubkey and PQ signature) would be enormous (SPHINCS+ signatures are often several kilobytes). The transaction values \u200b\u200bwould become gigantic, and many current wallets would reject them.\r\nRunar's solution: you don't use a native PQ address.\r\nYou lock your BSV wallets in a clever 10 KB script that contains the PQ verification logic.\r\n\u2192 The script is exactly 10 KB \u2192 it fits perfectly within the practical limit of BSV wallets (many are still capped at ~10 KB for compatibility reasons, even though BSV allows much more).\r\nWhen you spend: you provide the (large) PQ signature in the unlocking script.\r\nHow to do it in practice (steps): Go to the playground: https://runar.run\r\nChoose TypeScript (the simplest option).\r\nCreate your quantum wallet contract (the playground has ready-made examples for PQ).\r\nCompile \u2192 you directly get the hex script + the locking script.\r\nWith the Runar SDK (or any wallet that supports P2SH/custom scripts), send your BSV to this script (a single migration transaction).\r\nOnce locked: even if a quantum computer breaks ECDSA tomorrow, your funds are protected because the expenditure requires a WOTS+ or SPHINCS+ signature (impossible to forge quantumly).\r\nHuge advantage over the classic method: No need for a network soft fork.\r\nWorks today with existing wallets.\r\nThe script remains auditable and 100% Bitcoin Script.\r\nKnown limitation: the migration itself (the locking transaction in the script) remains vulnerable as long as it uses ECDSA. So do it before Q-Day. Here's a solution worth its weight in gold that can protect your Satoshi BSVs from future quantum attacks. Time is precious, let's not waste it. I've given you the solution, my dear BSV friends; it's up to you to share and deploy it.\r\nSo... Yippee ki yay Mother Qubit !",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "14aqJ2hMtENYJVCJaekcrqi12fiZJzoWGK",
  "display_name": "BiBiP",
  "channel": null,
  "parent_txid": null,
  "ref_txid": null,
  "tags": null,
  "reply_count": 0,
  "like_count": 0,
  "timestamp": "2026-04-01T20:40:49.000Z",
  "media_url": null,
  "aip_verified": true,
  "has_access": true,
  "attachments": [],
  "ui_name": "BiBiP",
  "ui_display_name": "BiBiP",
  "ui_handle": "BiBiP",
  "ui_display_raw": "BiBiP",
  "ui_signer": "14aqJ2hMtENYJVCJaekcrqi12fiZJzoWGK",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}