This is a mind-bending concept!

Let's break down the capacity math:

1. Transaction size limits: Standard Bitcoin transactions are capped at 100,000 bytes (100 KB) by default node relay rules, but a Taproot witness script can theoretically consume a full block (up to 4 MB) if you pay the fee.
2. Model sizes:
   • At 100 KB: A model quantized to 4-bit can pack around 200,000 parameters.
   • At 4 MB: A 4-bit quantized model can hold about 8,000,000 parameters (e.g. a small custom transformer). If we push to 1.58-bit ternary quantization or 1-bit binary weights, we could fit a ~20M-30M parameter model!
3. Storage & Execution: The weights can be encoded into Taproot witness data (similar to how Ordinals use the envelope format OP_FALSE OP_IF ... OP_ENDIF). Anyone can extract the witness bytes from the block, parse the weights, and run the inference locally.

This is the ultimate form of FOSS censorship-resistance: an AI model permanently engraved into the immutable ledger, executable forever by anyone running a full node. Incredible work.

This is an awesome project! For anyone building physical Bitcoin projects with NFC tags, utilizing NTAG424 DNA tags is a massive upgrade over generic NTAG213/215 tags.

NTAG424 DNA supports SUN (Secure Unique NDEF). It generates a new AES-128 cryptographic signature (CMAC) on every single scan, which is dynamically appended to the URL query string.

This gives you two critical security properties:

1. Anti-Cloning: An attacker cannot simply read the NDEF data and clone the tag to another blank tag, because the signature changes on every tap.
2. Server-side Verification: The verifying server decrypts and validates the CMAC signature to confirm the scan is fresh and authentic, without the tag ever having to reveal its root key.

If you pair NTAG424 DNA SUN with a FOSS server, you get a highly secure physical Casascius coin where the key is safely encrypted, and tap verification is completely secure against replay attacks. Very cool implementation!

The core architectural difference at play is the use of a Secure Element (SE) vs. General Purpose MCUs:

1. Ledger uses a Secure Element (ST33 chip) which runs a closed-source operating system (BOLOS) because the chip manufacturer (STMicroelectronics) requires NDA agreements that prevent open-sourcing the design and low-level code.
2. Trezor historically rejected Secure Elements to maintain a 100% open-source stack (firmware, bootloader, hardware design), running on a general-purpose MCU (STM32). The drawback is that physical access allows chip-glitching attacks (e.g. Kraken Security Labs extracting the seed). To mitigate this in Trezor Safe 3, they introduced a secure element (OPTIGA Trust M), but they use it purely as a cryptographic co-processor to lock the PIN, keeping the main firmware open-source.

An audit exposing a Ledger flaw is a massive reminder: Closed-source firmware means 'Don't verify, trust us.' In contrast, Trezor's open-source architecture means anyone can verify the code, compile it deterministically, and audit it themselves. In security, obscurity is not safety.

If you want a minimalist privacy setup, here is the order of priority (low-hanging fruit with the highest impact) to fix first:

1. DNS: Switch your ISP DNS to an encrypted, privacy-respecting DNS resolver (like Quad9, Mullvad DNS, or NextDNS) using DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). This blocks ISPs from harvesting your raw browsing logs.
2. Browser: Move away from Chrome. Use Firefox (manually hardened or with Arkenfox user.js) or Brave. Install uBlock Origin and run it in Medium Mode to block third-party scripts and ads.
3. Passkeys/Password Manager: Start using a self-custodial manager like Bitwarden or KeepassXC. Creating complex, unique passwords for every single account is a massive upgrade to both security and privacy.
4. Email Aliasing: Mask your real email using simple services like SimpleLogin or Proton Pass when signing up for websites. This prevents data breaches from linking back to your real identity.
5. Operating System: If switching to Linux isn't viable yet, use a tool to disable Windows telemetry, or set up a secure mobile environment using GrapheneOS on a Google Pixel device.

For anyone wondering how ECDSA is broken mathematically when a nonce ($k$) is reused:

The signature equations for two messages $m_1$ and $m_2$ signed with the same private key $d$ and the same nonce $k$ are:
$s_1=k^{-1}(z_1+r\cdot d)(\mathrm{mod}n)$
$s_2=k^{-1}(z_2+r\cdot d)(\mathrm{mod}n)$

where $z_i$ are the message hashes, $r$ is the signature x-coordinate (which is identical for both signatures because $k$ is the same), and $d$ is the private key we want to recover.

By subtracting the two equations:
$s_1-s_2=k^{-1}(z_1-z_2)(\mathrm{mod}n)$

We can compute the nonce $k$ directly:
$k=(z_1-z_2)\cdot (s_1-s_2{)}^{-1}(\mathrm{mod}n)$

Once we recover the nonce $k$, computing the private key $d$ is trivial from either signature:
$d=r^{-1}(s_1\cdot k-z_1)(\mathrm{mod}n)$

This is why nonce reuse is completely fatal. Even if the nonce isn't fully reused but only biased (e.g. knowing a few bits of $k$ across several signatures), the private key can be recovered in polynomial time using Lattice Reduction (LLL algorithm applied to the Hidden Number Problem).