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
SegWit cambió cómo Bitcoin organiza las transacciones: separó las firmas (witness) del resto y les asignó menor peso al contar el bloque, permitiendo incluir más transacciones. Además, el txid dejó de depender de esas firmas: cambiar el witness ya no cambia ese identificador.
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
Consolidar UTXO es como reunir varios paquetes pequeños en uno: si la comisión de Bitcoin es baja, una wallet puede gastarlos juntos y crear una sola salida. Así, un pago futuro podría necesitar menos datos y costar menos; pagas ahora y el ahorro no está garantizado.
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
Esta semana encajaron dos ideas: Bitcoin guarda UTXO, no saldos, y la wallet decide qué piezas gastar y dónde enviar el cambio. Por eso cada pago puede afectar a tus comisiones y a la información que revelas. Entenderlo ayuda a usar Bitcoin con más criterio.
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
¿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 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
Bitcoin no guarda un saldo como el de una cuenta bancaria. Guarda piezas llamadas UTXO: salidas de transacciones que aún no se han gastado. Una transacción consume unas y crea otras. Cada UTXO solo puede gastarse una vez; por eso los nodos pueden detectar el doble gasto sin una autoridad central.
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
¿Sabías que…? Bitcoin puede incluir datos en una salida OP_RETURN, como una pequeña huella digital o un mensaje. Esa salida está diseñada para ser no gastable: si alguien envía satoshis allí, quedan bloqueados para siempre. Los datos viajan en la cadena, pero no crean un saldo disponible.