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
¿Cómo puede un nodo avisar a sus pares de transacciones nuevas sin repetir el mismo anuncio por toda la red?
Erlay aborda ese coste en la capa de retransmisión. En vez de que cada nodo envíe a cada par un inventario de cada transacción que ve, los pares intercambian resúmenes compactos de sus conjuntos de transacciones y reconcilian las diferencias. El esquema Minisketch permite reconstruir elementos que faltan cuando el número de diferencias cabe en la capacidad del resumen; después, los nodos solicitan las transacciones que aún no tienen.
La ganancia potencial crece cuando un nodo mantiene muchas conexiones: disminuye el tráfico redundante, aunque la reconciliación añade intercambio de mensajes y puede tardar más que un anuncio inmediato. Si las diferencias exceden lo que el resumen puede representar, hacen falta rondas o mecanismos de recuperación; no existe una compresión ilimitada ni se presupone que las mempools sean iguales.
Esto no cambia consenso: una transacción reconciliada aún debe validarse. Tampoco obliga a un minero a incluirla; la selección de bloque sigue siendo decisión minera. La wallet solo crea y difunde la transacción. Erlay modifica cómo ciertos pares descubren qué les falta, no qué transacciones son válidas.
Erlay aborda ese coste en la capa de retransmisión. En vez de que cada nodo envíe a cada par un inventario de cada transacción que ve, los pares intercambian resúmenes compactos de sus conjuntos de transacciones y reconcilian las diferencias. El esquema Minisketch permite reconstruir elementos que faltan cuando el número de diferencias cabe en la capacidad del resumen; después, los nodos solicitan las transacciones que aún no tienen.
La ganancia potencial crece cuando un nodo mantiene muchas conexiones: disminuye el tráfico redundante, aunque la reconciliación añade intercambio de mensajes y puede tardar más que un anuncio inmediato. Si las diferencias exceden lo que el resumen puede representar, hacen falta rondas o mecanismos de recuperación; no existe una compresión ilimitada ni se presupone que las mempools sean iguales.
Esto no cambia consenso: una transacción reconciliada aún debe validarse. Tampoco obliga a un minero a incluirla; la selección de bloque sigue siendo decisión minera. La wallet solo crea y difunde la transacción. Erlay modifica cómo ciertos pares descubren qué les falta, no qué transacciones son válidas.
PajaritoBTC
Una transacción firmada todavía no está confirmada. ¿Qué falta entre autorizar un gasto y verlo asentado en la cadena?
Primero, la wallet construye la transacción y firma con la clave correspondiente. La firma demuestra que se autoriza gastar ciertas salidas; no envía por sí sola nada a la red. Después, la wallet la transmite a nodos, que la revisan y pueden retransmitirla. Si cumple sus reglas, puede quedar en sus mempools, aunque estas no son una cola única compartida por todos.
Un minero puede seleccionarla e incluirla en un bloque. Cuando un nodo acepta ese bloque como válido, la transacción tiene una confirmación. Cada bloque posterior que se añade sobre ese bloque aumenta el recuento: el siguiente la lleva a dos, y así sucesivamente.
Seis confirmaciones significa que el bloque de la transacción y cinco bloques posteriores están en la cadena activa. No es un interruptor que convierta el pago en absolutamente irreversible: una reorganización podría retirar bloques recientes. Pero, en general, rehacer una parte más profunda exige más trabajo acumulado.
La clave es separar etapas: firmada, difundida, incluida y con confirmaciones acumuladas. Ver una transacción en una wallet no siempre significa que ya esté confirmada; el recuento indica cuánta cadena se ha construido sobre su bloque.
Primero, la wallet construye la transacción y firma con la clave correspondiente. La firma demuestra que se autoriza gastar ciertas salidas; no envía por sí sola nada a la red. Después, la wallet la transmite a nodos, que la revisan y pueden retransmitirla. Si cumple sus reglas, puede quedar en sus mempools, aunque estas no son una cola única compartida por todos.
Un minero puede seleccionarla e incluirla en un bloque. Cuando un nodo acepta ese bloque como válido, la transacción tiene una confirmación. Cada bloque posterior que se añade sobre ese bloque aumenta el recuento: el siguiente la lleva a dos, y así sucesivamente.
Seis confirmaciones significa que el bloque de la transacción y cinco bloques posteriores están en la cadena activa. No es un interruptor que convierta el pago en absolutamente irreversible: una reorganización podría retirar bloques recientes. Pero, en general, rehacer una parte más profunda exige más trabajo acumulado.
La clave es separar etapas: firmada, difundida, incluida y con confirmaciones acumuladas. Ver una transacción en una wallet no siempre significa que ya esté confirmada; el recuento indica cuánta cadena se ha construido sobre su bloque.
PajaritoBTC
¿Qué ocurre si una transacción pendiente paga una comisión demasiado baja y ya no puede modificarse?
Una opción es CPFP, «Child Pays for Parent». La idea: crear una segunda transacción —la hija— que gaste una salida de la primera —la madre— y pague una comisión suficientemente alta. Un minero puede considerar el conjunto y obtener una comisión media atractiva por incluir ambas.
La hija no confirma mágicamente a la madre. Para ser válida, la madre debe estar en el bloque o ser incluida junto a ella, porque la hija depende de su salida. Los nodos comprueban esa relación, que no haya doble gasto y que cada transacción cumpla las reglas de consenso.
La técnica resulta útil cuando la primera transacción ya está difundida, pero también tiene límites: la salida debe poder gastarse, la política de la mempool puede imponer límites de tamaño o ancestros, y ningún minero está obligado a incluir el paquete. Además, la comisión alta de la hija cubre el conjunto; no cambia la comisión original.
La consecuencia es que una transacción puede influir indirectamente en la prioridad de otra mediante una dependencia válida. CPFP no rompe las reglas ni garantiza confirmación: coordina dos transacciones para que los mineros evalúen su coste y recompensa como un paquete.
Una opción es CPFP, «Child Pays for Parent». La idea: crear una segunda transacción —la hija— que gaste una salida de la primera —la madre— y pague una comisión suficientemente alta. Un minero puede considerar el conjunto y obtener una comisión media atractiva por incluir ambas.
La hija no confirma mágicamente a la madre. Para ser válida, la madre debe estar en el bloque o ser incluida junto a ella, porque la hija depende de su salida. Los nodos comprueban esa relación, que no haya doble gasto y que cada transacción cumpla las reglas de consenso.
La técnica resulta útil cuando la primera transacción ya está difundida, pero también tiene límites: la salida debe poder gastarse, la política de la mempool puede imponer límites de tamaño o ancestros, y ningún minero está obligado a incluir el paquete. Además, la comisión alta de la hija cubre el conjunto; no cambia la comisión original.
La consecuencia es que una transacción puede influir indirectamente en la prioridad de otra mediante una dependencia válida. CPFP no rompe las reglas ni garantiza confirmación: coordina dos transacciones para que los mineros evalúen su coste y recompensa como un paquete.
PajaritoBTC
¿Por qué un nodo acepta un bloque de Bitcoin? No porque alguien diga que es correcto. Comprueba su conexión con el bloque anterior, la prueba de trabajo, las transacciones y las reglas de gasto. Si algo falla, lo rechaza, aunque muchos otros nodos lo hayan recibido.
PajaritoBTC
¿Sabías que…? La hora escrita en un bloque de Bitcoin no tiene que ser exacta: debe superar la mediana de las horas de los 11 bloques anteriores y no adelantarse demasiado respecto al tiempo de la red. Es una marca acotada, no un reloj central.
PajaritoBTC
¿Por qué una recompensa de minería no puede gastarse inmediatamente?
La transacción coinbase crea las salidas que reciben el subsidio y las comisiones del bloque, pero esas salidas tienen una regla especial de consenso: no pueden gastarse hasta que hayan madurado 100 bloques. El bloque que contiene la coinbase cuenta como el primero; por eso deben existir 100 bloques posteriores antes de que el gasto sea válido.
Los nodos no confían en que una wallet espere correctamente. Al validar una entrada que referencia una coinbase, comprueban la altura del bloque que la creó y la altura actual de la cadena. Si todavía no han transcurrido las 100 confirmaciones exigidas, la transacción es inválida para un bloque, aunque la firma y el importe sean correctos.
La regla también protege frente a reorganizaciones. Si una rama pierde un bloque con una coinbase, sus salidas dejan de pertenecer al estado activo y cualquier gasto que dependiera de ellas debe reevaluarse. La recompensa no se convierte en saldo definitivo solo porque haya sido observada en una rama.
Aquí conviene separar capas: el consenso impone la madurez; la política de relay puede impedir que un nodo retransmita antes un gasto inválido; el minero no puede incluirlo legalmente hasta que cumpla la regla; y la wallet decide cuándo mostrarlo como disponible o construir un gasto.
La consecuencia es precisa: una coinbase confirmada no equivale todavía a una UTXO gastable. El protocolo introduce una espera obligatoria para que las recompensas minadas no se utilicen inmediatamente mientras la cadena puede reorganizarse.
La transacción coinbase crea las salidas que reciben el subsidio y las comisiones del bloque, pero esas salidas tienen una regla especial de consenso: no pueden gastarse hasta que hayan madurado 100 bloques. El bloque que contiene la coinbase cuenta como el primero; por eso deben existir 100 bloques posteriores antes de que el gasto sea válido.
Los nodos no confían en que una wallet espere correctamente. Al validar una entrada que referencia una coinbase, comprueban la altura del bloque que la creó y la altura actual de la cadena. Si todavía no han transcurrido las 100 confirmaciones exigidas, la transacción es inválida para un bloque, aunque la firma y el importe sean correctos.
La regla también protege frente a reorganizaciones. Si una rama pierde un bloque con una coinbase, sus salidas dejan de pertenecer al estado activo y cualquier gasto que dependiera de ellas debe reevaluarse. La recompensa no se convierte en saldo definitivo solo porque haya sido observada en una rama.
Aquí conviene separar capas: el consenso impone la madurez; la política de relay puede impedir que un nodo retransmita antes un gasto inválido; el minero no puede incluirlo legalmente hasta que cumpla la regla; y la wallet decide cuándo mostrarlo como disponible o construir un gasto.
La consecuencia es precisa: una coinbase confirmada no equivale todavía a una UTXO gastable. El protocolo introduce una espera obligatoria para que las recompensas minadas no se utilicen inmediatamente mientras la cadena puede reorganizarse.
PajaritoBTC
¿Cómo demuestra un bloque que incluye una transacción? Primero, las transacciones se resumen en un árbol de hashes y su raíz queda en el encabezado. Después, el nodo combina la transacción con una prueba de hashes. Si obtiene la misma raíz, confirma que pertenece al bloque. Luego verifica las reglas del pago.
PajaritoBTC
¿Cómo compromete un bloque de Bitcoin los datos witness de sus transacciones?
SegWit añadió un segundo compromiso dentro del bloque. Además del Merkle root tradicional, que se calcula con los TXID sin witness, el bloque puede incluir un witness commitment en una salida OP_RETURN de la coinbase.
Para construirlo, se calcula un árbol de Merkle con los wTXID de las transacciones. La coinbase ocupa la posición cero y su wTXID se define como cero. La raíz resultante se combina mediante SHA256d con un witness reserved value de 32 bytes incluido en el witness de la coinbase. El resultado debe coincidir con el compromiso publicado en esa salida.
La condición es de consenso: si existe un bloque con transacciones SegWit, los nodos comprueban esa relación entre wTXID, raíz, valor reservado y coinbase. Un minero no puede cambiar arbitrariamente el witness después de calcular el compromiso; tendría que rehacer el bloque y su prueba de trabajo.
El reserved value no es una firma ni una autorización. Es un dato elegido por quien construye el bloque y sirve como entrada final del compromiso. Tampoco convierte el witness en privado: los datos siguen viajando en el bloque y se validan según las reglas de scripts y firmas.
Hay una distinción importante. El relay decide qué transacciones acepta o retransmite; la minería decide cuáles intenta incluir. Ninguna política local puede hacer válido un compromiso incorrecto. Una wallet, por su parte, normalmente no construye este compromiso: prepara el witness de sus transacciones y deja la coinbase y el bloque al minero.
La consecuencia es precisa: SegWit no solo separa el witness del TXID. También permite que el bloque comprometa criptográficamente la versión completa de sus transacciones, mientras mantiene el Merkle root histórico para compatibilidad con estructuras existentes.
SegWit añadió un segundo compromiso dentro del bloque. Además del Merkle root tradicional, que se calcula con los TXID sin witness, el bloque puede incluir un witness commitment en una salida OP_RETURN de la coinbase.
Para construirlo, se calcula un árbol de Merkle con los wTXID de las transacciones. La coinbase ocupa la posición cero y su wTXID se define como cero. La raíz resultante se combina mediante SHA256d con un witness reserved value de 32 bytes incluido en el witness de la coinbase. El resultado debe coincidir con el compromiso publicado en esa salida.
La condición es de consenso: si existe un bloque con transacciones SegWit, los nodos comprueban esa relación entre wTXID, raíz, valor reservado y coinbase. Un minero no puede cambiar arbitrariamente el witness después de calcular el compromiso; tendría que rehacer el bloque y su prueba de trabajo.
El reserved value no es una firma ni una autorización. Es un dato elegido por quien construye el bloque y sirve como entrada final del compromiso. Tampoco convierte el witness en privado: los datos siguen viajando en el bloque y se validan según las reglas de scripts y firmas.
Hay una distinción importante. El relay decide qué transacciones acepta o retransmite; la minería decide cuáles intenta incluir. Ninguna política local puede hacer válido un compromiso incorrecto. Una wallet, por su parte, normalmente no construye este compromiso: prepara el witness de sus transacciones y deja la coinbase y el bloque al minero.
La consecuencia es precisa: SegWit no solo separa el witness del TXID. También permite que el bloque comprometa criptográficamente la versión completa de sus transacciones, mientras mantiene el Merkle root histórico para compatibilidad con estructuras existentes.
PajaritoBTC
Cerramos la semana con una idea: cada nodo verifica por separado, pero Bitcoin necesita coordinar un estado compartido. La cadena activa lo hace mediante reglas y trabajo acumulado. La próxima pregunta: ¿cómo eligen los nodos entre bloques válidos que compiten?
PajaritoBTC
¿Puede una transacción pendiente ser sustituida por otra que pague una comisión mayor?
Sí, mediante Replace-by-Fee (RBF), si la transacción original y la nueva cumplen las reglas de reemplazo aplicadas por el nodo. La versión nueva suele gastar las mismas entradas, modifica algún dato permitido y ofrece una comisión suficiente para compensar el espacio ocupado por la anterior.
RBF actúa antes de la confirmación. Un nodo puede retirar de su mempool la versión antigua y aceptar la nueva, pero no existe una mempool global: otros nodos pueden conservar la primera o no aceptar el reemplazo. Además, los mineros eligen qué transacciones incluir.
La sustitución no revierte un bloque ni cambia una transacción ya confirmada. Si la versión antigua entra primero en la cadena, deja de ser una operación pendiente reemplazable y la alternativa tendrá que evaluarse según sus entradas y el estado UTXO resultante.
La consecuencia es precisa: RBF ofrece flexibilidad para corregir una comisión insuficiente o ajustar una transacción antes de confirmarse, pero no garantiza aceptación universal ni una confirmación inmediata. “Pendiente” significa que todavía puede cambiar; “confirmada” significa que ya forma parte del estado de una cadena validada.
Sí, mediante Replace-by-Fee (RBF), si la transacción original y la nueva cumplen las reglas de reemplazo aplicadas por el nodo. La versión nueva suele gastar las mismas entradas, modifica algún dato permitido y ofrece una comisión suficiente para compensar el espacio ocupado por la anterior.
RBF actúa antes de la confirmación. Un nodo puede retirar de su mempool la versión antigua y aceptar la nueva, pero no existe una mempool global: otros nodos pueden conservar la primera o no aceptar el reemplazo. Además, los mineros eligen qué transacciones incluir.
La sustitución no revierte un bloque ni cambia una transacción ya confirmada. Si la versión antigua entra primero en la cadena, deja de ser una operación pendiente reemplazable y la alternativa tendrá que evaluarse según sus entradas y el estado UTXO resultante.
La consecuencia es precisa: RBF ofrece flexibilidad para corregir una comisión insuficiente o ajustar una transacción antes de confirmarse, pero no garantiza aceptación universal ni una confirmación inmediata. “Pendiente” significa que todavía puede cambiar; “confirmada” significa que ya forma parte del estado de una cadena validada.
PajaritoBTC
Esta semana vimos que una transacción puede esperar en la mempool y que un bloque válido puede incluir pocos pagos. La conclusión: Bitcoin no mide la actividad por «llenar» bloques; cada nodo verifica si las reglas se cumplen, no si hay mucho movimiento.
PajaritoBTC
Un bloque de Bitcoin puede ser válido aunque no incluya pagos de usuarios. Normalmente contiene la transacción coinbase, que registra la recompensa, además del encabezado y las reglas necesarias. La red valida el bloque, no exige que esté lleno de pagos.