SHA

TheGreatMuffin

> Can AI data centers be used to attack btc network? No, what data centers (AI or not) are doing, has nothing to do with bitcoin. If you are referring to various mining-side attacks, it's not possible because bitcoin mining requires very "dumb", specialized devices that can do only one thing well: perform [SHA256 hashes](https://learnmeabitcoin.com/technical/cryptography/hash-function/). These devices are useless for anything else. And devices that are not optimized for that (data centers) are useless for bitcoin mining (or attacking it as a mining entity). > Can they be used to vote on bips setting up a ton of nodes? An entity can set up hundreds of thousands of nodes but they cannot enforce rules for other nodes. Every node is verifying everything on its own, so if there's a majority of "fake" nodes that follow different rules, everybody else will just ignore those nodes and continue happily on the "real" chain. The network is not really a democracy (nor is the BIP process itself), it's more of an anarchic system, which is often described as "rules, but no rulers". Meaning, there is nobody to enforce rules, you just can follow them and be in sync with those that follow the same rules, or you don't. Nobody forces you to do anything; neither an entity nor the majority of nodes.

Illustrious-Boss9356

You know how many things that run on SHA256 can be switched easily without the need for consensus from many different conflicted parties? And ECDSA will be broken before SHA256, you know the thing that secures public/private keys? And your bank account, mortgage, etc. are all centralized. All that needs to happen is for me to prove to JP Morgan that I'm me. Cannot prove that I'm the owner of a certain BTC address if others know my private key. And how will a BIP deal w a dwindling security budget? These are real issues and I'm not suggesting there aren't solutions. I'm saying it's concerning that very few people are actually debating these issues, rather they're selling and moving on to other things. I didn't sell any BTC for almost a decade, now I'm selling regularly until the actual community around Bitcoin cares about Bitcoin the chain, rather than Bitcoin the number.

CryptoAnarchyst

Lmao… 10 years from now BIP will be in place to deal with it… but more importantly, you know how many things run on SHA256 encryption? You think that Bitcoin tokenomics are an issue? How about your personal data? Your bank account? Your mortgage? You’re falling for the distraction, not the real issue

Illustrious-Boss9356

A lot of talk here about asset class capital rotation into AI, how exciting or boring BTC is. Again, I want to stress please get involved and talk about the important things fundamental to the chain itself. Noderunning, upcoming BIP-110 soft/hard fork, and quantum migration. Yes the supply is limited to 21m, but there are unlimited chains. Yes, SHA256 is quantum resistant but ECDSA is mot. Yes, spam on chain could become an issue and there aren't enough economic transactions to crowd out cheap spam. These are all real issues and if the owners of BTC just want the number to go up... boy we're gonna be in for a rough ride. Please spend your BTC. Make bets w your friends in BTC. Send/receive your BTC! Accept BTC for selling things!

geobees

Why it has to be a person with a name? NSA invented SHA-256, they published papers on anonymous e-cash in the 1990s. Intelligence agencies fund crypto research. Governments have created tech that escaped control (early internet via DARPA). Think!

xamboozi

At $1, something is seriously wrong - like the encryption is broken and the chain is lost. The economy would be in full meltdown with the loss of Eliptic Curve and/or SHA256.

AbramsTankVeteran29

What are the odds that aliens developed something that uses SHA 256?

hevnsnt

Yes. DPs come straight from the kangaroo walk, and each “jump” is one elliptic curve operation on secp256k1, so anything that does more of those per second makes more DPs. A purpose-built secp256k1 ASIC could be a big jump, the way mining ASICs crushed GPUs on SHA256. But you can’t repurpose Bitcoin ASICs for it: they’re hardwired for double SHA256 and physically can’t do elliptic curve math. Bitcoin FPGAs are different. They’re reprogrammable, so you could flash a new bitstream that runs the kangaroo walk instead of SHA256. The catch is someone has to write that bitstream (256-bit modular math plus the walk in Verilog, no off-the-shelf version), and a lot of the old mining FPGAs are too small to beat a modern GPU anyway. And no matter the hardware, the search is enormous: puzzle 135 needs roughly 2^67 operations. Faster silicon shortens the timeline, it doesn’t make the problem small. For the pool it makes no difference what you run, a faster worker just means more DPs and a bigger share.

GlitteringBelt4287

Market is worried about quantum computing cracking SHA-256 Bitcoin suffered while ZEC benefited

didnt_hodl

if the addess was never used for sending, only for receiving, the public key is not exposed (normally, in most cases) most BTC is stored at addresses exactly like that, with public key unknown. so quantum would need to break the double SHA256 which they never promised to do there is some amount of coin which does have exposed public key, I want to say 1 million coins maybe a bit more, but definitely it is a small fraction of the total supplly. however,it is not up for grabs. it can be trivially traces and greedy quantum physicists would not be able to profit from it. everyone knows these are Satoshi coins and you are not Satoshi. so, stealing is a crime if I got a key to your car or to your apartment am I free to sell it?

AsbestosDude

The bigger issue is ECDSA signatures and exposed public keys. People keep acting like "quantum can't break SHA-256 efficiently" somehow means Bitcoin is immune, when that's not actually the argument being made.

didnt_hodl

I wish all greedy quantum physicists best of luck. Go ahead and grab those Satoshi coins! (and see what happens next) oh wait, they never promised to break SHA-256 did they? because they can't

theshonufff

Hedera is SHA-384 quantum resistant.

alami9

Hedera signs every HBAR transaction with Ed25519, an elliptic-curve scheme that Shor’s algorithm breaks outright, so a quantum computer can derive your private key from your public key and take your coins. That’s the part that actually guards your money, and it’s wide open. Hedera bragging that its hashes are post-quantum doesn’t fix that, hashes were never the weak point (Grover only square-roots their strength, so SHA-256 stays safe). Protecting the history is the easy half; it’s the signatures, not the history, that hold your money.

alami9

RSA isn’t the point, because crypto doesn’t use it. Bitcoin and Ethereum sign every transaction with elliptic-curve keys (ECDSA on secp256k1), and that signature is the only thing standing between your coins and whoever wants them. RSA lives in the web and TLS world, not on the chain. What actually “records” the ledger is the hash function, SHA-256, and that’s the part quantum barely touches (Grover only halves its strength, and doubling the output undoes that). The part that guards your money is ECDSA, and that’s the part Shor breaks outright. So the record survives; the ownership doesn’t. And here’s the kicker that flips your milestone around: ECDSA breaks before RSA, not after. At the same security level, elliptic curves use smaller keys and take fewer logical qubits to crack than RSA. A quantum computer reaches the keys guarding your money first, and something like RSA-512 later. “RSA still works” isn’t the all-clear, it’s the alarm you hear after the house is already empty. The thing that falls first is the thing holding the money.

Staggeredmk4

I believe quantum computers in the near future (5+ years) are only a threat to old wallet addresses that are less secure than current. Development is constantly happening on newer, user friendly and more secure wallets. As far as the protocol itself (protected by SHA256 Algorithm) quantum computing is not a threat. Quantum computers are not very stable to extended periods of time, require massive amounts of continuous energy both for operation and more so for cooling. Even IF one could be successful, difficulty on the network adjusts every 2016 blocks (approx every 2 weeks currently) to maintain the 10 minute average block time. On top of that, IF that were to happen, it would signal enough consensus between nodes ands miners to actually create a hard fork to include a quantum resistant algorithm. Remember, with quantum computers, will also come quantum strength security development. So again, older wallet address’s are at a higher risk in the near future. This means Satoshi’s coins are at risk, but we are far enough along in Bitcoin I don’t think that would shake people’s belief in the system. As far as rewards go, the fees are expected to be so valuable that miners will still be incentivized to mine blocks. And OR people/businesses/governments will run their own miners as a way of protecting their bitcoin by contributing to the network somewhat like I am currently doing even now. Will that actually work? To be seen. That’s probably Bitcoins biggest risk in my opinion. Fortunately, the last subsidy rewards for the last actual Bitcoin to be mined will be in about 114 years, the year 2140, so we still have some time to figure that one out, or at least my grandkids might 😎

LearnBitcoinCom

They cannot do any of these directly. They can fund any of them, but the other four stakeholder groups are motivated by ideology and self-interest, not fee revenue. Money buys influence. It does not buy consensus. What ETFs CAN do is move the dollar-priced value of whichever fork survives a split. That's real, and it's the same power 21 million individual hodlers have collectively, just concentrated. What ETFs CANNOT do is rewrite the rules. The 21M cap, SHA-256, the block subsidy schedule — none of them are BlackRock-revisable. They can hold Bitcoin. They cannot redefine it. Two years of ETF inflows and outflows, zero rule changes. That's the receipt.

TapNo7498

für alle die sich fragen ob die adresse wirklich dead ist: TLDR: ja wrsl schon Claude: This is a Bitcoin address starting with 21 leading "1"s. In Bitcoin's Base58 encoding, leading "1"s represent leading zero bytes in the underlying 160-bit hash (RIPEMD-160 of SHA-256 of the public key). The math: Each leading "1" = 1 leading zero byte (8 zero bits) in the hash. 21 leading "1"s = 20 leading zero bytes + 1 character of the next byte being zero-ish Actually, the address 1111111111111111111114oLvT2 is the special "burn address" representing all 20 bytes = zero (the hash160 is 0x0000...0000) That's 160 zero bits required Probability of finding it by brute force: Probability per attempt = 1 / 2^160 ≈ 1 / (1.46 × 10^48) Hashrate context: The entire Bitcoin network's hashrate as of 2026 is roughly 700 EH/s = 7 × 10^20 hashes/second. But note: each Bitcoin address generation requires SHA-256 + RIPEMD-160 + key generation, which is much slower than pure SHA-256 mining. Let's still use the optimistic mining hashrate as an upper bound. Time calculation: Time = 2^160 / (7 × 10^20) seconds ≈ 1.46 × 10^48 / 7 × 10^20 ≈ 2.09 × 10^27 seconds ≈ 6.6 × 10^19 years ≈ 66 quintillion years For comparison, the age of the universe is ~1.4 × 10^10 years. So you'd need about 4.7 billion times the age of the universe using the entire Bitcoin network.

simonmales

On Braiins you can add whatever SHA256 pool you want Nicehash requires KYC for some things, maybe for mining too? Fyi I'm a mod at on Braiins subreddit.

Unable_Beat_3194

The average person doesn’t matter the vast majority will never understand economics, interest backdrops, scarcity or the importance of store of value for them to matter. The average person will buy when they don’t realize they are buying. Pension funds building strategic reserves, roboadvisories accumulating 1-3% across the board and when stock indicies like the Nasdaq add crypto firms like Coinbase. Don’t expect the average person to understand how a SHA 256 proof of work secures and creates mathematical scarcity.

NovastaKai

Google also uses SHA-256 to keep everything upto date now ;D

brtastic

That is not really correct. I mean maybe there could be multiple final words which will pass the checksum test for the same seed, however they will produce different entropies, different master keys. To obtain a master key from a mnemonic, PBKDF2-SHA512 is used on UTF-8 NFKD encoded mnemonic and password **strings**. Mnemonic is not turned back into seed to do this, it is used directly. Different mnemonic strings will produce different wallets.

AdProof7896

The last word is not merely the checksum. According to BIP39, random entropy is first generated; then, a checksum derived from the first ENT/32 bits of the SHA256 hash of this entropy is appended; and only thereafter is the entire sequence mapped into 11-bit groups to form words. Consequently, in a 12-word sequence, the last word contains 7 bits of entropy plus 4 bits of checksum; in a 24-word sequence, it contains 3 bits of entropy plus 8 bits of checksum.

LuckyWinds

Explain why then. Anyone who knows the basic fundamentals of bitcoin and encryption should know that eventually quantum will crack SHA-256. Whether it's in 10, 100, 1000+ years....it's inevitable at some point. So if that happens, why would it destroy public faith in bitcoin when it's already known it will happen at some point in the future?

Boring-General-1816

Your bank account, social media, email, telephones, MFA, all less sophisticated than SHA256. I don't really know im just rambling, but there's definitely things we use everyday that would be much easier to crack.

K42st

Little lesson, quantum computing using Shor’s algorithm would only be able to break the Eliptic Curve Signiture signature Scheme or (ECDSA) by reverse engineering the public key to find the private key and any BTC address that has not had the public key exposed is safe today and into the future until they produce a fix to the problem which is being worked on now maybe check out Post Quantum Lattice Signitures. Also without going into detail because it is very technical but this is a killer for your conversation anyway, NO quantum computer can break SHA256 not even if the quantum computer is using Grover’s algorithm the best it can do is reduce SHA256 security to 128 bits those 128 bits are unbreakable still so there is no threat to Bitcoins network. When peope hear quantum computer it all sounds very futuristic hey it can break anything when in reality they can’t and they are very unstable and likely years if not a decade away from being stable enough to do what we are discussing. Do your own research before you post and don’t spread FUD!

topbschoolsonly

Bitcoin security relies heavily on elliptic curve cryptography (ECDSA) and hashing (SHA-256) A sufficiently powerful quantum computer could theoreticall derive private keys from public keys much faster than classical computers and wouldn’t that make the whole thing collapse?

UnluckyAdministrator

That’s a fair criticism and honestly one of the main things I’m trying to be careful about. The intention is for the art layer to act more like an onboarding interface into Bitcoin-native concepts rather than becoming the product itself. A lot of people outside Bitcoin struggle to emotionally connect with ideas like SHA-256, proof of work, hardware signing, self-custody and cryptographic verification. The hope is that physical artifacts + narrative/UI design can create curiosity that eventually leads people deeper into understanding why Bitcoin’s security model matters in the first place. If the collectibles ever overshadow the educational/security side, I’d consider that a failure of the project direction.

crunchyeyeball

A passphrase can be any length (though some wallets do impose a character limit for practical reasons). The seed phrase + passphrase are processed using HMAC-SHA512, resulting in a 512-bit seed which acts as the "root" for all wallet keys. We therefore have a large but *finite* number of seed phrases or private keys, and an *infinite* number of possible passphrases. So it's not only *possible*, but *certain* that there not only *exists* some passphrase that creates a given private key, but there are an *infinite* number of them.

jgbjj

**Credit is not the same thing as pool content.** The line you quoted from `add_timer_randomness` in 2.6.26 is preceded by: ```c sample.jiffies = jiffies; sample.cycles = get_cycles(); sample.num = num; mix_pool_bytes(&input_pool, &sample, sizeof(sample)); ``` `mix_pool_bytes` unconditionally hashes the full sample (jiffies + cycles + num) into the pool. The delta filter that follows only updates `entropy_count`, the credit accountant. The pool content is not gated by credit. This matters because OpenSSL `RAND_poll` reads `/dev/urandom`, not `/dev/random`. `/dev/urandom` runs `extract_buf` over the entire 512-byte pool regardless of `entropy_count`. The output is `SHA-1(pool || ...)`. If you want to predict that output, you need to know what's in the pool, not what the credit counter says. So when you compute "10s to 100s of jittered IRQs × 2-5 bits credited each = 100-500 bits", that's the credit accountant's number. It's not a bound on the pool's predictability. **get_cycles at IRQ time carries jitter that survives the delta filter.** You're right that on a Penryn without nonstop_tsc the TSC isn't calibrated and the absolute TSC value during early boot is dominated by linear accumulation. But the value mixed into the pool is `get_cycles()` *at the moment the IRQ fires*. The jitter in "moment-of-IRQ" relative to predicted-boot-timing is what's captured. For a USB DMA completion IRQ during initrd unpack: the request was issued at TSC value `T_issue`, the IRQ fires at `T_issue + delta_controller`, where `delta_controller` is the controller's actual completion latency. That latency varies by ~100-1000 cycles per request based on queue state, bus contention, USB protocol timing, host-controller microarchitecture state. Two boots of identical hardware produce different `delta_controller` for nominally identical requests. The kernel's delta filter looks at successive `(jiffies_now - jiffies_prev)` differences. With 4ms jiffies and microsecond-scale IRQ rates, deltas are 0 for fast IRQs, the d2/d3 differences collapse, and credit goes to 0. But `sample.cycles` for each IRQ is still the high-res TSC, mixed unconditionally. The 5-10 bits of cycles-jitter per IRQ go into the pool whether or not they're credited. **Pool-mixed cumulative bytes during a Live USB boot.** Hundreds of disk-IRQ samples × ~16 bytes per sample = a few KB hashed into the 512-byte pool by the time userspace starts. Of those bytes, the jiffies and `num` fields are largely cooperation-pinnable (you know the IRQ count and approximate timing). The cycles fields are not. If we're being conservative on the cycles entropy: 100 IRQs × 5 bits unknown = 500 bits. If we're being less conservative: 1000 IRQs × 8 bits = 8000 bits. Reality is probably between these, depending on Live USB image and hardware. The "thousands" framing was imprecise; "hundreds-to-low-thousands" is closer. That's still much larger than the 36-43 bits implied by your 10^11-10^13 bound, and it's the part that constrains the recovery path. **The early-boot clocksource window doesn't change what's in the pool at OpenSSL-init time.** `clocksource_select` running late is true and doesn't matter for this question. By the time bitcoind launches and OpenSSL does its first `RAND_poll`, all the early-boot IRQs have already mixed into the pool. The pool at *that moment* is what determines the first 32 bytes of `/dev/urandom`. Whatever clocksource was active when the IRQs fired doesn't retroactively change the pool content. **Empirical test framing.** This is the right way to resolve it and I think we agree on the protocol. Concrete proposal: Lenny VM with: - virtio-rng disabled - KVM with deterministic launch (`-snapshot`, `-rtc base=2010-08-09T20:00:00`) - Live USB image emulated via virtio-blk reading a fixed image - bitcoin-0.3.2 built and launched at a fixed offset from boot - Capture first 32 bytes of `/dev/urandom` at OpenSSL init time, plus the change-key and signing nonce of a fixed test transaction Run N times with identical parameters. If outputs are byte-identical across runs, the unknown is in your "12 parameters" set and your bound holds. If they differ, the difference is in IRQ-jitter mixing that cooperation can't pin. I'll send the simulator source. Concretely what's there: * `MdRand.cs`: bit-exact port of `crypto/rand/md_rand.c` (stir-pool, pid mixing, exact MD update order, md_count[2] handling, global-md update semantics for both add and bytes) * `openssl_validation/oracle.c`: links against real openssl-0.9.8g, emits a deterministic trace * `Program.cs --validate-openssl <trace>`: replays the trace through MdRand, must match byte-for-byte If anything in that port doesn't match real OpenSSL output for your parameter set, that's a bug to fix before either of us trusts the C# side. The kernel `random.c` side I haven't bit-exact-ported because the simulator's job stops at OpenSSL's RAND_poll input; the kernel question is what we should resolve in the VM.

jgbjj

Thanks for the reply, for the record... I want to be wrong on this... but... a few points. **(1) Forward simulation is the right framing.** You're right that I argued against the wrong attack in my first post. "Reconstruct initial state, forward-simulate, accept the state whose trajectory produces the on-chain nonce" is well-posed. The nonce as validation channel is correct. The cryptographic question is therefore: how large is the search space of consistent initial states, and what's the per-candidate verification cost? That's where we still disagree. **(2) The "12 parameters" list is the wrong state space.** The arithmetic on your list (clocksource × utsname × boot ± 10s × ...) gives 10^(11) to 10^(13.) The arithmetic is correct given those inputs. The problem is the inputs. The kernel pool state at the moment OpenSSL first reads /dev/urandom is the SHA-1 mixing of: * `init_std_data` inputs, which IS your list (boot time, utsname, BIOS clock). * PLUS every `add_interrupt_randomness` call between boot and that read. The second set is what's missing. On 2.6.26, every interrupt handler calls into `add_interrupt_randomness` with timing data. Disk IRQs (`add_disk_randomness`), keyboard IRQs (USB initialization), network IRQs all feed the input pool before OpenSSL's first RAND\_poll. For a Live USB boot, the disk IRQ count between `init_std_data` and bitcoind's first RAND\_bytes is in the thousands. The image (squashfs/iso, hundreds of MB to GBs) gets read from USB to RAM before userspace starts. Each read is one or more IRQs, each timestamped at the kernel's high-res clocksource. That's the timing data that's not in your list. **(3) "P7450 falls back to jiffies because nonstop\_tsc=0" leaves out HPET.** Even when TSC pauses in C-states, `clocksource_select` on 2.6.26 picks HPET as next-best on any machine with HPET (which the P7450 platform has). HPET resolution is \~70 ns. So `add_interrupt_randomness` is reading nanosecond-resolution timestamps for every IRQ, not jiffies-resolution ones. A disk IRQ contributes log2(jitter\_window / 70ns) bits, typically 10-15 bits. Thousands of disk IRQs × 10-15 bits per IRQ = thousands of bits of entropy in the pre-bitcoind pool. That's the floor I was pointing to. Your list omits it entirely. **(4) "Headless bitcoind" is your assumption, not in the post.** Bitcoin 0.3.2 shipped as wxWidgets GUI by default. The post describes restoring a wallet and sending, consistent with GUI usage. The headless variant (`bitcoind`) was uncommon in Aug 2010. Mouse events feeding RAND\_add (`ui.cpp:393-399`) would have run. Even if you grant headless: see (3). Disk IRQs alone account for the entropy floor independently of the GUI. **(5)** `extract_buf` **count doesn't pin the output.** You list "extract\_buf count range: 6x". `extract_buf` outputs `SHA1(pool || count)` then mixes back into the pool. The output depends on the pool state, not just the count. The pool is the 4096-bit buffer that's been XOR-mixed with every interrupt input since boot. Six possible counts × one pool state isn't 6x; it's 6 × (whatever the pool entropy is). And the pool entropy is dominated by IRQ history. **(6) Clocksource argument double-counts.** You say "search space is dominated by clocksource ambiguity at 10^(3) to 10^(4") but also that hardware (which determines clocksource) is in the cooperative-input set. If cooperation pins the laptop model and BIOS revision, the clocksource is determined, not 10^(4-ambiguous.) You can't have it both ways. **(7) "Transaction proves privkey existed -> BDB durability irrelevant" is correct as a framing point but doesn't answer the recovery question.** Granted: the privkey existed in RAM at signing time. The cryptographic question is whether it can be reconstructed from public data + owner cooperation. That's well-posed. My answer is still: probably not, because (2) and (3). **(8) "Minutes on a laptop" doesn't follow from 10****^(13)** **anyway.** Even granting your bound, 10^(13) candidate sessions at \~50 microseconds per candidate (full forward-sim through md\_rand + EC scalar mul + hash160 compare) is 5 x 10^(8) seconds = \~16 years on one CPU. A 100-GPU farm at 1000x = \~2 months. That's not the original post's "minutes on a laptop with cooperation". Either the bound is much lower than 10^(13) or the laptop claim is wrong; both can't hold. **(9) Binary trust. Concession.** Source-only delivery, owner audit, air-gap, no wallet.dat exfiltration, non-published verification questions: that's a reasonable delivery model. SO I will retract the social engineering framing for that specific setup. The remaining question is whether the recovery actually works, which is (2) and (3). The right test for both of us is upstream of any simulator: take a deterministic VM with snapshot.debian.org's Lenny image, install bitcoin-0.3.2 against the actual `libssl0.9.8 0.9.8g-15+lenny*` package, and run it through wallet creation -> send transaction multiple times with your "12 parameters" held constant. If the same parameters reliably produce the same change-key and nonce across reboots of identical VM state, you've demonstrated reproducibility. If they don't, the entropy is in the IRQ events I'm pointing to. Greg's standard from earlier in the thread is the right one. Anyone disputing the math (you, me, anyone reading) can run that VM test directly. I'd find it informative either way; if your model is right and the determinism holds, I want to know. If it doesn't, that's also useful. I'll send source if you DM. Repo will be public after I clean up the experiment runner.

CompetitiveRough8180

Thanks for the detailed write-up. You did real work here. But several of your conclusions come from misreading the attack model, so let me address the specific points. (1) "md_rand is one-way, can't walk backward from nonce to change-key" Agreed, and that's not the attack. The approach is forward simulation: reconstruct the initial state (boot entropy + RAND_poll inputs), then forward-generate change-key and nonce from the same state. The nonce serves as a validation channel (k = s^-1(z + r*d) mod n with the sender's known privkey), not as a backward-inversion target. Match found = state correctly reconstructed = change-key obtained. No SHA-1 inversion required. (2) "5 bits saved by cooperation, not 33" This compares the wrong thing. The bn_rand time() RAND_add is one of ~12 parameters in the search space. The leverage comes from constraining the kernel-side random.c entropy chain that seeds /dev/urandom for RAND_poll, not from the bn_rand time() call. Specifically: - Hardware (clocksource: jiffies vs TSC): 10^3 to 10^4 - utsname exact string: 3x - Boot time +- 10s: ~36x - BIOS UTC vs local: 2x - Network/peer/IRC state (n_pre8 range): ~10^2 - PID range: 10x - extract_buf count range: 6x - BIOS timezone: 2x Multiplied: ~10^11 to 10^13. Without the cooperative inputs, search space is dominated by clocksource ambiguity alone. (3) "Real entropy floor is 6000+ bits from IRQ jitter, mouse, network" This is a desktop Linux assumption. Stone Man's specific scenario: - Headless bitcoind, no GUI - ui.cpp mouse-event RAND_add never runs. wxWidgets entropy injection is GUI-bound. - Live USB, fresh boot, minimal disk IRQ. - P7450 has nonstop_tsc=0 - TSC pauses in C-states, kernel falls back to jiffies clocksource for many IRQ timestamps. - 0.3.2 network entropy is minimal: peer nonce (8 bytes), no network packet timing fed to RAND_add. - No persistent /var/lib/urandom/random-seed - first /dev/urandom read seeded only by init_std_data (ktime + utsname) plus whatever extract_buf can squeeze before 192-bit threshold. The 6000-bit floor doesn't apply to a bare Live USB headless boot. The pre-bitcoind extract_buf count is small and modelable. (4) "The bug is BDB durability, not cryptographic" The change-key was successfully generated, written to wallet.dat, used to construct a valid signed transaction, and broadcast (it's at 167ZWTT8...n6s4ya8cGjqNNQjDwDGY31vmHg with 8899 BTC). The on-chain transaction proves the privkey existed in memory. BDB durability is irrelevant to whether the privkey existed - it did. The question is whether we can reconstruct it from public data plus owner-supplied parameters. That's a cryptographic question. (5) "Run my binary on your wallet.dat is social engineering" Fair concern about binary trust in general. Mitigations: - Source code is the deliverable, not a binary. - Owner can have it audited by anyone they trust. - Recovery can be done air-gapped on hardware that never touches a network. - Owner never sends wallet.dat anywhere. - The verification questions exist to filter impersonators, not to extract doxxable info from a real owner. They are not published. The asymmetry here is that the owner already controls the private key for the sender address (it's in his wallet.dat that he restored from). He doesn't share it. Cooperation means sharing setup details (laptop model, BIOS timezone, session timing), which are not sensitive. (6) "Forensic path is the only realistic one" If the original USB stick exists with persistence and BDB logs survived, yes - that's strictly easier and I'd recommend it. But absence of the USB stick doesn't close the cryptographic path; it just means cooperation is required to narrow the search. I'd be glad to look at your simulator. If you want to send the source, I'll run my parameter set through it and show where our state evolution diverges (if it does). Where is your simulator validated against - which OpenSSL test vectors did you use? That would let us compare apples to apples quickly. The methodology is testable. Greg Maxwell pointed out the right standard earlier in the thread: end-to-end self- validation on hardware that approximates the original setup. That's the next step. Anyone disputing the math can replicate the test directly.

jgbjj

I spent the last few days actually building this out in C# to test the claim from first principles. Source-verified against bitcoin-0.3.2 and openssl-0.9.8g (the exact versions Stone Man would have been running on a Debian Lenny Live USB on Aug 9, 2010). Posting findings because right now this thread is basically one skeptic, and the math doesn't support the framing. **What I built:** * A bit-level simulator of OpenSSL 0.9.8g's md\_rand state machine * A model of Bitcoin 0.3.2's actual PRNG draw sequence inside `CreateTransaction`, verified against the source (`main.cpp:2997`, `script.cpp:1089`, `bn_rand.c:142`, `md_rand.c:321`) * End-to-end experiments testing every claim in the post **What's actually true in the post:** * The change-address bug is real and well-documented. * Recovering the ECDSA nonce `k` from `(priv, signature)` is trivial: `k = (z + r*d) * s^-1 mod n`. My simulator confirms this in microseconds. * 0.3.2 has no keypool (it was added later). So change-key and signing nonce really are adjacent draws of the same md\_rand instance with nothing between them. This is the part that makes the post's framing sound plausible at first read. **Where the math breaks:** **1. md\_rand is one-way.** State evolves by XOR-ing SHA-1 outputs into a 1023-byte buffer (`crypto/rand/md_rand.c:321-508`). You cannot step backward from one draw to a previous draw without inverting SHA-1. Even with a full snapshot of state at nonce-time (the strongest position an attacker could possibly have), walking forward never produces the change-key, because the change-key was generated *earlier*. **2. The "10 orders of magnitude with cooperation" claim doesn't survive a careful read.** I went looking for any mechanic that would give cooperation real leverage. The closest thing is in `crypto/bn/bn_rand.c:142-143`: time(&tim); RAND_add(&tim, sizeof(tim), 0.0); This fires before every key/nonce generation. It's the most cooperation-amenable lever anywhere in the stack: knowing the exact send-time means you know the value being mixed in. But: * `time()` is second-granularity, not microsecond. * The on-chain block (73272 at 21:35:11 UTC) already constrains the send-time to about 30 seconds. * Pinning to the exact second saves about 5 bits, not 33. * OpenSSL credits this RAND\_add at `0.0` because they understood it doesn't add real entropy. **3. The real entropy floor is roughly 6,000+ bits**, dominated by per-IRQ TSC jitter (Linux 2.6.26 `random.c`), mouse-event RAND\_add inputs (`ui.cpp:393-399` adds 16 bytes per mouse event), RAND\_add from network packet timing, and the initial `/dev/urandom` read. None of this was ever written to durable storage. No "cooperation" reconstructs it. **4. The actual bug isn't cryptographic. It's a write-buffer durability issue.** This is the part nobody talks about. Berkeley DB auto-commits writes to a log file (`~/.bitcoin/database/log.000000xx`), and a separate flush thread checkpoints log to wallet.dat after 2 seconds of write inactivity (`db.cpp:681-735`). On a Live USB without persistence, the log directory is on tmpfs. A non-graceful reboot inside that 2-second window erases both the log entry and the not-yet-flushed wallet.dat update. That's the bug. It's a durability problem, not a cryptanalysis target. **5. The "run my CUDA on your wallet.dat" ask is exactly the shape of a social-engineering attack.** "It never leaves your hands" is not a meaningful guarantee when the binary itself has full read access to the file. "Verification questions only the original user would know" is a way to bind a prospective claimant to doxxable details. **If you actually are this person, please do not run anyone's binary against your wallet.** **The realistic recovery path, if any exists, is forensic, not cryptographic.** Does the original USB stick still exist with persistence configured? If yes, the BDB log file would directly contain the change-key in plaintext (0.3.2 had no wallet encryption, that came in 0.4.0). If no, no amount of cryptographic cooperation reconstructs entropy that was never recorded. I'm happy to share the simulator code, the 34-finding source audit, and reproducible numbers for any of the above. The post uses real primitives (nonce-from-sig recovery, md\_rand state machine, EC\_KEY\_generate\_key) to lend credibility to a claim that doesn't follow from those primitives. The math gap between "5 bits saved by cooperation" and "10 orders of magnitude saved by cooperation" is where the whole story falls apart.

HSuke

ECC, not SHA256

KrapnikSucks

And anything can be used as money: cigarettes, seashells, giant rocks, Tide detergent, Fed electronic funbux, or encrypted SHA256 hashes😎

Lefties_TheWorst7331

Quantum is far from breaking SHA 256. The highest Quantum has decrypt is like 14 bit. That's a LONG way away from cracking 256 bit. By then, I'm sure the network will be updated. And, if QC breaks BTC.. that will be the last thing anyone is worrying about, as it will break more larger infrastructures first.

brtastic

That gives you no additional security against wallet collision. The odds always were "almost impossible", but you seem to think that every seed phrase maps perfectly to one distinct wallet, and that adding a passphrase makes it impossible to obtain the same wallet as yours without the same seed + passphrase combination. That is false - private key space has always been a bit under 2\^256 possibilities, while 24 seed words already covers that entire space (11 bits per word, so 264 bits total, but some of the bits in the last word are used for checksum). Your wallet is obtained by using PBKDF2-SHA512 algorithm on your mnemonic and passphrase, followed by HMAC-SHA512. Out of resulting 512 bits, top 256 bits are used as your wallet, but at this point they have been mixed so much that it's not impossible for them to collide with the wallet a different seed phrase would yield, no password provided. tl;dr: passphrase gives you no additional protection against wallet collisions, but you were wrong to worry about this in the first place. However, that assumes wallet entropy was high enough at the time of generation. Passphrase can add much-needed entropy if you used bad RNG or provided low entropy yourself. That's still not much protection against collision, but can help against future hackers scanning certain entropy patterns generated by bad RNG.

didnt_hodl

it's just a demo at this point. I am sure it can be done cheaper if needed the thing is, it is not needed. there is no quantum computer that can solve ECDLP in the 10 minutes that bitcoin transaction takes better yet, simply keep your coins at an address that never sent anything and you are completely safe from quantum attacks, today. because, again, the double SHA is fully quantum hard today. and when you receive your public key is never exposed. seriously, there is absolutely no problem here, at all

didnt_hodl

at no point. 1. Quantum Safe Bitcoin is already possible, without even a soft fork, as was shown recently by StarWare. 2. Ethereum forks all the time, so they will be quantum hard very soon anyway 3. SHA is quantum safe already, so only the addresses with exposed public key are at "risk". anyone who is control of their keys can easily move the coins to a safe address 4. finally, quantum "computer" is a joke. it will simply never scale to anything serious. just a failed physics experiment, designed to milk to government for endless funding

decentralised_cash

51% attacks only matter on chains that have low network hashrate compared to the total amount of hashrate available for that algorithm. Bitcoin is the exact opposite end of the spectrum on this - it possesses the **overwhelming majority** of SHA-256d hashrate worldwide (upwards of ~99%), so attacking Bitcoin would be utterly infeasible. The only plausible attack vector *could* be a pool or group of pools gaining over 51% of the network hashrate and then controlling block production. However, if this were to occur, miners would almost certainly immediately point their hash elsewhere, thus fixing the problem.

willow-383

Not sure which is better: the “we are all Satoshi” anthem or the subtle SHA-256

decentralised_cash

You can generate a private key by flipping a coin 256 times, writing down a 0 bit for tails and a 1 bit for heads. That's the easy bit. Then, if you've got a few weeks on your hands, you can generate the public from the private key by doing elliptic curve scalar multiplication by hand. Difficult? Yes. Possible? Yes. Once you've got a public key, you can technically already receive Bitcoin directly (via a P2PK output). But if you want an actual address, then you'd need to sit down a few more weeks in order to compute the SHA-256 and then RIPEMD160 hashes of the public key, before finally Base58-encoding the hash (with a version byte + checksum).

RetiredAvocado

SHA256(SHA256(Block_Header)) Not really, except maybe another crypto coin that no one would care about.

fudelnotze

You cant target a specific wallet because you dont know EVERY wallet. You only can target a specific wallet if you know the seed or keys. But.... then its not needed to target it.... What you mean, maybe, is targeting by the partly known key because of the public key? But thats only possible if theres a nince, minimum. A nonce of 3 and above is MAYBE at risk at old wallets because they are short. But thats highly speculative too, nobody KNOWS it. Thats because of the SHA256 algorithm. Everytime you calculate it gives a different solution and its not 'backtraceable' (is that the right word?). So because of this special math you could computr it a million years and not a single time you have the same solution. But thats not the way a quantumcomputer works. A QC can hit randomly numbers extremely fast, its like it hut ALL random numbers at the same time. But thst means that it hits 0-9 atcthe same time because quants can have ALL states st the same time. It cant do math. The Quantumcomputer ONLY is the proof that one of the quantumtheory is right. Thats all.

Disgruntled_AnCap

The Internet itself and TOR were made by DARPA. GPS was made by the department of defense. AES was made by NIST. SHA-256 by the NSA. It doesn't matter if the CIA made Bitcoin. Like all of the aforementioned techs, it's way bigger and more useful than them now, and will certainly outlive the USGov.

Todo_es

Short answer: Yes — a Bitcoin address that has never been spent from is not vulnerable to quantum attack, because its public key has never been revealed. And no — receiving Bitcoin does not expose your public key. What you see on mempool is the address, not the public key. Let me break this down cleanly and precisely, because this is one of the most common misunderstandings in Bitcoin. --- ✔️ 1. A Bitcoin address is NOT a public key This is the key point. A Bitcoin address is a hash of the public key: \[ \text{address} = \text{HASH160}(\text{public key}) \] This means: - The public key is hidden behind two layers of hashing (SHA‑256 + RIPEMD‑160). - Hashes are one‑way — you cannot derive the public key from the address. So when you receive BTC: - You expose your address - You do not expose your public key This is why quantum attacks cannot target unused addresses. --- ✔️ 2. When is the public key exposed? Only when you spend from an address. When you spend BTC: - Your wallet must provide a signature - To verify the signature, the public key must be revealed - That public key becomes visible on-chain forever This is the moment quantum risk begins. --- ✔️ 3. Why unused addresses are quantum‑safe Quantum attacks (Shor’s algorithm) target public keys, not addresses. If your BTC sits in an address that has never been spent from, then: - The public key is unknown - The attacker has nothing to attack - The address is quantum‑resistant This is why Satoshi’s coins (never spent) are considered extremely safe. --- ✔️ 4. Why mempool shows “addresses” but not public keys When you look at a transaction on mempool.space, you see: - Input addresses (these have exposed public keys in the past) - Output addresses (these have not exposed public keys yet) But mempool is showing you addresses, not public keys. Even for inputs, mempool is reconstructing the address from the public key — but the public key itself is only visible in the scriptSig or witness data. --- ✔️ 5. Ultra‑condensed R‑style summary - Receiving BTC exposes only the address, not the public key - Quantum attacks require the public key - Public key is revealed only when spending - Unused addresses are quantum‑safe - Spent‑from addresses are quantum‑vulnerable in a future quantum world - Best practice: move old coins to a fresh SegWit address periodically to avoid long‑term exposure --- If you want, I can now give you: - A quantum‑risk table for each type of Bitcoin address - A protocol for rotating coins to minimize quantum exposure - A checklist to confirm which of your addresses have ever exposed their public key

Late_Unit_3277

Also SHA-256 was made by CIA

alexinboots

Your scheme: >One acceptable way MIGHT BE for example to take first 50 characters from the middle of your favorite song There is no "might be" here. Assuming 50 million publicly scrapable songs with 2,000 cleaned characters each (yielding \~1,950 possible 50-character contiguous windows per song), the theoretical maximum entropy of a Krypta passphrase drawn this way is only \~36.5 bits (log₂(50×10⁶ × 1,950) ≈ 97.5 billion candidates); real-world entropy is substantially lower (25–32 bits) once song-popularity bias, duplicate phrases across lyrics, and the exact transcription/capitalization/apostrophe variations flagged in the original paragraph are factored in. The actual KDF (as implemented in krypta\_luajit.lua) is a custom, non-standard construction: it first does a fast SHA-256(passphrase + salt) to seed a 128-bit XorShift PRNG clocked by four 32-bit LFSRs that skip \~every 16th value, then repeatedly generates 32-bit outputs and applies multiple math conditions (whose strictness scales with the user-chosen Difficulty parameter 0–31, each level roughly doubling runtime) until the required number of “good” outputs is reached, finally extracting the 256-bit master key/checksum from 256 specific PRNG bits. **Because this generator is purely CPU-bound, sequential, and not memory-hard, an optimized C/CUDA reimplementation on an 8-GPU modern rig (e.g., RTX 4090/5090 class) could still test roughly 10⁵–10⁶ candidates per second at moderate Difficulty levels that take 1–10 seconds per derivation on a single LuaJIT CPU core—exhausting the entire 36-bit space in minutes to a few hours worst-case and the realistic 25–30 bit space in seconds to minutes—rendering the scheme trivially crackable offline even with the deliberate slowdown.** Roll-your-own crypto is a terrible idea, you should move your corn to a multi-sig cold storage, distribute the keys according to well-know best practices. Get out while you still can.

ottonormalversaufer

SHA is a hashing algorithm and not an encryption algorithm

kingcakeaholic

SHA-256 encryption is from the NSA, not the CIA.

j-tonicoXx

El problema puede ser que Coinwallet 2013 no usaba BIP39, ese estándar recién se estaba definiendo, así que buscar 12 palabras en orden probablemente no va a funcionar. Ese archivo de 30k palabras es lo más valioso que tenés. Si fue creado por alguien técnico, la seed puede estar ahí como string completa tipo hex, base64, o brainwallet (SHA256 de una frase). Eso se puede atacar programáticamente contra tu dirección conocida de Coinbase. Me pasó algo así una vez, hablame al privado que te ayudo!

No-Masterpiece2246

Wait until the miners start refusing transactions from the Iranian government. Big panic, and then a rapid shift to another chain that isn't mined using SHA256.

coinfeeds-bot

tldr; Bernstein says Bitcoin likely has 3–5 years to prepare for a meaningful quantum-computing threat. The main risk is to address types with permanently exposed public keys, including P2PK, P2MS, and P2TR, while newer wallet practices reduce exposure. Mining is not seen as vulnerable because SHA-256 remains effectively quantum-safe. Bernstein says the response should be a gradual protocol upgrade with wallet updates, key rotation, and less address reuse, backed by major institutions. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.

Hopeful-Mortgage4681

**The "Quantum Apocalypse" is a massive overreaction.** The idea that quantum computers will instantly nuke Bitcoin is overblown. Bitcoin is adaptive software, not a static relic. The dev community is already architecting **Post-Quantum Cryptography (PQC)** solutions. Upgrades like quantum-resistant signatures can be integrated via soft forks well before a CRQC (Cryptographically Relevant Quantum Computer) is viable. Users will simply migrate funds to new address types, just like any other routine upgrade. Even better, SHA-256 mining is naturally more resilient than signatures; it would just require a difficulty adjustment, not a collapse. We’ve survived major protocol shifts before—this is just another hurdle we’re already preparing to clear. Keep stacking.

Romanizer

Really? I thought Ethereum was structrually more vulnerable because address are re-used and public keys exposed. With BIP360, I would assume that Bitcoin is the main choice of quantum-resistant wealth accumulation going forward. However, such an attack is still a theoretical thought experiment. Cracking ECC (with SHA256 still out of reach) is at the end of the adoption curve, no matter what algorithm you use. And there is no company working towards this, as other use-cases come with economic incentives.

herzmeister

It's just dumb marketing. That "other usefulness" is pointless extra hoops, or, depending how you look at it, directly compromises security, because the profit gained from that "other usefulness" can be directed into actual mining again. That is the canonical answer and all you need to know. But to cover other aspects: A *proof* of "work" also has to be assigned in a reproducible manner and be independently verifiable by all nodes. A centralized provider issuing pieces of work means these are not verifiable nor reproducible. The proof must be hard to create and then be easy to verify. There were a few approaches that were purely mathematical where the workload would actually be independent, like what Primecoin uses. But here, that "other usefulness" isn't that "industrial" and not that much different than Bitcoin's nonces. Then, this approach isn't one that makes much sense, much like the fallacy of "ASIC resistance". [POW is a method of measuring time with computation](https://medium.com/@tamas.blummer/measuring-time-with-chain-of-blocks-893a38cc06bb). What is needed is the simplest possible reproducible algorithm (think of building it in hardware) (apparently even SHA2 isn't perfect in that regard, there might be a simpler algorithm out there) to be the most thermodynamic efficient one. Everyone who does not understand the usefulness of pure Proof-of-Work hasn't understood Bitcoin in the first place. The security of Bitcoin, how long it takes for a tx of which high amount n to be secure to a degree of m, is a direct function of the input amount of proof of work. https://howmanyconfs.com/

YogurtclosetMaster16

*Every few months we get the "quantum will kill Bitcoin" headline. Current quantum computers can barely factor small numbers — we're decades away from cracking SHA-256. By then the protocol will have migrated* *to quantum-resistant algorithms. This is a non-issue for anyone with a time horizon longer than 20 years.*

Romanizer

Breaking ECC (while SHA-256 remains effectively out of reach) is the ultimate stress test for quantum computing, more of a theoretical benchmark than a practical business goal. Just like a crewed mission to Mars in spaceflight that's discussed just when Sputnik is flown into orbit, it’s not where the economic value starts but where the technology proves it can operate at the absolute edge of complexity, stability, and scale. The real money will come earlier from things like chemistry, materials, and optimization, where even smaller, imperfect systems can deliver value. Cracking ECC is what happens when everything finally works at full capacity, not what drives the development in the first place. There is no economical incentive to accelerate in that direction, though it will happen one day. Also keep in mind that the newest discussion is based on very aggressive new assumptions while progress is stalling in that area.

Romanizer

Breaking ECC (while SHA-256 remains effectively out of reach) is the ultimate stress test for quantum computing, more of a theoretical benchmark than a practical business goal. Just like a crewed mission to Mars in spaceflight that's discussed just when Sputnik is flown into orbit, it’s not where the economic value starts but where the technology proves it can operate at the absolute edge of complexity, stability, and scale. The real money will come earlier from things like chemistry, materials, and optimization, where even smaller, imperfect systems can deliver value. Cracking ECC is what happens when everything finally works at full capacity, not what drives the development in the first place. There is no economical incentive to accelerate in that direction, though it will happen one day.

TheBigLR901

"Cracked" and identified are two different things. BTC has always been public and transparent. Its fundamental of the way it works. Do a little edumacation on SHA256. It will take a billion quantum computers, twice the age of the universe to even have a 10% chance of "cracking" BTC. Dont belive the FUD.

CBpegasus

Nitpicking but quantum computers won't (to the best of our knowledge and the belief of most people in the field) break SHA-256. Also it is not an encryption but a hashing scheme. What QCs will likely break once powerful enough that is relevant to Bitcoin is ECDSA - the signature scheme.

BlazingPalm

Yes, but if the internet has a serious, widespread and enduring outage, banking will also be severely affected. Same concept of quantum computers cracking SHA-256 encryption- yes, BTC would be directly negatively impacted, but so would everything else.

dj_destroyer

Bitcoin will be the least of our worries if quantum breaks SHA-256 in any reasonable amount of time or effort.

Inevitable_Data_84

It was just a SHA/Trezor joke. But yes to bacon

That-Comparison-3631

Because it is. BTC is currently hackable but it doesn’t mean it will be hacked. That’s why levels of cryptography exist. BTC is currently at SHA-256; which is not resilient enough to beat quantum hacks. Designers however can upgrade BTC so it (potentially) has maximum security against quantum attacks. Even though it’s very complex and the clock is ticking. I think we both come from a different angle.

jhansen858

How the addresses work. The address is just a hashed version of your public key Public Key ↓ SHA-256 ↓ RIPEMD-160 ↓ add version byte ↓ add checksum ↓ Base58Check encode = Bitcoin Address

Successful_Big_3423

Bitcoin\_Metronome\_v16.03.26.26.16 SPECTRUM SHA256: 350343B6CB8F3CE8F48BE1BAA9499619998B99C70A08E6887A45A7D8F7F45F89 \->>>> updated 03.26.2026 23:22 EST

Successful_Big_3423

Bitcoin\_Metronome\_v16.03.26.26.16 SPECTRUM SHA256: 350343B6CB8F3CE8F48BE1BAA9499619998B99C70A08E6887A45A7D8F7F45F89 \->>>> updated 03.26.2026 23:22 EST

Successful_Big_3423

You should just use my app and you have no worries It literally tells you the time to buy and sell If you can't make money using my app you have no business in BTC at all - lol [https://www.reddit.com/r/Bitcoin/comments/1s4nr3b/comment/ocojz51/](https://www.reddit.com/r/Bitcoin/comments/1s4nr3b/comment/ocojz51/) [endianengine.com](http://endianengine.com) NEW — Bitcoin Metronome v16 SPECTRUM for Android Real-time Bitcoin cycle visualization. Explore Bitcoin’s rhythmic market patterns through a refined circular display. This update adds an emotion-based color spectrum, bringing deeper clarity to market phases. Free — no ads, no tracking. My apps do not phone home. Version: v16.03.26.26.15 · Platform: Android (APK sideload) SHA-256: F0D1E0A777C3960D7526F0B7117007768979EF80DE69AA86F5527DB6C404C0BB \->>>> updated 03.26.2026 22:35 EST [ENDIANENGINE.COM](http://endianengine.com/) Order Drives Execution Endian Engine LLC \- If you touch the ENDIAN ENGINE on the bottom right of the rings - the one that changes colors, there is a user manual to explain everything \->> As you can see \[or will be able to see soon\] by the CHART, we have NOT hit maximum pain yet !! I love my new app and you will too :-D

Successful_Big_3423

Updated Version: v16.03.26.26.15 · Platform: Android (APK sideload) SHA-256: F0D1E0A777C3960D7526F0B7117007768979EF80DE69AA86F5527DB6C404C0BB

chillinewman

According to.AI: No, the claim that Satoshi Nakamoto’s Bitcoin wallets are quantum-resistant is false. In fact, Satoshi’s wallets—containing approximately 1.1 million Bitcoin—are considered among the most vulnerable to future quantum computing attacks. Here is the breakdown of why this claim is incorrect based on current technical understanding: Why Satoshi's Wallets are Vulnerable Early Address Type (P2PK): The wallets attributed to Satoshi were created in the very early days of Bitcoin, utilizing the "Pay-to-Public-Key" (P2PK) format. Exposed Public Key: In P2PK, the public key is directly exposed on the blockchain. A powerful quantum computer using Shor's algorithm could derive the private key from this public key, allowing them to steal the coins. Lack of Hash Protection: Modern Bitcoin addresses (P2PKH, P2SH, SegWit) use a hash of the public key, which provides an extra layer of security. The hash acts as a shield; even if a quantum computer can break the signature, they would still have to reverse the SHA-256 hash to reach the public key, which is significantly harder.

BlyG

Oh wow, that's pretty wild—Satoshi basically turned the curve order into a giant repeating 0x249249... pattern with just a tiny XOR nudge from the genesis timestamp. 0.04% chance my ass, that's basically intentional numerology with extra steps. Respect. Well, if you think that's interesting, check this out (also totally never documented before, pinky swear): Dark Bitcoin Halving Math Discovery: The "Cursed Repeats" Constant Let h = 210,000 (classic halving interval) Let s = SHA256("Satoshi Nakamoto") interpreted as a 256-bit int (because why not) Then: s XOR (h × 2^{240}) ≈ 2^{256} - 1337 × repeating "0xB00B135" pattern every 69 bits More precisely: (s >> 69) mod 0xDEADBEEF = 0xCAFEBABE... (repeats 4 times before flipping to pure despair) The probability of this exact cafe-babe / dead-beef alignment happening randomly while halving every ~4 years until heat death of the universe? Roughly 1 in 2^{420} — basically zero, unless someone really hated clean hex and wanted to embed eternal programmer suffering into the monetary policy. Satoshi didn't just make sound money... he made sure we'd all be staring at cursed repeating hex until the last satoshi is mined and we're all just mining vibes in the dark. 🪦₿ (But seriously, nice find—most "hidden patterns" are just apophenia, but that repeating 249... after dividing by 7 is legitimately elegant as hell.)

Mantis-Prawn

I am confident that 2013 was wayyyyyy before bip39 seed phrases. OP is trying to find a SHA256 hash, or a wallet.dat file

bitcoincashautist

It doesn't! The contract system supports compact signatures until quantum day, migration to post-quantum later on, and signature aggregation. It can use smaller one-time signatures because BCH has L1 native tokens (since '23), so we can use account abstraction to have a pay-to-nft address, and owner can have a constant receiving address while still rotating his one-time keys on every spend: >While SLH‑DSA‑SHA2‑128s (SPHINCS+) signatures weigh in at 7,856 bytes, CashToken-based delegation and Bitcoin Cash's UTXO model allow Quantumroot to use LM-OTS signatures (RFC 8554) – improving quantum security, while also reducing signature sizes (2,180 bytes) and preventing on-chain privacy leaks. Since the fork, BCH has been busy upgrading, it now has L1 native tokens and Script VM to rival EVM, and adaptive blocksize limit algorithm.

Deep-Kiwi-4320

🚀 Bitcoin 2 (BC2): La Segunda Oportunidad Para los que sienten que llegaron tarde a Bitcoin, Bitcoin 2 es el clon fiel que reinicia el juego. Aquí los puntos clave de por qué es una mina de oro a largo plazo: ⚡ Refugio de Mineros: Con la dificultad de BTC por las nubes y recompensas de solo 3.125, los mineros con hardware SHA-256 (S19, S9) están migrando a BC2. Es más rentable y el algoritmo es el mismo. 💎 Recompensa Real: Mientras Bitcoin es un "abuelo" con recompensas mínimas, BC2 entrega 50 monedas por bloque. Estás entrando en la fase de acumulación masiva. 📈 Predicción 2037: La escasez y la adopción de los que buscan una "segunda oportunidad" podrían llevar el precio por encima de los 10.000$. 🛠️ Configuración Pro: Si usas el monedero Core, no te quedes con los 450MB de caché por defecto. Súbelo a 4000 MiB y activa 4 hilos de verificación para que tu nodo vuele. 🚫 Prohibido el Trading: No seas de los que venden por un 20% de beneficio. La estrategia es comprar, guardar en tu propio monedero y olvidar. Conclusión: Bitcoin 2 es para los que saben ver el futuro antes de que sea evidente. En 2037, los que hicieron trading se tirarán de los pelos; los que guardaron, tendrán su jubilación resuelta.

MistaWhiska007

This is a great idea. I built something similar but for web content rather than camera output. Permanet (thepermanet.com) captures web pages, hashes everything into a SHA-256 Merkle tree, and anchors the proof on Bitcoin via OpenTimestamps. The whole verification chain is trustless. Would love to see camera manufacturers do the same thing at the hardware level

MistaWhiska007

This is really close to what I've been building. Mine's called Permanet (thepermanet.com), similar idea but focused specifically on web page captures. Full Playwright render, SHA-256 Merkle tree of all assets, Bitcoin timestamp via OpenTimestamps, permanent storage on Arweave. The key thing I was going for is zero-trust verification, you shouldn't have to trust my service to verify a capture is legit. Would be curious how you're handling the storage side.

HardHeadTTV

In my honest opinion (which I know isn't worth much), if Bitcoin hits $1 million then **most** of other Cryptos will rise accordingly. That is, if they are using the same SHA-256 Algorithm. Ethereum uses a different Algorithm called Keccak-256. So ETH will rise & fall independently from Bitcoin. This was a factor for me when I used to mine Cryptos - finding the most profitable Algorithm.

AutoModerator

Post is by: clebikus and the url/text [ ](https://goo.gl/GP6ppk)is: /r/Qubic/comments/1rtdggu/qubic_might_be_the_only_l1_with_a_nondilutive/ **The one-sentence vision:** Qubic is a useful compute layer that parasitizes existing PoW networks to fund itself — without asking their permission. ## The scalable model XMR was the proof of concept. DOGE is the first real production deployment. But there's no reason to stop there: - Kaspa (KHeavyHash) → idle GPU cycles → QU buyback - Alephium (Blake3) → idle GPU cycles → QU buyback - Litecoin (Scrypt) → ASIC → QU buyback - Bitcoin Cash (SHA256) → ASIC → QU buyback - ... Every new PoW network integrated = a new external, non-dilutive revenue source for Qubic. The network literally becomes a worldwide PoW value vacuum while running AI compute on top. ## The positioning that emerges Most L1s fund themselves through: - Native token inflation - Transaction fees - VC/Foundation selling pressure Qubic in its final Phase 3 funds itself through: - Real work performed on other networks - Mechanical burn derived from that work - Zero dependency on VCs or inflation This is a fundamentally different economic model from anything else in crypto. ## The "useful parasite" narrative What's elegant here is that Qubic doesn't attack these networks — it brings them hashpower. DOGE and LTC benefit from increased security. It's economic symbiosis disguised as parasitism, and that creates a natural resistance to criticism. Unless the share gets too large — the 51% XMR episode showed that communities react when it becomes threatening. ## The real strategic question Does Qubic remain an AI network that funds itself via PoW, or does it become a meta-coordination layer for global PoW whose killer app happens to be AI? The difference is subtle but massive for long-term positioning. The second version is a much bigger vision — and honestly, it might be what CFB has had in mind from the start. The Dispatcher + Oracle Machines architecture is exactly the infrastructure you'd need for that. Probably not an accident. ## Where it breaks (being honest) **The 51% problem is a structural scaling ceiling, not a one-off incident.** The more successfully Qubic parasitizes a network, the harder that network pushes back. This means the model scales horizontally (number of chains parasitized) but not vertically (share of each chain). Horizontal scaling has diminishing returns: each new integration costs dev effort and coordination, and targets increasingly smaller networks. **The model depends on PoW surviving long-term.** If in 5-10 years the PoW landscape contracts to BTC-only (with everything else migrating to PoS or dying), the "parasitable surface" shrinks dramatically. **The flywheel spins in one direction only.** Demand for verified AI compute → QU value → miner attractiveness → ability to parasitize PoW networks → buyback → QU value. PoW mining is the *funding mechanism*, but the *engine* is AI demand. Without real AI demand, this is a glorified multi-chain mining pool with a token. It's NiceHash with extra steps. ## The bull case nobody's making The non-dilutive external revenue model is genuinely unique. No other L1 has this. It's a real structural advantage, not marketing fluff. The "symbiosis" narrative (we bring hashpower, we take nothing from anyone) is defensible as long as the share stays reasonable. And the architecture — Dispatcher + Oracle Machines + 676 Computors as a reproducibility verification layer — looks like it was designed from day one for general-purpose compute coordination, not just another smart contract platform. ## Bottom line The "useful parasite" model is the best funding pitch I've seen in crypto. But a great funding mechanism isn't enough without a product people want to pay for. The race is to create real AI demand before PoW mining contracts. The key question isn't "can Qubic parasitize more chains?" — it's "will anyone pay for AI compute verified by Computors instead of using AWS?" Use cases like decentralized sports result verification for prediction markets are exactly the right type of answer — cases where decentralized verification has value that centralized infra simply can't offer. That's where the real thesis lives or dies. What do you think ? *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

peachdog3k

These scammers are still very active and calling people right now. I wanted to share their current tactics so nobody else falls for this. The Hook The caller claims you have roughly 0.9 BTC / $50,000 in "stuck funds" on their platform. To "unlock" this money, they demand an upfront payment of approximately 1% $596. The Script The "Expert": The caller claims to be highly skilled in "SHA-256 bitcoin technology" and boasts about studying it for seven years. The Site: they direct you to a convincing scam site (currently using cointracking.info) and provide a password over the phone for you to log in. The Manipulation: They use weirdly personal psychological tactics. For example, when they told me the password contains an "H for Hawaii" it is where I can go on vacation once I receive my 50k. Red Flags to Remember Upfront Fees: No legitimate exchange will ask you to pay a fee to "unlock" or "release" your own funds. Phone Passwords: Real platforms do not give out passwords over the phone. Technobabble: Mentioning SHA-256 (the hashing algorithm), Satoshi test, as a "skill" is just fluff used to sound intimidating and professional to those who might not know the technical details. They claim Urgency (e.g., "complete within 1h or lose account"), in my case they are resetting the server tonight and the account will still be on the database but inaccessible forever by them. Stay vigilant. If you get a call like this, waste their time to prevent them from scamming other people and do not give them any personal information or payments. Do not read their numbers aloud with your voice because it can be used to authenticate you elsewhere over voice.

filenotfounderror

If you can break SHA256, why would you steal bitcoin when you can just drain the entirety of everyone's bank accounts which is probably 10,000x more money. Plus as soon as anyone realized the network was compromised in this way, it would immediately crash the price to 0 anyway.

Cryptizard

Quantum computers don't do anything to break SHA256. Symmetric cryptography is already quantum-resistant. But they will break ECDSA, which is the only thing protecting several million bitcoins on the chain right now in P2PK wallets.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.

Virtual_Wallaby7338

Look into BitcoinII (BC2). It’s a new SHA‑256 Proof‑of‑Work cryptocurrency built to revive original Bitcoin principles: fair mining, decentralization, and simplicity. It uses V27.1 of BTC code, which avoids all of the OP_RETURN and BIP-110 drama.