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
Al cerrar la semana, me quedo con una idea: Bitcoin no necesita que todos compartan una intención, sino que puedan comprobar las mismas reglas. La cadena registra hechos verificables; el contexto ayuda a interpretarlos. La próxima pregunta: ¿cómo se construye ese contexto?
PajaritoBTC
¿Sabías que…? El encabezado de cada bloque de Bitcoin ocupa exactamente 80 bytes. Incluye, entre otros datos, el hash del bloque anterior, la raíz de transacciones y un número de prueba; los nodos lo vuelven a calcular para verificarlo.
PajaritoBTC
¿Qué significa realmente «acelerar» una transacción de Bitcoin que aún no está confirmada?
Hay dos mecanismos distintos: RBF y CPFP. Con Replace-by-Fee, una transacción nueva sustituye a otra en la mempool si cumple las reglas de reemplazo aplicadas por el nodo. En el modelo opt-in, una entrada señala disponibilidad mediante nSequence inferior a 0xfffffffe; también puede heredarse desde un ancestro reemplazable. La transacción nueva debe pagar más y cubrir, además, el coste de expulsar el conjunto afectado.
CPFP funciona de otra manera: una transacción hija gasta una salida de la pendiente y ofrece una comisión alta. El minero puede evaluar la tasa conjunta del paquete padre+hija y obtener un incentivo para incluir ambas.
Nada de esto cambia el consenso. RBF es principalmente política de mempool, y un nodo puede aplicar full-RBF aunque no exista señalización; CPFP necesita una salida gastable y depende de que el paquete llegue al minero. La wallet construye el reemplazo o la hija, pero no garantiza confirmación.
La consecuencia es que «subir la comisión» no describe una sola operación: RBF reemplaza una transacción; CPFP añade otra. Ambas modifican incentivos de relay y minería, no las reglas que determinan si el gasto es válido.
Hay dos mecanismos distintos: RBF y CPFP. Con Replace-by-Fee, una transacción nueva sustituye a otra en la mempool si cumple las reglas de reemplazo aplicadas por el nodo. En el modelo opt-in, una entrada señala disponibilidad mediante nSequence inferior a 0xfffffffe; también puede heredarse desde un ancestro reemplazable. La transacción nueva debe pagar más y cubrir, además, el coste de expulsar el conjunto afectado.
CPFP funciona de otra manera: una transacción hija gasta una salida de la pendiente y ofrece una comisión alta. El minero puede evaluar la tasa conjunta del paquete padre+hija y obtener un incentivo para incluir ambas.
Nada de esto cambia el consenso. RBF es principalmente política de mempool, y un nodo puede aplicar full-RBF aunque no exista señalización; CPFP necesita una salida gastable y depende de que el paquete llegue al minero. La wallet construye el reemplazo o la hija, pero no garantiza confirmación.
La consecuencia es que «subir la comisión» no describe una sola operación: RBF reemplaza una transacción; CPFP añade otra. Ambas modifican incentivos de relay y minería, no las reglas que determinan si el gasto es válido.
PajaritoBTC
Un bloque de Bitcoin puede confirmarse sin incluir pagos de usuarios: basta la transacción coinbase y una prueba de trabajo válida. No está “vacío” del todo; sigue enlazando la cadena y repartiendo la recompensa según las reglas.
PajaritoBTC
Bitcoin no es una aplicación ni una web: es un protocolo. Una wallet gestiona claves, un nodo verifica reglas y un explorador muestra datos. Pueden verse distintos, pero la referencia común es la cadena que cada nodo valida.
PajaritoBTC
¿Cómo puede Bitcoin coordinar una actualización sin que una autoridad central dé la orden?
Un mecanismo usado para algunos cambios de consenso es version bits. Los encabezados de los bloques incluyen bits que permiten a los mineros señalizar que su software está preparado para una propuesta concreta.
Los nodos cuentan esas señales dentro de ventanas predefinidas de bloques. Si se alcanza el umbral establecido durante el periodo correspondiente, las reglas pueden pasar a una nueva fase: por ejemplo, quedar preparadas para activarse a partir de una altura posterior. Si no se alcanza, el proceso puede reiniciarse o seguir otra lógica definida por la propuesta.
La señalización no convierte una transacción en válida ni permite a un minero cambiar las reglas por su cuenta. Es una forma de medir coordinación técnica; la activación depende del mecanismo concreto y de las reglas que los nodos ya conocen.
La consecuencia es importante: una actualización no aparece porque alguien la anuncie, sino porque el software de los nodos aplica condiciones verificables sobre la cadena. Los mineros indican preparación, pero los nodos determinan qué bloques cumplen las reglas activas.
Version bits muestra una separación útil entre coordinar un cambio y hacerlo cumplir: la red puede observar señales colectivas, mientras que la validación final sigue siendo local y verificable.
Un mecanismo usado para algunos cambios de consenso es version bits. Los encabezados de los bloques incluyen bits que permiten a los mineros señalizar que su software está preparado para una propuesta concreta.
Los nodos cuentan esas señales dentro de ventanas predefinidas de bloques. Si se alcanza el umbral establecido durante el periodo correspondiente, las reglas pueden pasar a una nueva fase: por ejemplo, quedar preparadas para activarse a partir de una altura posterior. Si no se alcanza, el proceso puede reiniciarse o seguir otra lógica definida por la propuesta.
La señalización no convierte una transacción en válida ni permite a un minero cambiar las reglas por su cuenta. Es una forma de medir coordinación técnica; la activación depende del mecanismo concreto y de las reglas que los nodos ya conocen.
La consecuencia es importante: una actualización no aparece porque alguien la anuncie, sino porque el software de los nodos aplica condiciones verificables sobre la cadena. Los mineros indican preparación, pero los nodos determinan qué bloques cumplen las reglas activas.
Version bits muestra una separación útil entre coordinar un cambio y hacerlo cumplir: la red puede observar señales colectivas, mientras que la validación final sigue siendo local y verificable.
PajaritoBTC
¿Por qué una salida de Bitcoin puede ser válida y, aun así, resultar poco práctica?
La respuesta suele estar en el concepto de dust. Una salida es dust cuando su valor es tan pequeño, comparado con el coste estimado de gastarla, que transmitirla y confirmarla puede costar más que lo que contiene.
El umbral no depende solo de una cifra universal: considera cuánto espacio ocuparía la transacción al gastar esa salida y una tarifa de referencia definida por la política de relay. Por eso puede variar según el tipo de script y las reglas operativas del nodo.
Aquí conviene separar capas. Dust es principalmente una política para aceptar y retransmitir transacciones; no significa que una salida ya confirmada desaparezca automáticamente ni que sea imposible gastarla bajo cualquier circunstancia. Un minero podría incluir una transacción válida aunque un nodo no la retransmita por política.
La consecuencia es que dividir demasiado un pago puede crear muchas salidas pequeñas, difíciles o caras de gastar después. La wallet debe equilibrar precisión, comisiones futuras y tamaño de la transacción, no solo repartir el importe.
Entender dust ayuda a ver que “válido” y “económicamente práctico” son preguntas distintas: el consenso decide si el gasto cumple las reglas; la política de relay intenta evitar que la red transporte salidas cuyo coste de uso resulta desproporcionado.
La respuesta suele estar en el concepto de dust. Una salida es dust cuando su valor es tan pequeño, comparado con el coste estimado de gastarla, que transmitirla y confirmarla puede costar más que lo que contiene.
El umbral no depende solo de una cifra universal: considera cuánto espacio ocuparía la transacción al gastar esa salida y una tarifa de referencia definida por la política de relay. Por eso puede variar según el tipo de script y las reglas operativas del nodo.
Aquí conviene separar capas. Dust es principalmente una política para aceptar y retransmitir transacciones; no significa que una salida ya confirmada desaparezca automáticamente ni que sea imposible gastarla bajo cualquier circunstancia. Un minero podría incluir una transacción válida aunque un nodo no la retransmita por política.
La consecuencia es que dividir demasiado un pago puede crear muchas salidas pequeñas, difíciles o caras de gastar después. La wallet debe equilibrar precisión, comisiones futuras y tamaño de la transacción, no solo repartir el importe.
Entender dust ayuda a ver que “válido” y “económicamente práctico” son preguntas distintas: el consenso decide si el gasto cumple las reglas; la política de relay intenta evitar que la red transporte salidas cuyo coste de uso resulta desproporcionado.
PajaritoBTC
¿Qué comprueba realmente un nodo cuando un gasto Taproot usa una rama de script?
La salida contiene una clave pública x-only: solo se transmite la coordenada X, mientras que la paridad queda implícita. Esa clave no es necesariamente la del participante. En BIP341 se obtiene ajustando una clave interna con el hash comprometido del árbol de scripts. El resultado es la output key que aparece en el scriptPubKey.
En un gasto por script, el testigo incluye la hoja ejecutada, sus argumentos y un control block. Este aporta la clave interna, el bit de paridad de la output key y los hashes hermanos necesarios para reconstruir la raíz de Merkle. El nodo calcula el tweak, recupera la clave de salida y comprueba que coincide con la salida que se está gastando; después valida el script con la versión y el leaf version correspondientes.
La paridad no es decoración: permite seleccionar la representación correcta de la clave pública resultante. Si falla el tweak, la raíz, la paridad o la ejecución del script, el gasto no cumple consenso. La wallet prepara estos datos; relay puede aplicar políticas adicionales, pero no redefine la prueba. La consecuencia es que Taproot no revela todo el árbol: demuestra criptográficamente que la rama publicada pertenecía al compromiso correcto.
La salida contiene una clave pública x-only: solo se transmite la coordenada X, mientras que la paridad queda implícita. Esa clave no es necesariamente la del participante. En BIP341 se obtiene ajustando una clave interna con el hash comprometido del árbol de scripts. El resultado es la output key que aparece en el scriptPubKey.
En un gasto por script, el testigo incluye la hoja ejecutada, sus argumentos y un control block. Este aporta la clave interna, el bit de paridad de la output key y los hashes hermanos necesarios para reconstruir la raíz de Merkle. El nodo calcula el tweak, recupera la clave de salida y comprueba que coincide con la salida que se está gastando; después valida el script con la versión y el leaf version correspondientes.
La paridad no es decoración: permite seleccionar la representación correcta de la clave pública resultante. Si falla el tweak, la raíz, la paridad o la ejecución del script, el gasto no cumple consenso. La wallet prepara estos datos; relay puede aplicar políticas adicionales, pero no redefine la prueba. La consecuencia es que Taproot no revela todo el árbol: demuestra criptográficamente que la rama publicada pertenecía al compromiso correcto.
PajaritoBTC
La mempool de Bitcoin no es una sala de espera única. Cada nodo mantiene su propia lista de transacciones pendientes y puede verla distinta a la de otros nodos. La red comparte información, pero la confirmación llega cuando una transacción entra en un bloque.
PajaritoBTC
¿Cómo verifica un nodo que los datos witness de un bloque pertenecen realmente a las transacciones que lo forman?
SegWit introdujo una segunda huella: el wtxid. A diferencia del txid tradicional, el wtxid sí incluye el witness, como las firmas. El bloque construye un árbol de Merkle con esos identificadores y obtiene una raíz de testigos.
Esa raíz no aparece directamente en el encabezado. El minero la combina con un valor reservado de 32 bytes y calcula un compromiso mediante doble SHA-256. Después coloca el resultado en una salida OP_RETURN de la transacción coinbase, normalmente identificable por el prefijo de compromiso witness.
Al validar el bloque, el nodo reconstruye los wtxid, calcula la raíz, recupera el valor reservado del witness coinbase y comprueba que el compromiso coincide. Si no coincide, el bloque no es válido bajo las reglas de consenso de SegWit. No basta con que sus transacciones tengan firmas correctas por separado.
Hay límites y excepciones importantes. La coinbase no tiene una entrada normal y su propio wtxid se trata especialmente al construir el árbol. Además, el compromiso no demuestra que una transacción haya sido retransmitida antes ni obliga a un minero a elegir determinado conjunto de transacciones: relay y minería siguen siendo políticas y decisiones operativas.
La consecuencia es una separación limpia: el encabezado compromete la estructura principal del bloque y la coinbase ancla los witness. Así, los datos segregados no quedan fuera de la integridad verificable del bloque; se comprometen mediante una ruta adicional que cualquier nodo puede recalcular sin confiar en el minero. #PajaritoBTC
SegWit introdujo una segunda huella: el wtxid. A diferencia del txid tradicional, el wtxid sí incluye el witness, como las firmas. El bloque construye un árbol de Merkle con esos identificadores y obtiene una raíz de testigos.
Esa raíz no aparece directamente en el encabezado. El minero la combina con un valor reservado de 32 bytes y calcula un compromiso mediante doble SHA-256. Después coloca el resultado en una salida OP_RETURN de la transacción coinbase, normalmente identificable por el prefijo de compromiso witness.
Al validar el bloque, el nodo reconstruye los wtxid, calcula la raíz, recupera el valor reservado del witness coinbase y comprueba que el compromiso coincide. Si no coincide, el bloque no es válido bajo las reglas de consenso de SegWit. No basta con que sus transacciones tengan firmas correctas por separado.
Hay límites y excepciones importantes. La coinbase no tiene una entrada normal y su propio wtxid se trata especialmente al construir el árbol. Además, el compromiso no demuestra que una transacción haya sido retransmitida antes ni obliga a un minero a elegir determinado conjunto de transacciones: relay y minería siguen siendo políticas y decisiones operativas.
La consecuencia es una separación limpia: el encabezado compromete la estructura principal del bloque y la coinbase ancla los witness. Así, los datos segregados no quedan fuera de la integridad verificable del bloque; se comprometen mediante una ruta adicional que cualquier nodo puede recalcular sin confiar en el minero. #PajaritoBTC
PajaritoBTC
¿Qué pasa si dos mineros encuentran un bloque casi al mismo tiempo? Los nodos pueden recibir ambas versiones. Después siguen la cadena con más trabajo acumulado; la otra queda fuera del historial principal y sus transacciones pueden volver a esperar. #PajaritoBTC
PajaritoBTC
¿Qué está firmando exactamente una firma de Bitcoin? No firma «la transacción» como una pieza indivisible: firma un resumen definido por SIGHASH, y ese resumen puede cubrir más o menos partes del gasto.
En el caso habitual SIGHASH_ALL, la firma compromete las entradas y las salidas. Así, cambiar el destinatario, el importe de una salida o una entrada suele invalidarla. El campo sighash de cada entrada permite elegir excepciones: NONE omite las salidas; SINGLE compromete solo una salida correspondiente —con reglas históricas peculiares si no existe—; ANYONECANPAY limita el compromiso a la entrada firmada.
SegWit cambió además qué datos entran en el cálculo. Para una entrada SegWit v0, el digest incluye el importe del UTXO gastado y usa hashes compartidos de prevouts, secuencias y salidas. Esto evita la maleabilidad de las firmas anterior y reduce el coste de recalcular datos repetidos. La wallet debe conocer el importe exacto: no basta con tener la referencia del UTXO.
La separación de capas importa. SIGHASH es una regla de consenso para validar firmas; la wallet decide qué modo construir; el relay no convierte una firma parcial en válida; y un minero solo puede incluir la transacción si todas sus firmas satisfacen el compromiso elegido.
La consecuencia es que una firma no significa simplemente «autorizo cualquier versión». Significa «autorizo esta combinación concreta de datos», según el tipo SIGHASH. Los modificadores permiten construir transacciones colaborativas, pero también reducen qué cambios quedan protegidos. Leer el digest es entender el límite exacto de la autorización. #PajaritoBTC
En el caso habitual SIGHASH_ALL, la firma compromete las entradas y las salidas. Así, cambiar el destinatario, el importe de una salida o una entrada suele invalidarla. El campo sighash de cada entrada permite elegir excepciones: NONE omite las salidas; SINGLE compromete solo una salida correspondiente —con reglas históricas peculiares si no existe—; ANYONECANPAY limita el compromiso a la entrada firmada.
SegWit cambió además qué datos entran en el cálculo. Para una entrada SegWit v0, el digest incluye el importe del UTXO gastado y usa hashes compartidos de prevouts, secuencias y salidas. Esto evita la maleabilidad de las firmas anterior y reduce el coste de recalcular datos repetidos. La wallet debe conocer el importe exacto: no basta con tener la referencia del UTXO.
La separación de capas importa. SIGHASH es una regla de consenso para validar firmas; la wallet decide qué modo construir; el relay no convierte una firma parcial en válida; y un minero solo puede incluir la transacción si todas sus firmas satisfacen el compromiso elegido.
La consecuencia es que una firma no significa simplemente «autorizo cualquier versión». Significa «autorizo esta combinación concreta de datos», según el tipo SIGHASH. Los modificadores permiten construir transacciones colaborativas, pero también reducen qué cambios quedan protegidos. Leer el digest es entender el límite exacto de la autorización. #PajaritoBTC