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
¿Qué protege realmente una hardware wallet, y qué queda fuera de su alcance?
Su función principal es mantener la clave privada dentro del dispositivo y usarla allí para firmar. La wallet del ordenador o del móvil puede preparar una transacción, pero recibe la firma, no la clave. Así se reduce el riesgo de que un programa malicioso copie directamente el secreto desde ese equipo.
Pero firmar no significa comprender por ti. La aplicación puede mostrar una dirección o un importe engañosos; por eso importa revisar en la pantalla del propio dispositivo los datos que presenta antes de confirmar. La pantalla ayuda a detectar discrepancias, aunque no vuelve segura cualquier transacción ni garantiza que entiendas todas sus condiciones.
El dispositivo tampoco protege una frase de recuperación que alguien haya fotografiado, escrito en una web falsa o entregado a otra persona: quien obtiene esa copia puede reconstruir las claves. Y no evita que pierdas el dispositivo, que falle, que uses software comprometido o que autorices sin darte cuenta un gasto no deseado.
En síntesis: una hardware wallet protege sobre todo la clave frente a ciertos riesgos del ordenador conectado. No sustituye la verificación de lo que firmas ni protege los secretos que salen de su entorno. Su seguridad depende también de cómo se configura, se respalda y se usa.
Su función principal es mantener la clave privada dentro del dispositivo y usarla allí para firmar. La wallet del ordenador o del móvil puede preparar una transacción, pero recibe la firma, no la clave. Así se reduce el riesgo de que un programa malicioso copie directamente el secreto desde ese equipo.
Pero firmar no significa comprender por ti. La aplicación puede mostrar una dirección o un importe engañosos; por eso importa revisar en la pantalla del propio dispositivo los datos que presenta antes de confirmar. La pantalla ayuda a detectar discrepancias, aunque no vuelve segura cualquier transacción ni garantiza que entiendas todas sus condiciones.
El dispositivo tampoco protege una frase de recuperación que alguien haya fotografiado, escrito en una web falsa o entregado a otra persona: quien obtiene esa copia puede reconstruir las claves. Y no evita que pierdas el dispositivo, que falle, que uses software comprometido o que autorices sin darte cuenta un gasto no deseado.
En síntesis: una hardware wallet protege sobre todo la clave frente a ciertos riesgos del ordenador conectado. No sustituye la verificación de lo que firmas ni protege los secretos que salen de su entorno. Su seguridad depende también de cómo se configura, se respalda y se usa.
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
¿Qué autoriza exactamente una firma de Bitcoin?
No siempre cubre toda la transacción. El campo sighash define qué partes quedan comprometidas. SIGHASH_ALL, el caso habitual, firma todas las entradas y salidas. SIGHASH_NONE firma las entradas, pero deja abiertas las salidas; SIGHASH_SINGLE firma una entrada y su salida correspondiente. ANYONECANPAY modifica el alcance sobre las entradas: la firma cubre solo la entrada desde la que se genera.
Los flags pueden combinarse. Por ejemplo, SINGLE|ANYONECANPAY permite que alguien autorice su propia entrada y una salida concreta, mientras otras partes de la transacción quedan abiertas para participantes adicionales. Esto resulta útil en protocolos colaborativos, pero exige analizar también índices, importes y condiciones.
Hay un límite importante: “no cubierto por la firma” no significa “ignorado por consenso”. Cuando un nodo recibe la transacción completa, sigue comprobando que cada entrada gasta un UTXO existente, que no hay doble gasto, que los scripts se satisfacen y que los valores no crean bitcoins. Una parte modificable debe seguir formando una transacción válida.
La política de relay puede rechazar ciertas combinaciones o transacciones no estándar; la minería decide qué transacciones intenta incluir. Ninguna política amplía la autorización criptográfica ni permite violar el consenso. La wallet, por su parte, debe construir el preimagen exacto y advertir qué componentes quedan deliberadamente abiertos.
La consecuencia: una firma no siempre dice “apruebo esta transacción completa”, sino “apruebo este compromiso concreto sobre ella”. La flexibilidad permite coordinar gastos entre partes, pero también hace peligroso interpretar una firma sin conocer su sighash.
No siempre cubre toda la transacción. El campo sighash define qué partes quedan comprometidas. SIGHASH_ALL, el caso habitual, firma todas las entradas y salidas. SIGHASH_NONE firma las entradas, pero deja abiertas las salidas; SIGHASH_SINGLE firma una entrada y su salida correspondiente. ANYONECANPAY modifica el alcance sobre las entradas: la firma cubre solo la entrada desde la que se genera.
Los flags pueden combinarse. Por ejemplo, SINGLE|ANYONECANPAY permite que alguien autorice su propia entrada y una salida concreta, mientras otras partes de la transacción quedan abiertas para participantes adicionales. Esto resulta útil en protocolos colaborativos, pero exige analizar también índices, importes y condiciones.
Hay un límite importante: “no cubierto por la firma” no significa “ignorado por consenso”. Cuando un nodo recibe la transacción completa, sigue comprobando que cada entrada gasta un UTXO existente, que no hay doble gasto, que los scripts se satisfacen y que los valores no crean bitcoins. Una parte modificable debe seguir formando una transacción válida.
La política de relay puede rechazar ciertas combinaciones o transacciones no estándar; la minería decide qué transacciones intenta incluir. Ninguna política amplía la autorización criptográfica ni permite violar el consenso. La wallet, por su parte, debe construir el preimagen exacto y advertir qué componentes quedan deliberadamente abiertos.
La consecuencia: una firma no siempre dice “apruebo esta transacción completa”, sino “apruebo este compromiso concreto sobre ella”. La flexibilidad permite coordinar gastos entre partes, pero también hace peligroso interpretar una firma sin conocer su sighash.
PajaritoBTC
¿Cómo decide una wallet qué monedas gastar si Bitcoin no tiene saldos de cuenta?
La wallet trabaja con UTXO: salidas recibidas que siguen sin gastarse. Para pagar, debe seleccionar una combinación cuyo valor cubra el importe enviado y la comisión. Esa elección se llama coin selection.
Si las monedas elegidas suman más de lo necesario, la transacción crea una salida de cambio hacia otra dirección controlada por la wallet. Ese cambio no es un detalle contable externo: se convierte en un nuevo UTXO que podrá gastarse después.
La selección busca equilibrar objetivos distintos: evitar demasiadas entradas, reducir el tamaño de la transacción, consolidar UTXO pequeños o preservar otros para futuros pagos. No existe una combinación universalmente mejor; depende de las reglas y prioridades de la wallet.
La consecuencia es importante: dos pagos del mismo importe pueden producir transacciones distintas porque parten de UTXO diferentes. También pueden tener comisiones distintas, ya que cada entrada añade datos y ocupa espacio.
Por eso, “tener fondos” no describe por sí solo cómo será un gasto. La wallet debe reunir piezas concretas, demostrar que puede desbloquearlas y crear el cambio siguiendo sus propias reglas. Los nodos validan el resultado; la estrategia de selección pertenece a la wallet.
La wallet trabaja con UTXO: salidas recibidas que siguen sin gastarse. Para pagar, debe seleccionar una combinación cuyo valor cubra el importe enviado y la comisión. Esa elección se llama coin selection.
Si las monedas elegidas suman más de lo necesario, la transacción crea una salida de cambio hacia otra dirección controlada por la wallet. Ese cambio no es un detalle contable externo: se convierte en un nuevo UTXO que podrá gastarse después.
La selección busca equilibrar objetivos distintos: evitar demasiadas entradas, reducir el tamaño de la transacción, consolidar UTXO pequeños o preservar otros para futuros pagos. No existe una combinación universalmente mejor; depende de las reglas y prioridades de la wallet.
La consecuencia es importante: dos pagos del mismo importe pueden producir transacciones distintas porque parten de UTXO diferentes. También pueden tener comisiones distintas, ya que cada entrada añade datos y ocupa espacio.
Por eso, “tener fondos” no describe por sí solo cómo será un gasto. La wallet debe reunir piezas concretas, demostrar que puede desbloquearlas y crear el cambio siguiendo sus propias reglas. Los nodos validan el resultado; la estrategia de selección pertenece a la wallet.
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 puede una dirección de Bitcoin representar un script sin mostrarlo todavía?
Con P2SH (Pay-to-Script-Hash), la salida no guarda directamente todas las condiciones de gasto. Guarda el hash de un redeemScript: el script que define qué debe cumplirse para gastar esos fondos.
Al recibir, basta con comprometerse con ese hash. El contenido del script puede permanecer fuera de la cadena hasta que alguien intente gastar. Por ejemplo, puede describir una multifirma, aunque la dirección no revela por sí sola cuántas firmas serán necesarias.
Al gastar, la transacción incluye el redeemScript y los datos necesarios para satisfacerlo. El nodo calcula de nuevo su hash y comprueba que coincide con el compromiso de la salida. Después ejecuta el script y verifica firmas, claves u otras condiciones.
La separación tiene una consecuencia importante: P2SH no hace que las reglas sean secretas para siempre. Las oculta mientras los fondos permanecen sin gastar, pero la rama utilizada y sus datos aparecen cuando se consume la salida.
P2SH también distingue dos momentos: quien recibe solo necesita conocer el hash, mientras quien gasta debe disponer del script correcto y cumplir sus condiciones. El hash no autoriza el gasto; únicamente identifica el conjunto de reglas comprometido.
La idea clave es sencilla: P2SH cambia qué se publica al recibir y qué se revela al gastar. Los nodos siguen validando todas las condiciones, pero la salida inicial puede ser compacta y no necesita exponer de antemano el diseño completo del script.
Con P2SH (Pay-to-Script-Hash), la salida no guarda directamente todas las condiciones de gasto. Guarda el hash de un redeemScript: el script que define qué debe cumplirse para gastar esos fondos.
Al recibir, basta con comprometerse con ese hash. El contenido del script puede permanecer fuera de la cadena hasta que alguien intente gastar. Por ejemplo, puede describir una multifirma, aunque la dirección no revela por sí sola cuántas firmas serán necesarias.
Al gastar, la transacción incluye el redeemScript y los datos necesarios para satisfacerlo. El nodo calcula de nuevo su hash y comprueba que coincide con el compromiso de la salida. Después ejecuta el script y verifica firmas, claves u otras condiciones.
La separación tiene una consecuencia importante: P2SH no hace que las reglas sean secretas para siempre. Las oculta mientras los fondos permanecen sin gastar, pero la rama utilizada y sus datos aparecen cuando se consume la salida.
P2SH también distingue dos momentos: quien recibe solo necesita conocer el hash, mientras quien gasta debe disponer del script correcto y cumplir sus condiciones. El hash no autoriza el gasto; únicamente identifica el conjunto de reglas comprometido.
La idea clave es sencilla: P2SH cambia qué se publica al recibir y qué se revela al gastar. Los nodos siguen validando todas las condiciones, pero la salida inicial puede ser compacta y no necesita exponer de antemano el diseño completo del script.
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
¿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
¿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
¿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.