En sentido estricto, Orphan Block es un bloque cuyo padre desconoce el nodo observador. El uso amplio lo confunde con un bloque stale de una rama inactiva; la etiqueta por sí sola no determina su validez ni su causa.
Bitcoin Developer Guide distingue explícitamente un Orphan Block con padre desconocido de un Stale Block en una rama competidora. Este último puede tener un padre conocido y ser válido. Al leer un explorador o informe de un pool, identifique primero el significado empleado; la palabra orphan no resuelve esa distinción. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 busca hashPrevBlock en su índice mediante AcceptBlockHeader. Una entrada ausente devuelve prev-blk-not-found; un padre marcado como inválido conduce a bad-prevblk. Son resultados distintos. Obtener el padre permite más controles contextuales, pero no garantiza por sí solo la aceptación del bloque completo. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 introdujo la sincronización headers-first: primero las cabeceras y después la descarga paralela de bloques. El índice puede conocer la cabecera del padre sin tener su bloque completo en disco. No confunda un cuerpo de bloque ausente con una cabecera parental desconocida; determine qué datos faltan realmente. [Bitcoin Core 0.10.0 — Headers-first synchronization]
En getchaintips, Bitcoin Core 29 distingue active, valid-fork, valid-headers, headers-only e invalid. valid-fork es una rama inactiva completamente validada; valid-headers tiene bloques disponibles sin validación completa y headers-only carece de algunos bloques. Ni siquiera la expresión orphaned branches de la ayuda justifica fusionar estos estados. [Bitcoin Core 29 — getchaintips]
Ejemplo: dos bloques diferentes A y B pueden tener altura 900000. Ese número no identifica al ganador ni un bloque único; registre hash y previousblockhash. La selección entre ramas válidas sigue el trabajo acumulado, denominado chainwork en RPC, no simplemente la altura. La cifra ilustrativa no afirma una bifurcación histórica concreta. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
getblock de Bitcoin Core 29 devuelve confirmations = -1 para un bloque fuera de la cadena principal. No es una profundidad negativa de reorganización ni prueba de un padre ausente. Léalo junto con el hash, la información de la rama y el estado local; la salida de un nodo no enumera todo lo recibido por los demás. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY en Bitcoin Core 29 vale 100. Restringe el gasto de una salida coinbase según la profundidad en bloques, no según minutos de espera. El tiempo transcurrido o nuevos bloques en otro lugar no restauran la recompensa de una rama stale ajena al historial activo; la madurez no sustituye la inclusión en la cadena. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
Para su registro, combine getchaintips y getblock con hash del bloque, padre, estado de rama, versión del nodo y hora de observación. Registre esta hora separadamente del campo time de la cabecera. Una sola salida no demuestra un ataque, una tasa global de huérfanos ni una avería concreta de red; hacen falta más observaciones. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Para obtener la imagen más completa, lee esta entrada junto con Bloque obsoleto, Reorganización de cadena, Propagación de bloques, Proof of Work. También enlazan con esta entrada Bloque obsoleto.