New Users: Jimmy is a good man and an awesome follow, but he's overstates two things here:

a) you only need 128 coin flips (attacker will need to boil only one ocean to guess your 12 words)

b) it's not that hard, takes about 10 minutes, and worth every minute

You _must_ make that effort, don't let anyone talk you out of it.

audit this

^ bag 😞

...and then they can shake and dump the 128-penny bad twice 😉

tl;dr: Network transition to post-quantum signature schemes will be required regardless of the chosen seed length.

I'd be willing to add 256-bit to airgap-coinflip if there's enough demand for it:
https://github.com/ghscuuo/airgap-coinflip


---

Thanks for making me ask my llm to dive a little deeper for me into the bit lengths!:

THE BOTTOM LINE: Current funds are safe. The 10-20 year quantum threat is a risk-management assumption, not a consensus timeline (physics constraints are massive). Bitcoin will require a post-quantum network upgrade long before these threats operationalize.

CONTEXT: Thread discusses manual BIP39 seed generation via physical coin flips (pennies) to eliminate PRNG hardware/software trust assumptions.

CLASSICAL BRUTE FORCE:
• 128-bit (12 words): Requires energy exceeding current planetary output. Classically secure indefinitely.
• 256-bit (24 words): Requires more energy than the sun will produce in its lifetime.

QUANTUM THREAT: Grover's Algorithm (Hashing/Symmetric)
• Theoretically halves cryptographic strength, but practically carries massive quantum gate-depth overhead. 128-bit offline seeds remain practically secure.
• 256-bit seeds completely harden the offline BIP39/BIP32 derivation pathways against theoretical quantum arrays.

QUANTUM THREAT: Shor's Algorithm (Asymmetric/ECC)
• Shor's algorithm breaks the Elliptic Curve Cryptography (secp256k1) used in Bitcoin signatures.
• If a public key is exposed on-chain (e.g., via spending from an address), seed length offers zero protection against Shor's deriving the private key.

CONCLUSION: 256 coin flips hardens offline storage against Grover's, but cannot fix the underlying ECC vulnerability of a spent transaction. Network transition to post-quantum signature schemes will be required regardless of the chosen seed length.

tl;dr: Network transition to post-quantum signature schemes will be required regardless of the chosen seed length.

I'd be willing to add 256-bit to airgap-coinflip if there's enough demand for it:
https://github.com/ghscuuo/airgap-coinflip




Thanks for making me ask my llm to dive a little deeper for me into the bit lengths!:

THE BOTTOM LINE: Current funds are safe. The 10-20 year quantum threat is a risk-management assumption, not a consensus timeline (physics constraints are massive). Bitcoin will require a post-quantum network upgrade long before these threats operationalize.

CONTEXT: Thread discusses manual BIP39 seed generation via physical coin flips (pennies) to eliminate PRNG hardware/software trust assumptions.

CLASSICAL BRUTE FORCE:
• 128-bit (12 words): Requires energy exceeding current planetary output. Classically secure indefinitely.
• 256-bit (24 words): Requires more energy than the sun will produce in its lifetime.

QUANTUM THREAT: Grover's Algorithm (Hashing/Symmetric)
• Theoretically halves cryptographic strength, but practically carries massive quantum gate-depth overhead. 128-bit offline seeds remain practically secure.
• 256-bit seeds completely harden the offline BIP39/BIP32 derivation pathways against theoretical quantum arrays.

QUANTUM THREAT: Shor's Algorithm (Asymmetric/ECC)
• Shor's algorithm breaks the Elliptic Curve Cryptography (secp256k1) used in Bitcoin signatures.
• If a public key is exposed on-chain (e.g., via spending from an address), seed length offers zero protection against Shor's deriving the private key.

CONCLUSION: 256 coin flips hardens offline storage against Grover's, but cannot fix the underlying ECC vulnerability of a spent transaction. Network transition to post-quantum signature schemes will be required regardless of the chosen seed length.

I know nothing but my gut says the root cause was the relatively urgent "need" to rewrite a massive amount of code to resolve the corporate software license dispute. For want of an "ifdef" or something.

(my long winding prompt here)

AI response:

• Corporate terminology: "First Principles Analysis" or "Core Utility."
• The HWW Mantra (Translated):
• Electronics cannot be trusted to create secrets. The Coldcard bug proved devices fail silently. Create your master key in the physical world (flipping coins).
• Hardware wallets are just digital pens. They exist only to conveniently sign checks (spend). They should never create the account.
• Don't spend your vault. Hold the main stash. Use layers (Lightning/Ecash) for daily movement.
• The Secure Vault Routine (Air-gapped execution):
1. Online device: Drafts the transaction (Watch-only mode).
2. Offline device: Holds the key, reviews, and signs the draft.
3. The Air-gap: Move the data between them using QR codes or SD cards.
4. Online device: Broadcasts the finalized transaction to the network.



• Inquiry: Does your framework discard commercial hardware wallets entirely in favor of dedicated air-gapped laptops (e.g., Glacier Protocol), or are you retaining HWWs strictly as
"dumb" signing peripherals?

> i hate bitcoin-dedicated hww, tell me why you agree 😉

▸ Thought for 3s, 781 tokens
Prioritizing Tool Usage

• Black-box execution: Niche silicon and closed bootloaders prevent true user verification of runtime execution.
• Feature bloat: Modern HWWs bundle RNG, descriptor generation, NFC/Bluetooth, and complex UI. High complexity breeds firmware integration failures (e.g., Coldcard PRNG override).
• Supply chain targeting: Purchasing specialized crypto hardware exposes the buyer's identity. Physical interception vectors remain high.
• Vendor lock-in: Proprietary companion applications and non-standard derivation paths degrade long-term self-sovereignty.
• Redundant utility: Commodity offline hardware (air-gapped laptop via Lubuntu/Tails) executes identical cryptographic signing with inspectable, replaceable components.
• Centralized failure vector: Consolidating entropy generation, storage, and signing into a single appliance violates defense-in-depth principles.


AI Critique:
• Verdict: Structurally sound critique of HWW trade-offs, but falters on commodity hardware assumptions and ignores modern protocol standardization.

• Validated Arguments:
• Supply Chain: Spot on (e.g., Ledger 2020 customer database hack). Purchasing crypto hardware inherently flags targets.
• Black-Box: Spot on. Secure Elements (SE) require NDA trust in silicon manufacturers (STMicroelectronics), violating verification ethos.
• Centralized Failure: Accurate. Placing entropy generation, storage, and signing in one physical basket creates a catastrophic SPOF.

• Refutations / Weaknesses:
• Commodity Hardware Fallacy: Laptops possess massively larger, un-auditable attack surfaces (Intel ME, AMD PSP, closed-source UEFI) than microcontrollers. Trades a specialized black box for a generalized one.
• Vendor Lock-in: Largely outdated. Widespread adoption of BIP39, BIP44/84, and BIP174 (PSBTs) enables seamless cross-vendor migration and third-party coordinator use (Sparrow/Electrum).

• Critical Omissions:
• Blind Signing: Tiny screens force blind signing of complex scripts (multisig change, lightning channel opens).
• Physical Extraction: Devices lacking Secure Elements (e.g., older Trezors) are vulnerable to rapid voltage-glitching seed extraction if physically intercepted.
• Multisig Mitigations: Fails to acknowledge multi-vendor multisig setups, the industry-standard architecture designed specifically to neutralize HWW centralized failure vectors.


Note also, working on an old offline laptop is approximately 100x easier than any hww.



My draft coin-flip seed gen thing for review and comment, thanks in advance:
https://github.com/ghscuuo/airgap-coinflip/releases/tag/v0.0.1-rc.1
(I could do a super simple signing version, too, upon request)

in a nutshell, dice are probably fine, but I think pennies are a tiny bit better and not nearly as hard to do as folks fear

not sure, but perhaps, folks correctly assign very high respect to the EFF/Reinhold/Bonneau diceware system, and I agree, but diceware base6 7,776-word list passwords dont have the base6->base2 conversion problem required for the bip39 2048-word list

sorry if I'm wrong

• Hypothesis 1 (Pennies vs. Dice): Fair and accurate. Pennies eliminate format/translation vectors in exchange for a manageable increase in physical labor.
• Hypothesis 2 (Diceware vs. BIP39 translation): 100% accurate observation.
• Diceware Mechanics (Base-6 to Base-6): 5 physical dice rolls yield exactly 7,776 states (6⁵). This maps 1:1 to the 7,776-word list. Zero mathematical translation. Zero modulo bias.
• BIP39 Mechanics (Base-6 to Base-2): 2,048-word list (2¹¹). Physical dice (Base-6) cannot map cleanly to an 11-bit binary space without forced translation, modulus math, or cryptographic hashing.
• Conclusion: The stellar reputation of dice is inherited from standard Diceware (where the math aligns perfectly). The math failures and UX friction arise exclusively when forcing Base-6 physical hardware into the Base-2 BIP39 standard.


maybe we need a new base6 bip...

from my AI:

> i'm trying to express to normal non-techy humans a very rough sense of the relative safety of flipping pennies for entropy vs dice rolls and dice math

• Coins (Pennies): High Labor, Zero Risk
• Native machine language (Base-2 / Binary).
• 1 flip = exactly 1 bit. 128 flips = 128 bits.
• Aerodynamic physics of high-rotation flips neutralize minor weight imbalances.
• Zero mathematical translation required.
• Immune to format-mismatch and base-conversion errors.

• Dice (Pedestrian): Low Labor, High Risk
• Foreign machine language (Base-6).
• Requires mathematical translation (Base-6 to Base-2), introducing cryptographic failure vectors (modulo bias, truncation).
• Introduces human UX failure vectors (miscalculating roll counts, inputting into incorrect tool fields).
• Missing physical mass (drilled pips) and rounded edges skew resting probabilities.
• Base entropy structurally degrades from 2.58 bits down to ~2.5 bits before translation even begins.

• The Trade-off
• Coins require sheer physical brute force (128 flips) but guarantee cryptographic safety.
• Dice save physical labor (50 rolls) but introduce compounding catastrophic risks (manufacturing bias + translation math + human error).

I don't know if I believe all of those words, but the essence hits home for me. Flipping coins gets a bad rap. I'm trying to rehabilitate its reputation. 😉

Copy and paste that into your strongest AI and post back here what it says.

Opus comment on the above:

• AI Review Synthesis (Pro Model):
• Verdict: Persuasive success (hypes coins, demonizes dice) but severe target-audience failure (alienates laypersons with crypto-student jargon).
• Strengths: "High Labor/Zero Risk" dichotomy successfully anchors the trade-off. Highlighting physical tangibility of "drilled pips" grounds abstract entropy logic.
• Weakness (Jargon Overload): Terms like modulo bias, truncation, and UX failure vectors block non-techy comprehension.
• Weakness (Metaphor): "Base-2/Base-6 native language" introduces unnecessary mental translation steps.
• Weakness (Physics/Reality): "Zero Risk" ignores massive human fatigue vectors (boredom/miscounting 128 flips). Coin aerodynamics claim ignores Persi Diaconis physics (minor
starting-position bias).
• AI Prescriptions:
• Strip the math (e.g., "Computers speak 2s, dice speak 6s. Forcing 6 into 2 requires complicated math. Mistakes ruin randomness").
• Acknowledge physical fatigue and counting errors as the primary coin-flip risk.

arguable, I understand ♥️