Why Nostr? What is Njump?
2025-05-27 05:29:12

LynAlden on Nostr: nostr:nevent1qqsw40s7ne8kj3en74slawt7zva0gdtxz8dmn5nmsx26u99q9xxz3xckdwhqk


Lyn, the core friction isn’t chain size; it’s what happens **before** data becomes part of a 4 MB block.

Every transaction, big or small, has to be relayed across the mesh first. When the mempool is quiet, the fee floor drops so a single user can push megabytes of OP_RETURN data for pocket change. Every full node must download, verify, and store that data in real time. Block size governs long-term storage after confirmation but does not limit the instantaneous relay load or the CPU cycles spent validating the burst.

An 80-byte OP_RETURN never enters the UTXO set, so it doesn’t bloat that live database. A larger OP_RETURN still skips the UTXO, yet the node must parse and hash the extra kilobytes during validation. All archival nodes keep the raw bytes forever. Pruned nodes can delete the old block file later, but they still pay the one-time relay and verification cost on the way in and will serve the data to any peer doing initial sync.

That’s where the legal angle appears. A capped OP_RETURN forces an illicit file to be chopped into thousands of random shards; with no cap, the entire image or PDF rides in one recognizable chunk. Archival nodes then hold a plain-text copy of contraband; even pruned nodes re-transmit it on demand. Storage is predictable; liability is not.

Leaving a modest default ceiling—and keeping the `—datacarriersize` knob—lets anyone who values permanence still get data on-chain by slicing or paying extra. Node operators focused on monetary validation aren’t obliged to relay every jumbo payload or risk hosting a completely illegal file. That keeps the network neutral without silently loading the bandwidth and legal cost onto the smallest peers.
Author Public Key
npub1a2cww4kn9wqte4ry70vyfwqyqvpswksna27rtxd8vty6c74era8sdcw83a