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
¿Puede una transacción estar firmada y, aun así, no poder incluirse todavía en un bloque?
Sí. Bitcoin tiene mecanismos de tiempo que retrasan la validez de un gasto. nLockTime fija una condición absoluta: la transacción no puede confirmarse antes de una altura de bloque o, en ciertos casos, de una marca temporal. La condición se evalúa respecto a la cadena, no al reloj de una wallet.
nSequence permite otra clase de bloqueo: el relativo. Una entrada puede exigir que transcurra cierto número de bloques o tiempo desde la confirmación de la transacción que creó el UTXO. Esto resulta útil para pagos condicionados, canales y protocolos que necesitan una ventana de espera.
Firmar la transacción no elimina esas restricciones. La firma demuestra autorización sobre una operación concreta, pero los nodos también comprueban si se cumple el bloqueo y si el UTXO sigue disponible. Antes de ser válida para un bloque, puede permanecer fuera de la mempool o ser rechazada por la política local.
La consecuencia es importante: “preparada” no significa “confirmable”. Los bloqueos temporales forman parte de las reglas que coordinan qué puede gastar cada transacción y cuándo. No dependen de que un minero acepte esperar: si el bloqueo todavía no se cumple, el bloque que la incluya será inválido.
Sí. Bitcoin tiene mecanismos de tiempo que retrasan la validez de un gasto. nLockTime fija una condición absoluta: la transacción no puede confirmarse antes de una altura de bloque o, en ciertos casos, de una marca temporal. La condición se evalúa respecto a la cadena, no al reloj de una wallet.
nSequence permite otra clase de bloqueo: el relativo. Una entrada puede exigir que transcurra cierto número de bloques o tiempo desde la confirmación de la transacción que creó el UTXO. Esto resulta útil para pagos condicionados, canales y protocolos que necesitan una ventana de espera.
Firmar la transacción no elimina esas restricciones. La firma demuestra autorización sobre una operación concreta, pero los nodos también comprueban si se cumple el bloqueo y si el UTXO sigue disponible. Antes de ser válida para un bloque, puede permanecer fuera de la mempool o ser rechazada por la política local.
La consecuencia es importante: “preparada” no significa “confirmable”. Los bloqueos temporales forman parte de las reglas que coordinan qué puede gastar cada transacción y cuándo. No dependen de que un minero acepte esperar: si el bloqueo todavía no se cumple, el bloque que la incluya será inválido.
PajaritoBTC
La comisión de Bitcoin se parece al franqueo de una carta: no depende de cuánto dinero envías, sino del espacio que ocupa tu transacción y de la demanda de espacio en los bloques. Pagar más puede hacerla más atractiva para incluirla, pero no garantiza una confirmación inmediata.
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
¿Cómo puede un nodo aplicar un bloque y, si aparece una reorganización, deshacerlo sin reconstruir toda la cadena?
Al conectar un bloque, el nodo valida cada transacción contra una vista del conjunto UTXO. Consume las salidas referenciadas, crea las nuevas y registra los datos necesarios para revertir esos cambios. La vista puede combinar la base de datos persistente con capas de caché en memoria: no todo cambio se escribe inmediatamente en disco.
Los datos undo guardan, entre otras cosas, la información de los UTXO gastados que ya no estaría disponible después de conectar el bloque. Si la cadena activa cambia, el nodo desconecta bloques en orden inverso: elimina sus salidas creadas y restaura las salidas consumidas usando esos datos. Después conecta la rama alternativa aplicando de nuevo las reglas.
La condición importante es que undo no decide qué rama es válida ni sustituye la verificación. Solo conserva información operativa para deshacer una transición de estado ya validada. El consenso sigue comprobando entradas, scripts, valores, coinbase, peso y prueba de trabajo; la política de relay y la minería no cambian esta mecánica.
Hay límites: si faltan o se corrompen datos undo, el nodo puede necesitar reconstruirlos o recurrir a una restauración más costosa. Además, una reorganización no “devuelve” automáticamente una transacción a la mempool: su aceptación depende de que siga siendo válida y de las políticas locales.
La consecuencia es precisa: el conjunto UTXO es un estado mutable asociado a la cadena activa, no una lista irreversible. Las cachés aceleran la actualización y undo hace posible retroceder de forma eficiente; la seguridad continúa dependiendo de que cada transición haya sido validada según consenso.
Al conectar un bloque, el nodo valida cada transacción contra una vista del conjunto UTXO. Consume las salidas referenciadas, crea las nuevas y registra los datos necesarios para revertir esos cambios. La vista puede combinar la base de datos persistente con capas de caché en memoria: no todo cambio se escribe inmediatamente en disco.
Los datos undo guardan, entre otras cosas, la información de los UTXO gastados que ya no estaría disponible después de conectar el bloque. Si la cadena activa cambia, el nodo desconecta bloques en orden inverso: elimina sus salidas creadas y restaura las salidas consumidas usando esos datos. Después conecta la rama alternativa aplicando de nuevo las reglas.
La condición importante es que undo no decide qué rama es válida ni sustituye la verificación. Solo conserva información operativa para deshacer una transición de estado ya validada. El consenso sigue comprobando entradas, scripts, valores, coinbase, peso y prueba de trabajo; la política de relay y la minería no cambian esta mecánica.
Hay límites: si faltan o se corrompen datos undo, el nodo puede necesitar reconstruirlos o recurrir a una restauración más costosa. Además, una reorganización no “devuelve” automáticamente una transacción a la mempool: su aceptación depende de que siga siendo válida y de las políticas locales.
La consecuencia es precisa: el conjunto UTXO es un estado mutable asociado a la cadena activa, no una lista irreversible. Las cachés aceleran la actualización y undo hace posible retroceder de forma eficiente; la seguridad continúa dependiendo de que cada transición haya sido validada según consenso.
PajaritoBTC
¿Por qué una transacción de Bitcoin puede tener dos identificadores relacionados: TXID y wTXID?
El TXID es el hash de la transacción serializada sin los datos witness, como las firmas SegWit. El wTXID incluye también ese witness. La separación permite distinguir la estructura principal del gasto de los datos usados para autorizarlo.
Antes de SegWit, ciertos cambios en la forma de representar una firma podían modificar el identificador sin cambiar qué se gastaba ni quién recibía. Esa maleabilidad complicaba construir transacciones que dependieran del TXID de otra aún no confirmada.
Con SegWit, el TXID queda separado de las firmas witness. Una modificación válida del witness puede cambiar el wTXID, pero no el TXID de la transacción. Esto no significa que cualquier dato pueda alterarse: la transacción debe seguir cumpliendo las reglas y las firmas deben ser válidas.
La consecuencia es práctica: los protocolos pueden referirse con más estabilidad a una transacción padre mediante su TXID, mientras el wTXID sirve para identificar la versión completa que incluye el witness. Aun así, las wallets y los nodos deben manejar ambos identificadores correctamente.
La idea clave es que no son dos transacciones distintas. Son dos hashes sobre representaciones distintas de la misma operación. SegWit no elimina la necesidad de validar firmas; reorganiza qué datos forman parte del identificador principal y mejora la estabilidad de las dependencias entre transacciones.
El TXID es el hash de la transacción serializada sin los datos witness, como las firmas SegWit. El wTXID incluye también ese witness. La separación permite distinguir la estructura principal del gasto de los datos usados para autorizarlo.
Antes de SegWit, ciertos cambios en la forma de representar una firma podían modificar el identificador sin cambiar qué se gastaba ni quién recibía. Esa maleabilidad complicaba construir transacciones que dependieran del TXID de otra aún no confirmada.
Con SegWit, el TXID queda separado de las firmas witness. Una modificación válida del witness puede cambiar el wTXID, pero no el TXID de la transacción. Esto no significa que cualquier dato pueda alterarse: la transacción debe seguir cumpliendo las reglas y las firmas deben ser válidas.
La consecuencia es práctica: los protocolos pueden referirse con más estabilidad a una transacción padre mediante su TXID, mientras el wTXID sirve para identificar la versión completa que incluye el witness. Aun así, las wallets y los nodos deben manejar ambos identificadores correctamente.
La idea clave es que no son dos transacciones distintas. Son dos hashes sobre representaciones distintas de la misma operación. SegWit no elimina la necesidad de validar firmas; reorganiza qué datos forman parte del identificador principal y mejora la estabilidad de las dependencias entre transacciones.
PajaritoBTC
¿Qué significa que un pago de Bitcoin esté «pendiente»? Que la transacción ha sido difundida y puede estar en la mempool, la sala de espera de los nodos. Todavía no forma parte de un bloque. Cuando un minero la incluye y los nodos validan ese bloque, queda confirmada. Pendiente no es lo mismo que definitivo.
PajaritoBTC
¿Sabías que…? La recompensa del bloque génesis —el primero de Bitcoin— no puede gastarse como una coinbase normal. Aunque aparece en el bloque, los nodos no la incorporan al conjunto UTXO: es una pieza histórica, no un saldo disponible.
PajaritoBTC
¿Qué demuestra exactamente un gasto Taproot cuando una salida P2TR aparece en la cadena?
La salida contiene un punto público ajustado: la clave interna se combina con un tweak derivado de esa clave y, si existe, de la raíz de un árbol de scripts. El scriptPubKey no revela las ramas posibles; compromete su raíz mediante ese ajuste.
Hay dos rutas de gasto. En key path, el firmante demuestra conocimiento de la clave privada ajustada mediante una firma Schnorr. No necesita revelar qué scripts estaban comprometidos. En script path, publica el script ejecutado, una prueba de Merkle que demuestra que pertenece al árbol y un control block con la clave interna y los datos necesarios para reconstruir la clave ajustada.
La condición que conecta las piezas es criptográfica y de consenso: el nodo recalcula el tweak, comprueba que coincide con la clave de la salida y verifica la firma o la ejecución del script según la ruta elegida. Si falla cualquiera de esos pasos, la entrada es inválida aunque la wallet conozca una rama correcta.
El límite importante es que Taproot no convierte cualquier script en válido ni hace invisible todo el gasto. La ruta script revela la rama usada y sus datos; las ramas no usadas permanecen ocultas. Además, los límites de tamaño, las reglas de Tapscript y la interpretación de los leaf versions siguen siendo reglas de consenso. La política de relay puede ser más restrictiva, pero no define la validez final.
Una wallet puede preferir key path, seleccionar una rama concreta o construir el árbol de forma que ciertas ramas resulten más costosas de revelar. Eso es comportamiento de wallet, no una propiedad que los nodos puedan inferir siempre.
La consecuencia es precisa: Taproot separa el compromiso previo de la revelación posterior. La salida fija una clave y, opcionalmente, un árbol; el gasto revela solo la evidencia necesaria para satisfacer una ruta. La privacidad y el ahorro de datos dependen de cómo se diseñen y utilicen esas rutas, mientras la validez continúa siendo verificable por cualquier nodo.
La salida contiene un punto público ajustado: la clave interna se combina con un tweak derivado de esa clave y, si existe, de la raíz de un árbol de scripts. El scriptPubKey no revela las ramas posibles; compromete su raíz mediante ese ajuste.
Hay dos rutas de gasto. En key path, el firmante demuestra conocimiento de la clave privada ajustada mediante una firma Schnorr. No necesita revelar qué scripts estaban comprometidos. En script path, publica el script ejecutado, una prueba de Merkle que demuestra que pertenece al árbol y un control block con la clave interna y los datos necesarios para reconstruir la clave ajustada.
La condición que conecta las piezas es criptográfica y de consenso: el nodo recalcula el tweak, comprueba que coincide con la clave de la salida y verifica la firma o la ejecución del script según la ruta elegida. Si falla cualquiera de esos pasos, la entrada es inválida aunque la wallet conozca una rama correcta.
El límite importante es que Taproot no convierte cualquier script en válido ni hace invisible todo el gasto. La ruta script revela la rama usada y sus datos; las ramas no usadas permanecen ocultas. Además, los límites de tamaño, las reglas de Tapscript y la interpretación de los leaf versions siguen siendo reglas de consenso. La política de relay puede ser más restrictiva, pero no define la validez final.
Una wallet puede preferir key path, seleccionar una rama concreta o construir el árbol de forma que ciertas ramas resulten más costosas de revelar. Eso es comportamiento de wallet, no una propiedad que los nodos puedan inferir siempre.
La consecuencia es precisa: Taproot separa el compromiso previo de la revelación posterior. La salida fija una clave y, opcionalmente, un árbol; el gasto revela solo la evidencia necesaria para satisfacer una ruta. La privacidad y el ahorro de datos dependen de cómo se diseñen y utilicen esas rutas, mientras la validez continúa siendo verificable por cualquier nodo.
PajaritoBTC
¿Cómo pueden varias personas coordinar una transacción de Bitcoin sin compartir sus claves privadas? Una herramienta habitual es la PSBT, sigla de Partially Signed Bitcoin Transaction: transacción de Bitcoin parcialmente firmada.
Una PSBT contiene la estructura de la transacción y datos auxiliares, como los UTXO que se quieren gastar, pero no es todavía una transacción lista para la red. Puede pasar de una wallet a otra para que cada participante revise qué entradas y salidas están previstas.
Cada firmante comprueba su parte y añade su firma con la clave que controla. En un esquema multifirma, por ejemplo, varias personas pueden firmar por separado sin entregarse las claves privadas. Después, otra wallet combina las firmas y finaliza los datos necesarios para construir la transacción transmitible.
La PSBT no sustituye a la verificación. Antes de emitir el resultado, hay que comprobar destinatarios, importes, comisión, UTXO y que se hayan reunido las firmas exigidas por la condición de gasto. Una PSBT puede estar parcialmente firmada, ser incompatible con otra versión o contener datos que aún no permitan gastar.
La consecuencia es clara: separar preparación, firma y emisión reduce la necesidad de que una sola herramienta vea o controle todas las claves. Pero la seguridad no está en el archivo por sí solo, sino en revisar qué autoriza cada firma y en validar la transacción final antes de enviarla a la red.
Una PSBT contiene la estructura de la transacción y datos auxiliares, como los UTXO que se quieren gastar, pero no es todavía una transacción lista para la red. Puede pasar de una wallet a otra para que cada participante revise qué entradas y salidas están previstas.
Cada firmante comprueba su parte y añade su firma con la clave que controla. En un esquema multifirma, por ejemplo, varias personas pueden firmar por separado sin entregarse las claves privadas. Después, otra wallet combina las firmas y finaliza los datos necesarios para construir la transacción transmitible.
La PSBT no sustituye a la verificación. Antes de emitir el resultado, hay que comprobar destinatarios, importes, comisión, UTXO y que se hayan reunido las firmas exigidas por la condición de gasto. Una PSBT puede estar parcialmente firmada, ser incompatible con otra versión o contener datos que aún no permitan gastar.
La consecuencia es clara: separar preparación, firma y emisión reduce la necesidad de que una sola herramienta vea o controle todas las claves. Pero la seguridad no está en el archivo por sí solo, sino en revisar qué autoriza cada firma y en validar la transacción final antes de enviarla a la red.
PajaritoBTC
Cuando escaneas un QR para pagar con Bitcoin, el QR no envía nada por sí solo: solo comparte datos del destino y quizá el importe. Tu wallet aún debe crear y firmar la transacción antes de que los nodos la verifiquen.
PajaritoBTC
Una firma de Bitcoin no siempre compromete exactamente la misma información. El tipo de SIGHASH indica qué partes de la transacción quedan cubiertas por esa firma.
Con SIGHASH_ALL, la opción habitual, la firma compromete todas las entradas y todas las salidas. Si alguien cambia el destinatario, el importe o una entrada, la firma deja de ser válida.
Otros tipos permiten compromisos parciales. SIGHASH_NONE firma las entradas, pero no fija las salidas; SIGHASH_SINGLE vincula una entrada con la salida correspondiente. Combinados con ANYONECANPAY, también pueden limitar el compromiso a una entrada concreta.
Esto puede servir para construir transacciones de forma coordinada: varias partes aportan entradas o acuerdan salidas sin que una firma tenga que cubrir desde el principio el diseño completo. Pero la flexibilidad tiene un coste: una firma parcial deja partes abiertas a modificaciones previstas por ese tipo.
La consecuencia es importante: “está firmado” no significa necesariamente “cada byte de la transacción quedó fijado”. Para interpretar una firma hay que conocer su SIGHASH y comprobar qué autorizó exactamente. No es una puerta trasera ni una garantía ilimitada, sino una forma precisa de definir el alcance del compromiso.
Con SIGHASH_ALL, la opción habitual, la firma compromete todas las entradas y todas las salidas. Si alguien cambia el destinatario, el importe o una entrada, la firma deja de ser válida.
Otros tipos permiten compromisos parciales. SIGHASH_NONE firma las entradas, pero no fija las salidas; SIGHASH_SINGLE vincula una entrada con la salida correspondiente. Combinados con ANYONECANPAY, también pueden limitar el compromiso a una entrada concreta.
Esto puede servir para construir transacciones de forma coordinada: varias partes aportan entradas o acuerdan salidas sin que una firma tenga que cubrir desde el principio el diseño completo. Pero la flexibilidad tiene un coste: una firma parcial deja partes abiertas a modificaciones previstas por ese tipo.
La consecuencia es importante: “está firmado” no significa necesariamente “cada byte de la transacción quedó fijado”. Para interpretar una firma hay que conocer su SIGHASH y comprobar qué autorizó exactamente. No es una puerta trasera ni una garantía ilimitada, sino una forma precisa de definir el alcance del compromiso.