Transaction

j"19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAutM~Title: The AI workspace that works for you. | Notion URL Source: https://www.notion.so/bridgetdoran/Entropy-Collision-27e91fd47f8b80679734dd31067abfa7 Markdown Content: Version: 9-25-25 Note: In this write-up, “collision” doesn’t mean a hash collision or two users picking the exact same 256-bit key at random. It refers to a mis-derived private key accidentally overlapping with an externally used address - almost certainly because the other party’s key came from weak entropy. During HD wallet development, an implementation error led me to accidentally generate a private key that controlled an external BitcoinSV address with transaction history. This case study examines how that overlap occurred, what it reveals about entropy quality in the wild, and the broader security implications. While scanning for addresses using an incorrectly implemented derivation script, one of the generated private keys provided access to an external address containing 1 satoshi. The address had transaction activity spanning December 2023 to February 2025, confirming it belonged to another party. This wasn’t theoretical, it was a real overlap with someone else’s funds. The scanning script was designed for BIP39 mnemonic-based wallets, but was mistakenly used with a raw hex seed: Plain Text Copy // Script assumed BIP39 mnemonic workflow const seed = bip39.mnemonicToSeedSync(inputString) const hdKey = HDKey.fromSeed(seed) // But received raw hex instead of mnemonic phrase ​ When bip39.mnemonicToSeedSync() receives raw hex instead of a mnemonic phrase, it doesn’t reject the input. Instead, it deterministically processes the hex string through PBKDF2 with a “mnemonic” salt, deriving a completely different 64-byte seed and creating a valid but completely unintended key tree. The original seed was generated using cryptographically secure methods: Shell Copy node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" ​ This used Node.js’s crypto.randomBytes(32), which pulls from the OS entropy pool and produces ~256 bits of entropy. The misprocessing through BIP39 created an entirely different key space and accidentally discovered an address within it. Scenario 1: Impossibly Rare Coincidence Probability: ~1 in 2^256 Effectively impossible with proper entropy Scenario 2: Weak Entropy (Most Likely) The external address was generated with poor randomness Low-entropy seeds create predictable key spaces Deterministic misprocessing made it possible to stumble into one of those predictable spots When bip39.mnemonicToSeedSync() processes arbitrary input: It doesn’t validate or reject non-mnemonic strings It applies a deterministic transformation (PBKDF2) This creates a repeatable “wrong” keyspace that can still be explored If the external address was based on weak entropy, it occupied a small predictable portion of the total keyspace. The misprocessing explored that portion and found it. This case demonstrates that weak entropy isn’t just theory: Predictable seed generation creates discoverable addresses Even secure seeds, if misprocessed, can accidentally intersect with weak ones Small overlaps matter: if 1 satoshi is at risk, so is everything else The overlap resulted from: Misusing BIP39 functions for non-mnemonic input Deterministic processing of incorrect data No validation of seed format This wasn’t a failure of cryptography. It was an implementation error that likely revealed someone else’s weak entropy. If multiple implementations make similar mistakes or users keep generating weak seeds: Key spaces overlap “Random” addresses become predictable Funds remain at risk even years later Validate inputs: reject non-mnemonic data if expecting mnemonics Make assumptions explicit: document what your code expects Verify tool assumptions (mnemonic vs raw hex) 😉 Document derivation logic Use testnet first Use proven wallet software Ensure entropy comes from secure randomness Never reuse seeds across environments Weak entropy is still out there Implementation bugs can surface it Better validation and standards are needed This wasn’t a failure of BitcoinSV’s cryptographic model or BIP-32’s design. It was an implementation slip that intersected with someone else’s weak entropy. The collision happened because: An implementation mistake created a deterministic but incorrect key derivation path Someone else’s address was likely generated with insufficient entropy The deterministic nature of both allowed them to intersect The real lesson: Strong cryptography depends on strong implementation. Weak entropy and careless seed handling create vulnerabilities that persist for years, waiting to be discovered by accident or malice. This case study is shared for educational purposes. The collision involved minimal funds (~1 satoshi) and was discovered accidentally during development. No exploitation occurred. Author: Bridget Doran text/plainutf-8file.txt
|"1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5SETtreechat_post_id$9b6fd4cd-5165-4f35-877d-b259774c2217attached_to_tx@b3a86bf687eb6b08151790a19b5da2d78745f6a669c780038e83245fc9be9fb1