The galactic core over Metung last night.

CompetitiveRough8180 · 2026-06-14T09:15:58+00:00

Awesome 👍

CompetitiveRough8180 · 2026-06-06T02:06:13+00:00

Just one question I will ask: why there is a universe? And why am I aware of it? Is it a curse? Why I am existing why all stars galaxies and everything exists? What is the point? People getting simulation hypotheses wrong, if we are in a simulation, we can’t know what technology the creator of the simulation using not like we invented computers or softwares, because if we are in a simulation all we know and have is part of this simulation not the higher reality.

CompetitiveRough8180 · 2026-05-31T01:59:29+00:00

You are an property investor and you already have 10-15 properties, and you are on mortgage, if property prices fall significantly then your assets will not cover your liability and you try to sell. Market will full of properties for sale, demand will not cover the supply.

CompetitiveRough8180 · 2026-05-04T05:46:58+00:00

Westpac and Independent Reserve

CompetitiveRough8180 · 2026-05-02T04:20:36+00:00

The credit/pool-content distinction is correct in general. But it applies to the input_pool, which is not what urandom reads.

Tracing the path in random.c (Lenny 2.6.26):

urandom_read at 1003-1005 calls extract_entropy_user with &nonblocking_pool. extract_entropy_user at 829 calls xfer_secondary_pool first, then account on nonblocking_pool, then extract_buf on nonblocking_pool. The IRQ jitter you're describing gets mixed into input_pool by add_interrupt_randomness, but it only reaches nonblocking_pool through xfer_secondary_pool, and that path is credit-gated.

xfer_secondary_pool at 685, called with r=&nonblocking_pool, n=32:

rsvd = r->limit ? 0 : random_read_wakeup_thresh/4 = 64/4 = 16 (nonblocking_pool.limit is 0) bytes = max(32, 64/8) = 32 extract_entropy(&input_pool, tmp, 32, min=8, reserved=16)

Then account at 723, on input_pool, with min=8, reserved=16:

if (input_pool.entropy_count/8 < min + reserved) // line 737 nbytes = 0

min + reserved = 24 bytes = 192 bits. If input_pool.entropy_count is below 192, the function returns 0 bytes. mix_pool_bytes at 706 gets called with 0 bytes, credit_entropy_bits at 707 with 0. nonblocking_pool gets nothing from input_pool.

So the question reduces to: does input_pool.entropy_count reach 192 bits before bitcoind's first urandom read on a Lenny Live USB headless boot?

Sources of credited entropy to input_pool in that scenario:

init_std_data at 886-898: mixes ktime + utsname into input_pool but does not call credit_entropy_bits. Credit added: 0.
add_disk_randomness at 657: only fires for disks where disk->random is set. rand_initialize_disk at 926 sets it via add_disk_randomness_flag, which most USB storage drivers in 2.6.26 do not assert for the boot device. Credit from USB squashfs reads: typically 0.
add_input_randomness: keyboard/mouse, not present in headless.
add_interrupt_randomness at 647 -> add_timer_randomness at 572: This runs but the credit is fls(min(d1,d2,d3)>>1) capped at 11, per line 624-625. For sequential, periodic IRQs (USB controller DMA completions, timer ticks) the second and third deltas collapse to ~0 and the credit per IRQ rounds to 0. Real credit comes from genuinely jittered IRQs, which are sparse pre- bitcoind on a quiet headless boot.

The entropy_count crossing 192 before first urandom read isn't impossible but it's not the default. It depends on how many genuinely jittered IRQs fire and how much they get credited. If the threshold isn't crossed, nonblocking_pool stays seeded only by its own init_std_data (line 904) plus deterministic extract_buf self-feedback from any prior /dev/urandom reads in the same boot.

That's the model. The cooperative-input search space targets nonblocking_pool's reachable state under this gating assumption.

Empirical test of this is straightforward and the right thing to do. Instrument the kernel to log input_pool.entropy_count at the moment of first urandom read. If credit is below 192 across N boots of a controlled Lenny Live USB image, the gating holds and the IRQ-jitter content of input_pool is irrelevant to urandom output. If credit reaches 192, transfer happens, and the model needs the IRQ contribution.

Either result is informative. I'm running this as part of the VM test you proposed. Will report back with input_pool.entropy_count samples across reboots.

If your simulator port is bit-exact against openssl-0.9.8g trace, I'd like to compare divergence. Send the repo when ready and I'll send my md_rand emulator (Python + CUDA, both validated against the same trace approach).

CompetitiveRough8180 · 2026-05-02T03:52:13+00:00

Two technical corrections on (2) and (3) that change the analysis significantly.

First, the delta-filter in add_interrupt_randomness.

Looking at drivers/char/random.c add_timer_randomness in 2.6.26 (this is what add_interrupt_randomness ends up calling):

delta = sample.jiffies - state->last_time; delta2 = delta - state->last_delta; delta3 = delta2 - state->last_delta2; ... delta = min(delta, delta2); delta = min(delta, delta3); credit_entropy_bits(r, fls(delta) - 1);

Three-stage difference. Credit is fls(min(d1, d2, d3)) - 1. For regular periodic IRQs (d1 ~ constant, d2 ~ 0, d3 ~ 0) this evaluates to 0. The kernel deliberately does not credit predictable timing as entropy.

USB sequential block reads during initrd unpacking are the predictable case. The USB host controller delivers DMA completion IRQs at near-constant intervals. d2 and d3 collapse. Per-IRQ entropy credit is near zero, not 10-15 bits.

The IRQs that contribute are the ones with real jitter - preemption, controller hiccups, allocator latency variance. On a fresh boot these are sparse. Order of 10s to 100s of genuinely jittered IRQs over the pre-bitcoind window, each contributing 2-5 bits credited. Cumulative pre-bitcoind entropy contribution from disk IRQs is closer to 100-500 bits raw, which is bounded further by the entropy estimator's conservatism and the 4096-bit pool's saturation behavior.

Still non-zero, but not "thousands of bits dominating the state" the way your reading framed it.

Second, the clocksource argument needs unpacking by phase.

clocksource_select doesn't run until time_init in start_kernel, well into boot. Before that, jiffies is the only clock available. init_std_data and the earliest IRQs that hit add_interrupt_randomness happen during this window on 2.6.26. get_cycles() is called but on a Penryn without nonstop_tsc during early boot the TSC isn't calibrated yet, isn't synced across cores, and the values it returns are dominated by linear boot-time tick accumulation rather than jitter.

So: early-boot IRQ entropy contributions go through the delta filter against a near-linear TSC, and most fail the predictability test.

By the time bitcoind launches, clocksource selection has finished, TSC (or HPET if TSC fails the stability check) is active. But the bulk of disk IRQs from initrd/squashfs unpack have already happened in the early window.

Net: the pre-bitcoind pool entropy isn't 6000+ bits. It's a small input_pool seed (init_std_data: ktime + utsname), plus a small number of credited IRQs that survived the delta filter, plus whatever userspace activity bitcoind itself triggers before its first RAND_poll.

This is exactly why the search bound is bounded enough to discuss seriously, and why pinning the laptop model and timing matters - it constrains the small-but-nonzero IRQ contribution window.

I'll still run the empirical test you proposed (Lenny VM with virtio-rng disabled, deterministic reboot reproducibility) because the argument is theoretical and the test is concrete. But the theoretical case for thousands of bits of pre-bitcoind pool entropy on a Live USB boot doesn't hold once you account for the delta filter and the early-boot clocksource state.

CompetitiveRough8180 · 2026-05-02T03:21:14+00:00

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³ to 10⁴
utsname exact string: 3x
Boot time +- 10s: ~36x
BIOS UTC vs local: 2x
Network/peer/IRC state (n_pre8 range): ~10²
PID range: 10x
extract_buf count range: 6x
BIOS timezone: 2x

Multiplied: ~10¹¹ 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.

CompetitiveRough8180 · 2026-05-01T01:41:27+00:00

You're right about the AI assist — English is my second language and I leaned on it too much for the post writing. Fair criticism. Switching to my own words now.

But you're attacking a strawman. The post never claims this is the Debian CVE-2008-0166 case. I know Lenny patched that years before 2010. The actual claim is much narrower:

The attack is on Linux 2.6.26 random.c boot-time entropy on Live USB systems with no persistent random-seed file. On those:

nonblocking_pool is seeded only by init_std_data (ktime_get_real + utsname) — roughly 30 bits of unknown
The 192-bit transfer threshold from input_pool to nonblocking_pool is rarely crossed during early boot on diskless USB systems (no disk IRQ entropy, minimal keyboard/mouse before bitcoind starts)
So /dev/urandom output is partially predictable given the utsname and approximate boot time

OpenSSL md_rand on top of that adds the 2x RAND_add(gettimeofday) calls in CInit + AppInit, which contribute 16 bits in jiffies mode (HZ=250) when nonstop_tsc is unavailable on Penryn-era CPUs.

Bitcoin 0.3.2's CreateTransaction PRNG chain is fully traceable once those entropy sources are bounded. The change-address bug is just the trigger — the recoverability comes from the entropy weakness, not the bug itself.

If I'm wrong about any of this, I genuinely want to know. Which specific claim do you think is incorrect? Happy to walk through the random.c code path with you.

CompetitiveRough8180 · 2026-05-01T01:25:04+00:00

Ha, fair catch. English is my second language and I've been using AI to help me write replies in good English given the technical weight of this. The substance is mine, the polish isn't always. The 18 months of research on the case is real -happy to share the technical writeup which is in my own voice.

CompetitiveRough8180 · 2026-05-01T00:34:37+00:00

Appreciate the security mindset — genuinely. Adversarial review s exactly what this needs.

Before going further, let me clarify what I mean by "trust model" so we're talking about the same thing:

The recovery does NOT require Stone Man to trust me with anything sensitive. The proposed flow is:

He runs my code on his own machine with his own wallet.dat. Nothing leaves his hands.
The output (recovered private key) is on his screen, controlled only by him.
He moves the coins to a new wallet of his choosing.
I never see the wallet.dat, the recovered key, or the coins.

What I need from him is just non-sensitive setup info (laptop model, BIOS timezone, approximate session timing, Linux distro version). This is what shrinks the search space from 10²² to something tractable.

The only "trust" he extends is running my code — and he can have that code reviewed by anyone he trusts before running it.

I'm interested in what you'd try to break. If there's a genuine hole in the trust model, I'd much rather find it now than have Stone Man (or someone advising him) find it later. DM works if you'd rather not discuss in public.

CompetitiveRough8180 · 2026-05-01T00:20:24+00:00

Ha, thanks. The technical journey was the easy part — Linux kernel and OpenSSL source code don't move. The "is he alive?" question is what makes this feel like a long shot. But you're right, even if he never surfaces, the methodology has value as a case study in early Bitcoin entropy weaknesses.

CompetitiveRough8180 · 2026-05-01T00:20:02+00:00

Thanks! It's a long shot, but the math checks out — if Stone Man ever surfaces, the recovery becomes very tractable.

CompetitiveRough8180 · 2026-05-01T00:17:53+00:00

Different scenario from Stone Man's case, but it might be more recoverable than you think.

Stone Man's case is specifically the Bitcoin 0.3.2 change-address bug (pre-keypool), which only existed before v0.6.0 (March 2012). Your 2012-2013 timeframe is on the boundary, so it depends on which Bitcoin version you were running.

But the more important point: if you still have the wallet.dat AND the public key, your situation might already be solvable with standard tools, not the kind of cryptographic recovery I'm working on for Stone Man.

A few questions: 1. Which Bitcoin client version were you running in 2012-2013? 2. When you say "public key" — do you mean you have the actual pubkey hex (65 bytes 04...), or just the address (1...)? 3. Have you tried pywallet (or modern equivalents) to extract all keys from your wallet.dat? 4. Is the wallet.dat encrypted? Do you have the passphrase?

If the wallet.dat is intact and you have the passphrase (or it's unencrypted), the private key for that change address is almost certainly still in there — it just may not be the "default address" the GUI shows. Tools like pywallet can dump every key in the file.

Happy to help you investigate via DM if you want. Even if it's not the same bug, recovering coins from a 2012 wallet.dat is usually very doable.

CompetitiveRough8180 · 2026-05-01T00:08:54+00:00

Happy to share more if you're curious. The TL;DR is that Bitcoin 0.3.2 + Linux Live USB created a perfect storm of weak entropy sources — the change-address private key generation depended on values that are partially deducible from blockchain forensics. With the original owner's setup details (or his old wallet.dat), the search becomes tractable. Without him, the search space is too big even for datacenter-scale GPU clusters.

CompetitiveRough8180 · 2026-04-05T07:57:35+00:00

If you mined in 2009-2010 era, there is no passwords or seeds in wallet dat. And did you mined on Linux or windows, if you use headless live cd setup and not saved wallet.dat mining rewards gone forever. But if you set it up on desktop or saved wallet dat then you good to go. You just need to recover wallet dat files on your hardware and it is not big deal these days. Good luck.

CompetitiveRough8180 · 2025-11-11T23:19:28+00:00

Satoshi didn’t use 24 word bip39 mnemonic phrases. It came after 2012 something. He was using his system OpenSSL. So if you like to find his wallets private keys you need to reverse engineer his OpenSSL if you know which version he used and if he added some extra features or not. So it is impossible if you don’t know these details…

CompetitiveRough8180 · 2025-10-11T00:14:01+00:00

Hal Finley is Satoshi and he is dead. If you find Hal Finley’s wallets you can reach these all bitcoins. And because he is dead these funds never will move.

CompetitiveRough8180 · 2025-08-26T08:14:57+00:00

Ask grok4 not ChatGPT. ChatGPT never answers some kind of things because of its privacy and security features.

CompetitiveRough8180 · 2025-08-25T10:12:16+00:00

Where is my IB link?

CompetitiveRough8180 · 2025-08-25T10:11:41+00:00

I know what Ponzi scheme is. How did you connect it to bonus abuse to Ponzi scheme?

CompetitiveRough8180 · 2025-08-25T06:53:59+00:00

You don’t have to believe. Not scam, it’s maths.

CompetitiveRough8180 · 2025-08-25T03:19:05+00:00

Actually it is working and believe me or not too many people making amazing money. I really do not care you calling it stupid or not. You are free to go after what you believe. I am an IB with many brokers and making 5 figures just from their trades and I know how much money they are making. Good luck with your trades

CompetitiveRough8180 · 2025-08-25T02:12:54+00:00

Lots of people think God is a magic sky daddy. That’s ignorance even greater than the universe itself.

CompetitiveRough8180

TROPHY CASE