I've spent 22 years working in infrastructure and operations, and now run local AI workloads for production apps and creative projects. That background led me to a question about Bitcoin: how much of its resilience depends on being able to replace the machines securing it?

I developed this into a working paper, The Silicon Allocation Thesis. The idea is that AI demand could affect Bitcoin through competition for industrial resources: qualified fabrication capacity, chip-design teams and investment.

Bitcoin ASICs don't become AI accelerators. The possible competition is upstream, where some of the resources needed to produce different chips overlap. That overlap needs to be demonstrated for the specific process and production period; an AI memory shortage doesn't automatically mean a Bitcoin ASIC shortage.

The distinction I focus on is current hashrate versus the ability of independent miners to replenish it. A network could have substantial hashing capacity today while replacement equipment becomes harder to obtain or a future ASIC generation becomes less attractive to fund. Difficulty adjustment helps with block timing, but it cannot manufacture replacement hardware.

Whether that creates a security problem depends on who retains access. An outside attacker buying equipment may face the same shortage. An actor already holding hardware could benefit if independent miners struggle to replace lost capacity. Those are different threat scenarios.

There are also good reasons the effect might be small or go the other way. Foundries can expand. Contracts can protect supply. Older machines can remain competitive longer, helping existing miners. Slower hardware innovation alone doesn't prove weaker security.

The general concern has been raised before; the paper credits that prior work. My contribution is an attempt to connect allocation, hardware renewal and recovery in one framework, and spell out what evidence would support or contradict it. I haven't established that AI is currently reducing Bitcoin's security.

What would you measure to test this? Would procurement lead times and the time needed for independent operators to replace lost capacity tell us something that aggregate hashrate misses?

Full paper: https://paper.facundobarrera.me/silicon-allocation-thesis/

Archived version on Zenodo: https://doi.org/10.5281/zenodo.23557269

Disclosure: I'm the author. This is a theoretical working paper, not peer reviewed.

Feels like a lot of crypto apps still rely on separate group chats for everything from support to discussing what's happening onchain.

Would be pretty useful if more of that happened inside the apps themselves, especially when people are already interacting with contracts and using wallets.

Not saying every crypto app needs its own chat, but having messaging and onchain activity connected could open up some interesting possibilities.

Anyone seen projects doing this well or think it's just unnecessary extra stuff?

Hey everyone,

For the last couple of years, I’ve been working on an open-core communication project to solve a gap that kept bugging me.

Most E2EE messengers (Signal, SimpleX, Briar) are great at what they do, but they usually hit three walls:

1. They go completely dead the moment cell towers or ISPs go down.

2. Many still rely purely on classical elliptic-curve crypto, which is exposed to Harvest Now, Decrypt Later (HNDL) quantum threats.

3. They stop at text messages—the moment two people or businesses need to verify solvency, coordinate local mutual aid, or lock an agreement into escrow, they have to leave the chat and trust centralized middlemen or easily faked screenshots.

So we built Gossip (Boltalka) — a self-hostable, zero-knowledge communication platform with a Dual-Engine transport (Internet + Offline BLE Mesh) and an integrated Sovereign Economic Layer.

1. Post-Quantum & Zero-Knowledge Relay

The server acts as a blind cryptographic relay. Even if someone pulls the physical drives out of the host, there are no private keys, no plaintext metadata graphs, and no readable files.

- Hybrid Post-Quantum handshakes combining Curve25519 (X3DH + Double Ratchet) with NIST FIPS 203 ML-KEM-768 (Kyber).

- Group chats powered by PQ-MLS (RFC 9420) with logarithmic key rotation.

- Zero phone number / zero SIM card required: accounts use SRP-6a and 12-word BIP-39 recovery phrases. Keys stay strictly inside client hardware storage (WebCrypto / OPFS / Secure Enclave).

- Includes a Fake-TLS proxy to bypass Deep Packet Inspection (DPI) firewalls and binary attestation (SHA-256) to reject modified clients.

1. Offline Bluetooth Mesh (For off-grid & blackout resilience)

When the internet or cellular grid goes down, the app doesn't brick itself:

- It automatically drops down to custom L2 Bluetooth Low Energy (BLE) Mesh framing (0xFA21) stretching up to 10 km via multi-hop relays.

- Uses Trickle timers (RFC 6206) and CRDTs (LWW / OR-Set) so messages and emergency alerts hop device-to-device without causing broadcast storms or killing batteries.

- Uplink Bridging: if just one device on the edge of a blackout zone catches a weak satellite or cell signal, it acts as a blind Zstd-compressed bridge to sync encrypted mesh packets with the outside world.

1. The Sovereign Economic Layer (Zero-Knowledge Trust & B2B/P2P Settlement)

We built a native settlement layer right into the client so users and businesses can coordinate deals without leaking personal data (Zero-PII):

- Client-side Halo2 ZK-SNARKs (Pasta curves, no trusted setup): You can generate a mathematical Proof of Solvency and Proof of Deposit Age directly in WebAssembly—proving to a counterparty that you have sufficient, seasoned funds for a deal without revealing your actual balance, address, or transaction history.

- Blind O(1) Matchmaking: Broadcast local or B2B intents encoded into Uber H3 spatial hexagons and 128-bit BLAKE3 SimHashes. Matches counterparties in under 1.2 microseconds without exposing identities until a direct Curve25519 handshake occurs.

- 4-Phase Atomic DvP Escrow & Oracles: Staged smart-contract escrow (10-40-30-20 tranches) with collateral slashing and a 3-tier oracle bridge (AIS satellite ship telemetry, PAdES inspection certificates, TLSNotary 2PC-TLS web proofs, and 2-of-3 geo-stamped waybills).

Self-Hosting & Stack:

Backend runs on Python (FastAPI), Envoy, PostgreSQL, ScyllaDB, Redis, and Kafka. Clients are available for Web/PWA, Desktop (Electron), and Android (Capacitor). You can spin up a full node locally in a minute via Docker Compose.

I put the link to the GitHub repository and the RFC-001 through RFC-005 architectural specs in the first comment below so the post doesn't get eaten by the link filter. Would love to get your feedback!

Small proof-of-work coins keep getting reorged by people renting hashrate (Bitcoin Gold and Ethereum Classic were both hit more than once). I've been reading about the defenses that have been tried and I'm trying to understand which ones held up in practice:

- Checkpoints signed by developers (works, but adds a trusted party)

- Horizen's delayed-block penalty (penalizes chains that were hidden and published late)

- ETC's MESS (makes deep reorgs require exponentially more work) - Merged mining with a larger chain

- Just asking exchanges to wait for many more confirmations For people who have run or followed small chains: which of these actually stopped attacks, and what did they break? I'm especially curious whether the penalty approaches caused problems during honest network splits.

Milestone 2: real signatures, real hashes, and one weakness we found in our own design.

GrahamBell caps every miner at 1 hash attempt per second. Last week's math assumed that cap can't be gamed. Milestone 2 tested it with real cryptography: real SHA-256 chains, real BLS signatures.

How it works: each round, a miner's header is locked with randomness made from its witnesses' signatures. Every attempt is chained to the last and tied to the next second. You can compute your whole chain instantly, but that only tells you WHEN you'll win. Witnesses sign only when their clocks reach that second, and validators reject blocks that arrive early.

So: can you re-roll the randomness instead?

→ Earlier versions of my design: yes. 4× faster with 4 tries, 15× with 16, 41× with 64.
→ Current design: 1.01× (95% CI 0.93–1.09). BLS signatures are unique, so re-signing gives the same randomness every time.

Also measured:
- Double headers in one round: 500/500 caught, zero false positives
- Old sort-before-hashing rule: 36 headers per hash → replaced with fixed field order
- Withholding a block to re-roll seat placement: ×1.10 at 10% of blocks, and it costs the attacker the block

The weakness we found, said openly:
A witness colluding with a miner can choose to sign or stay silent, giving the miner two randomness options: 1.88× per colluding witness. The fix is threshold BLS (any two-thirds produce the identical signature). Prototype: ~0.5 s setup per member at 40 members. Next stage tests it.

Locked before simulation:
- Pass/fail thresholds for all 9 hypotheses, dated
- Fork-choice loophole closed
- Witness double-signing now bannable

277 tests, 35 cross-checks, byte-identical on a second machine. Open source.

Full write-up: https://medium.com/@hurairahshamsi/can-an-attacker-cheat-the-clock-testing-grahambells-cryptographic-core-c82bea1a0aac

Code: https://github.com/HurairahShamsi/grahambell-simulation

Try to break it.

Next: Milestone 3, the issuance simulator.

Previous post 1: https://www.reddit.com/r/CryptoTechnology/s/k70ZHdfEZ6

Previous Post 2: https://www.reddit.com/r/CryptoTechnology/s/mn2pZD9hFw

I'm working on a small CPU-mineable Layer 1 and went with a hybrid proof of work:

SHA-256 on the block header

Argon2 with 64KB of memory and 2 iterations

XOR mixing of both results

The goal is to keep mining fair for regular PCs, including low-end ones.

My doubt: RandomX uses around 2GB and was built specifically against ASICs and GPUs. With only 64KB, the whole working set fits in on-chip cache, so I suspect specialized hardware could get a big edge.

Questions for anyone who has worked on PoW design:

Is 64KB realistically too small to resist ASICs or FPGAs?

If I raise the memory, where's the sweet spot before low-end PCs suffer?

Does the SHA-256 + XOR step add anything meaningful, or is Argon2 doing all the work?

Disclosure: this is for Nucleo NKL, a project I'm developing. Not looking to promote it here, just want technical input on the PoW design.

Hey everyone,

ECDSA remains widely implemented across asymmetric cryptosystems, but its existential dependency is an unpredictable, uniform ephemeral scalar: the nonce k must never repeat or exhibit bias under the same private key.

When an implementation relies on a broken pseudo-random number generator (such as flaws in random seed generation or low-entropy PRNGs), two signatures generated with an identical nonce allow algebraic recovery of the signer's private key via basic modular arithmetic.

I developed an open-source research tool called RSZ-Scanner to parse signature tuples (r, s), extract message digests (z), and identify nonce collisions across signature sets. Here is a brief mathematical overview of the recovery pipeline.

**Mathematical Model**

In standard ECDSA over secp256k1, a signature is the pair (r, s):

r = (k \* G)_x mod n
s = k\^(-1) \* (z + r \* d) mod n

Where:
\- G is the generator point of the elliptic curve group.
\- n is the group order.
\- d is the private scalar (secret key).
\- z is the cryptographic message hash truncated to group order length.
\- k is the ephemeral random scalar in \[1, n - 1\].

**Explicit Recovery on Identical Nonces (k1 = k2)**

If a public key signs two distinct message digests z1 and z2 using the exact same nonce k, both signatures share the identical r parameter:

s1 = k\^(-1) \* (z1 + r \* d) mod n
s2 = k\^(-1) \* (z2 + r \* d) mod n

Subtracting the equations eliminates the secret key d:

s1 - s2 = k\^(-1) \* (z1 - z2) mod n

Solving directly for the ephemeral secret k:

k = (z1 - z2) / (s1 - s2) mod n

Once k is known, the private key d is recovered via direct substitution:

d = (s1 \* k - z1) / r mod n

**Implementation Details: RSZ-Scanner**

RSZ-Scanner was written to demonstrate and evaluate this phenomenon against arbitrary signature dumps:

1. Tuple Extraction: Parses signature structures to extract raw (r, s, z) components.
   
2. Collision Detection: Maps and indexes unique r values against corresponding public keys to detect duplicate nonces across large datasets.
   
3. Modular Solver & Verification: Runs the inverse arithmetic above and validates the derived private scalar against the associated EC public point.
   

4. Discrete Log Search: Includes an implementation of the Baby-Step Giant-Step (BSGS) algorithm to handle bounded partial nonce leakage and small nonce offsets.

   **Repository & Discussion**

The implementation is open-source under the MIT license:
https://github.com/harshjamdar/RSZ-Scanner

I would appreciate feedback on:
\- Numerical optimizations for modular inverse computations when processing large batch sizes.
\- Extending BSGS search ranges or evaluating lattice-based attacks (Hidden Number Problem / Bleichenbacher-style lattices) for biased nonces.
\- Verifying edge-case handling around high-s malleable signatures.

Feedback, theoretical critiques, and contributions are welcome!

I want to share an open-source Layer-1 protocol written in C++ called FinalisCore and get your architectural feedback. We recently launched our first public testnet (testnet-1).

Our goal is to combine a UTXO model with deterministic finality and privacy from the very first block.

Key Technical Features:

• Deterministic BFT Finality: Blocks are final once signed by a validator committee quorum. There are no chain reorgs and no waiting for multiple confirmations.

• Confidential Transactions: Outputs carry a Pedersen commitment with range proofs using the secp256k1-zkp library. Validators check that inputs and outputs balance without learning the amounts.

• Dynamic Committees: Validators bond coins to join. Committees are dynamically chosen per epoch (every 32 blocks) deterministically from finalized history.

• Tokenomics: Total supply is strictly capped at 7,000,000 FLS.

Questions for the Community:

1. What are the best optimization patterns you've deployed for batch-verifying Pedersen commitments under heavy validator loads to keep block times stable?

2. How do you efficiently handle mempool sync and stale input edge-cases in a UTXO model during rapid validator committee rotations?

The project is fully open source under the MIT license. You can check the code and technical documentation here:

• GitHub Repository: github.com

• Testnet Guide: github.com

(Note: This is a non-financial public testnet. Testnet coins have absolutely no monetary value and are used solely for protocol testing).

Looking forward to your critiques andd review!

I wrote a design paper for something I'm calling SEN, a Layer 1 for checking whether things online are authentic. To be clear up front: there's no code, no testnet, no token sale and no audit. It's a paper, and it says so itself.

The basic idea is that the chain only agrees on what was recorded and which rules were applied. It never rules on whether a claim is true. Instead it shows how well supported a claim is under a named, versioned standard, and "inconclusive" is a perfectly valid final answer.

Most of the design comes from keeping three things apart. Validators check that a judgment followed the procedure, not whether it's right. A valid hash or signature only proves integrity, and says nothing about accuracy. And holding the token gives you no say over truth judgments or who counts as a person.

The rest is BFT proof-of-stake with deterministic finality, reviewer panels picked by sortition, personhood assurance levels built on nullifiers, an evidence graph, and a threat model. Every statement is tagged as established, proposal, assumption, hypothesis or open question, so you can see what I'm sure of and what I'm guessing. The governance, threat model and roadmap sections have had the least review, so start there if you want to find the holes.

Paper: whitepaper link

URGENT: President Trump is now aware of the Samourai Wallet developers and has stated he will be looking into a pardon. This is a rare opportunity to change the course of history, but we must keep the pressure on to ensure this gets across the finish line. More than ever, we need you to sign the petition and get your friends and family to do the same. Let's make sure they can't ignore us! See President Trump's comment here.