TCP/IP

TCP/IP is the foundational protocol suite of the internet, named after its two core protocols: the Transmission Control Protocol (TCP) and the Internet Protocol (IP). IP handles addressing and routing — getting packets from one machine to another across many hops — while TCP layers reliability on top, guaranteeing that bytes arrive complete and in order, retransmitting whatever gets lost. Nearly everything a sovereign Bitcoiner runs rides on this stack: a node's peer connections, a miner's pool connection, a wallet talking to a home server, the dashboard in your browser. Understanding it is the difference between administering your infrastructure and merely hoping at it.

The four layers

The suite is organized as layers, each wrapping the one above with its own header — a process called encapsulation. The link layer (Ethernet, Wi-Fi) moves frames across one physical network segment. The internet layer (IP) assigns addresses and forwards packets hop by hop between networks; routers live here. The transport layer offers two personalities: TCP for reliable, ordered byte streams, and UDP for lightweight fire-and-forget datagrams where speed beats guarantees. The application layer is everything you actually use — HTTP, SSH, DNS, and the Bitcoin, Lightning, and Stratum protocols. Each layer solves one problem and trusts its neighbors for the rest; that separation of concerns is why the same stack serves a Bitaxe and a hyperscale datacenter unchanged.

Ports, sockets, and Bitcoin

IP addresses identify machines; ports identify services on a machine. A connection is defined by the pair of address:port endpoints — a socket. Bitcoin Core listens for peers on TCP port 8333 by default; Lightning implementations, Electrum servers, and web dashboards each claim their own ports. Mining lives here too: an ASIC's connection to its pool is a long-lived TCP session speaking Stratum V1 (plaintext JSON) or the encrypted, binary Stratum V2. When a miner shows "pool connection lost," it is reporting a TCP-layer event, and the diagnosis toolkit is the standard one: can you resolve the pool's name, reach its address, and complete a handshake on its port?

Why node runners need this

Self-hosting failures are overwhelmingly layer confusion. A node that never gets inbound peers usually has nothing wrong with Bitcoin software — the culprit is a router doing network address translation with no port forwarding rule, or a firewall silently dropping the port. A dashboard reachable at home but not remotely is an addressing problem, not an application problem. Knowing which layer to interrogate — link up? address assigned? route exists? port open? service listening? — turns a mystery into a five-minute checklist.

The sovereignty angle

Addressing has its own history lesson. IPv4's 32-bit space — about 4.3 billion addresses — ran out years ago, which is why home networks live behind shared private ranges and why some ISPs stack customers behind carrier-grade NAT, where even your router's "public" address is shared and inbound connections are impossible without workarounds. IPv6's 128-bit space dissolves the scarcity and can hand every device a globally reachable address, restoring the original end-to-end model — with the firewall, rather than address exhaustion, deciding what gets in. How networks are carved into ranges is covered under subnetting and CIDR. For a node runner, knowing which regime your ISP puts you in is step zero of reachability planning.

TCP/IP is radically decentralized by design: any machine with an address can speak to any other without permission, which is precisely the property Bitcoin's peer-to-peer network inherits and depends on. The practical erosion of that property — NAT, carrier-grade NAT, filtered ports — is why running reachable infrastructure takes deliberate effort, and why mastering this stack is a genuinely sovereign skill rather than trivia.