Pajarito en redes
Aquí reunimos lo que Pajarito publica en redes: hilos para profundizar, tests para comprobar lo que sabes, definiciones del glosario en un minuto, avisos de seguridad y datos para entender mejor Bitcoin. Todo en un solo sitio, con filtros por tipo y por tema, para que puedas leerlo sin depender del algoritmo de ninguna red.
Cada publicación enlaza con la guía de la web donde seguir aprendiendo. Si quieres recibirlas según salen, síguenos donde prefieras:
Para preguntas largas, correcciones o colaboraciones, usa la página de contacto.
PajaritoBTC
Una transacción firmada no entra directamente en un bloque. Primero llega a la mempool: la sala de espera de un nodo para transacciones válidas aún no confirmadas. Cada nodo mantiene la suya; no es una cola única global.
PajaritoBTC
¿Puede un nodo empezar a operar sin esperar a validar todos los bloques desde el génesis? Bitcoin Core puede hacerlo mediante assumeutxo, una optimización distinta de assumevalid.
El nodo carga una instantánea del conjunto UTXO correspondiente a una altura concreta. Esa instantánea incluye los UTXO que deberían existir allí y metadatos para enlazarla con la cadena. Si el hash y los parámetros esperados coinciden con los datos incorporados para esa red, el nodo puede construir rápidamente un chainstate y continuar validando bloques nuevos desde ese punto.
Pero la instantánea no reemplaza la validación histórica. El nodo inicia en paralelo una validación completa desde el génesis, reconstruye otro estado UTXO y compara ambos al alcanzar la misma altura. Si no coinciden, la optimización no puede considerarse correcta y el nodo debe tratar el problema como un fallo de validación.
La condición clave es que los datos de la instantánea no cambian las reglas de consenso. No autorizan bloques inválidos ni permiten saltarse la comprobación de los bloques posteriores. Son un atajo operativo identificado por metadatos conocidos por el software; la cadena completa sigue siendo la referencia que debe verificarse.
La consecuencia es precisa: assumeutxo reduce el tiempo hasta disponer de un nodo funcional, pero no convierte una instantánea en una autoridad. Acelera la construcción inicial del estado y deja la comprobación histórica para segundo plano. Assumevalid omite temporalmente ciertas firmas históricas; assumeutxo adelanta el estado UTXO. Son optimizaciones diferentes, con límites diferentes.
El nodo carga una instantánea del conjunto UTXO correspondiente a una altura concreta. Esa instantánea incluye los UTXO que deberían existir allí y metadatos para enlazarla con la cadena. Si el hash y los parámetros esperados coinciden con los datos incorporados para esa red, el nodo puede construir rápidamente un chainstate y continuar validando bloques nuevos desde ese punto.
Pero la instantánea no reemplaza la validación histórica. El nodo inicia en paralelo una validación completa desde el génesis, reconstruye otro estado UTXO y compara ambos al alcanzar la misma altura. Si no coinciden, la optimización no puede considerarse correcta y el nodo debe tratar el problema como un fallo de validación.
La condición clave es que los datos de la instantánea no cambian las reglas de consenso. No autorizan bloques inválidos ni permiten saltarse la comprobación de los bloques posteriores. Son un atajo operativo identificado por metadatos conocidos por el software; la cadena completa sigue siendo la referencia que debe verificarse.
La consecuencia es precisa: assumeutxo reduce el tiempo hasta disponer de un nodo funcional, pero no convierte una instantánea en una autoridad. Acelera la construcción inicial del estado y deja la comprobación histórica para segundo plano. Assumevalid omite temporalmente ciertas firmas históricas; assumeutxo adelanta el estado UTXO. Son optimizaciones diferentes, con límites diferentes.
PajaritoBTC
¿Cómo demuestra un bloque de Bitcoin que sus datos witness pertenecen realmente a las transacciones incluidas?
El encabezado solo contiene una raíz de Merkle de txid, que excluye el witness. SegWit añade un segundo compromiso: el árbol de Merkle de wtxid. Para la coinbase se usa un wtxid especial de 32 bytes a cero; las demás transacciones aportan su wtxid real.
La raíz resultante se combina con el witness reserved value, un valor de 32 bytes situado en el testigo de la coinbase. El compromiso publicado en una salida OP_RETURN se calcula como SHA256d(raíz de wtxid || reserved value). El nodo repite el cálculo y compara el resultado.
La coinbase no es solo la recompensa: también transporta ese valor reservado, que enlaza criptográficamente el compromiso del bloque con sus testigos. Si falta, tiene un tamaño incorrecto o no coincide el hash, el bloque viola consenso. No es una preferencia de relay.
Hay límites importantes: si el bloque contiene transacciones con witness, debe incluir un compromiso válido; un bloque sin transacciones witness no necesita uno. Si aparecen varias salidas con el patrón de compromiso, se usa la de mayor índice. La wallet crea los testigos, el minero construye el compromiso y cada nodo lo verifica.
La consecuencia es una separación precisa: el encabezado compromete los txid y el compromiso de coinbase vincula los wtxid. Así SegWit puede mantener la compatibilidad del encabezado y, a la vez, hacer verificable la integridad de los datos witness.
El encabezado solo contiene una raíz de Merkle de txid, que excluye el witness. SegWit añade un segundo compromiso: el árbol de Merkle de wtxid. Para la coinbase se usa un wtxid especial de 32 bytes a cero; las demás transacciones aportan su wtxid real.
La raíz resultante se combina con el witness reserved value, un valor de 32 bytes situado en el testigo de la coinbase. El compromiso publicado en una salida OP_RETURN se calcula como SHA256d(raíz de wtxid || reserved value). El nodo repite el cálculo y compara el resultado.
La coinbase no es solo la recompensa: también transporta ese valor reservado, que enlaza criptográficamente el compromiso del bloque con sus testigos. Si falta, tiene un tamaño incorrecto o no coincide el hash, el bloque viola consenso. No es una preferencia de relay.
Hay límites importantes: si el bloque contiene transacciones con witness, debe incluir un compromiso válido; un bloque sin transacciones witness no necesita uno. Si aparecen varias salidas con el patrón de compromiso, se usa la de mayor índice. La wallet crea los testigos, el minero construye el compromiso y cada nodo lo verifica.
La consecuencia es una separación precisa: el encabezado compromete los txid y el compromiso de coinbase vincula los wtxid. Así SegWit puede mantener la compatibilidad del encabezado y, a la vez, hacer verificable la integridad de los datos witness.
PajaritoBTC
¿Sabías que…? El hash de un bloque de Bitcoin no se guarda dentro del bloque: se calcula a partir de su encabezado. Como ese encabezado incluye el hash anterior, cada bloque enlaza criptográficamente con el precedente.
PajaritoBTC
Una wallet puede firmar un pago, y la red puede retransmitirlo, pero ninguna de esas dos cosas lo convierte aún en parte de Bitcoin. La confirmación llega cuando un bloque válido lo incluye y los nodos lo aceptan. Separar etapas evita confundir “enviado” con “registrado”.
PajaritoBTC
¿Cómo descubre un nodo qué cadena debe descargar al sincronizarse con Bitcoin?
En el protocolo P2P, la respuesta empieza por los encabezados. Un nodo solicita headers a sus pares y recibe una secuencia de bloques descritos por su hash anterior, raíz de Merkle, tiempo, bits y nonce. Puede comprobar rápidamente que la cadena enlaza, que cada prueba de trabajo cumple el objetivo y que el trabajo acumulado aumenta.
Para pedir la continuación, el nodo envía un block locator: una lista de hashes de su cadena conocida, densa cerca de la punta y cada vez más espaciada hacia atrás. El par busca el primer punto común y devuelve headers posteriores. Así pueden reconciliarse ramas distintas sin enviar todo el historial desde el génesis.
Pero los headers no bastan. Solo comprometen la raíz de transacciones; todavía hay que descargar los bloques completos y validar sus transacciones, el conjunto UTXO, la coinbase y todas las reglas de consenso. Un par puede anunciar headers con mucho trabajo y aun así enviar bloques inválidos: el nodo no debe aceptarlos por haberlos recibido primero.
La consecuencia es una separación precisa: headers-first optimiza descubrimiento y orden de descarga, mientras la validación completa decide qué cadena es aceptable. Relay y comportamiento de los pares afectan a qué datos llegan antes; no sustituyen la comprobación local.
En el protocolo P2P, la respuesta empieza por los encabezados. Un nodo solicita headers a sus pares y recibe una secuencia de bloques descritos por su hash anterior, raíz de Merkle, tiempo, bits y nonce. Puede comprobar rápidamente que la cadena enlaza, que cada prueba de trabajo cumple el objetivo y que el trabajo acumulado aumenta.
Para pedir la continuación, el nodo envía un block locator: una lista de hashes de su cadena conocida, densa cerca de la punta y cada vez más espaciada hacia atrás. El par busca el primer punto común y devuelve headers posteriores. Así pueden reconciliarse ramas distintas sin enviar todo el historial desde el génesis.
Pero los headers no bastan. Solo comprometen la raíz de transacciones; todavía hay que descargar los bloques completos y validar sus transacciones, el conjunto UTXO, la coinbase y todas las reglas de consenso. Un par puede anunciar headers con mucho trabajo y aun así enviar bloques inválidos: el nodo no debe aceptarlos por haberlos recibido primero.
La consecuencia es una separación precisa: headers-first optimiza descubrimiento y orden de descarga, mientras la validación completa decide qué cadena es aceptable. Relay y comportamiento de los pares afectan a qué datos llegan antes; no sustituyen la comprobación local.
PajaritoBTC
La hora que ves en un bloque de Bitcoin no es un reloj exacto. El minero propone una marca temporal, pero debe respetar límites y los nodos la comparan con el tiempo mediano de bloques anteriores. Así, la red no depende del reloj de una sola máquina.
PajaritoBTC
¿Puede una transacción ser válida y, aun así, no circular por la red? Sí: hay que separar consenso de standardness.
El consenso define lo que un bloque no puede violar: entradas existentes y no gastadas, firmas válidas, scripts satisfechos, límites de tamaño y demás reglas activas. Si una transacción cumple esas condiciones, un minero podría incluirla en un bloque válido aunque algunos nodos no la acepten en su mempool.
La standardness es política local. Un nodo puede filtrar scripts, tamaños o formas consideradas poco comunes para reducir spam, consumo de recursos y riesgos operativos. Ese filtro afecta al relay y a la mempool, no convierte por sí solo una transacción válida en inválida bajo consenso.
La wallet debe conocer esta diferencia: construir un script permitido por consenso no garantiza que los nodos lo retransmitan ni que un minero lo vea. El minero puede recibirlo por otro canal, incluirlo directamente o aplicar sus propios filtros.
La consecuencia es que «no se propaga» y «no puede confirmarse» son diagnósticos distintos. Consenso decide qué bloques aceptan los nodos; standardness decide qué transacciones están dispuestos a transportar antes de que llegue un bloque.
El consenso define lo que un bloque no puede violar: entradas existentes y no gastadas, firmas válidas, scripts satisfechos, límites de tamaño y demás reglas activas. Si una transacción cumple esas condiciones, un minero podría incluirla en un bloque válido aunque algunos nodos no la acepten en su mempool.
La standardness es política local. Un nodo puede filtrar scripts, tamaños o formas consideradas poco comunes para reducir spam, consumo de recursos y riesgos operativos. Ese filtro afecta al relay y a la mempool, no convierte por sí solo una transacción válida en inválida bajo consenso.
La wallet debe conocer esta diferencia: construir un script permitido por consenso no garantiza que los nodos lo retransmitan ni que un minero lo vea. El minero puede recibirlo por otro canal, incluirlo directamente o aplicar sus propios filtros.
La consecuencia es que «no se propaga» y «no puede confirmarse» son diagnósticos distintos. Consenso decide qué bloques aceptan los nodos; standardness decide qué transacciones están dispuestos a transportar antes de que llegue un bloque.
PajaritoBTC
¿Qué ocurre después de pulsar «enviar»? 1) Tu wallet firma la transacción. 2) Los nodos comprueban que es válida y la retransmiten. 3) Un minero la incluye en un bloque, que los nodos verifican de nuevo. Así queda registrada en la cadena.
PajaritoBTC
¿Qué significa que una transacción de Bitcoin tenga un bloqueo temporal?
La pieza central es nLockTime, un campo que puede expresar una altura de bloque o una marca temporal absoluta. Pero no basta con escribir un valor futuro: para que el bloqueo sea relevante, al menos una entrada debe tener nSequence distinto de 0xffffffff. Si todas son finales, nLockTime se ignora y la transacción puede ser válida de inmediato.
Al validar, los nodos comparan el bloqueo con la altura siguiente o con el Median Time Past de la cadena, no con el reloj local exacto. Si aún no se cumple, la transacción no es final bajo consenso y no puede entrar en un bloque válido. La mempool puede rechazarla antes, según sus propias políticas, pero no convierte una transacción futura en inválida para siempre.
Esto es distinto de BIP68 y CSV: nLockTime fija una condición absoluta respecto a la cadena; CSV expresa una espera relativa desde la confirmación de un UTXO. La wallet debe elegir el mecanismo y construir las secuencias correctamente.
La consecuencia es que «bloqueada hasta una fecha» no describe una simple alarma de la wallet. Es una condición que los nodos y mineros deben evaluar con reglas precisas, usando altura o tiempo mediano y la finalidad de las entradas. Relay puede anticiparse y filtrar, pero solo el consenso decide si el bloqueo se ha cumplido.
La pieza central es nLockTime, un campo que puede expresar una altura de bloque o una marca temporal absoluta. Pero no basta con escribir un valor futuro: para que el bloqueo sea relevante, al menos una entrada debe tener nSequence distinto de 0xffffffff. Si todas son finales, nLockTime se ignora y la transacción puede ser válida de inmediato.
Al validar, los nodos comparan el bloqueo con la altura siguiente o con el Median Time Past de la cadena, no con el reloj local exacto. Si aún no se cumple, la transacción no es final bajo consenso y no puede entrar en un bloque válido. La mempool puede rechazarla antes, según sus propias políticas, pero no convierte una transacción futura en inválida para siempre.
Esto es distinto de BIP68 y CSV: nLockTime fija una condición absoluta respecto a la cadena; CSV expresa una espera relativa desde la confirmación de un UTXO. La wallet debe elegir el mecanismo y construir las secuencias correctamente.
La consecuencia es que «bloqueada hasta una fecha» no describe una simple alarma de la wallet. Es una condición que los nodos y mineros deben evaluar con reglas precisas, usando altura o tiempo mediano y la finalidad de las entradas. Relay puede anticiparse y filtrar, pero solo el consenso decide si el bloqueo se ha cumplido.
PajaritoBTC
¿Cómo puede un bloque de Bitcoin viajar por la red sin reenviar todas sus transacciones completas?
Una respuesta son los bloques compactos, definidos en BIP152. El nodo que anuncia el bloque envía su encabezado, una lista de identificadores cortos de las transacciones y las transacciones que el receptor probablemente no tenga.
El receptor intenta reconstruir el bloque usando su propia mempool. Si reconoce todos los identificadores, solo necesita recibir una pequeña descripción adicional y puede validar el bloque. Si faltan transacciones, solicita esas piezas en un mensaje de recuperación.
Esto ahorra ancho de banda y tiempo cuando mineros y nodos comparten una mempool parecida. Pero no es una confianza ciega: el bloque reconstruido debe pasar exactamente las mismas comprobaciones de consenso, y si la reconstrucción falla se pide el contenido que falta.
La consecuencia es una separación útil: los bloques compactos optimizan el transporte, no cambian qué transacciones son válidas ni qué cadena debe seguir un nodo. La red puede propagar menos datos repetidos sin sacrificar la verificación independiente.
Una respuesta son los bloques compactos, definidos en BIP152. El nodo que anuncia el bloque envía su encabezado, una lista de identificadores cortos de las transacciones y las transacciones que el receptor probablemente no tenga.
El receptor intenta reconstruir el bloque usando su propia mempool. Si reconoce todos los identificadores, solo necesita recibir una pequeña descripción adicional y puede validar el bloque. Si faltan transacciones, solicita esas piezas en un mensaje de recuperación.
Esto ahorra ancho de banda y tiempo cuando mineros y nodos comparten una mempool parecida. Pero no es una confianza ciega: el bloque reconstruido debe pasar exactamente las mismas comprobaciones de consenso, y si la reconstrucción falla se pide el contenido que falta.
La consecuencia es una separación útil: los bloques compactos optimizan el transporte, no cambian qué transacciones son válidas ni qué cadena debe seguir un nodo. La red puede propagar menos datos repetidos sin sacrificar la verificación independiente.
PajaritoBTC
Imagina varios árbitros con el mismo reglamento. En Bitcoin, cada nodo recibe transacciones y bloques y comprueba por su cuenta si cumplen las reglas. No pregunta a una oficina central: acepta solo lo que puede verificar.