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é ocurre con los UTXO cuando Bitcoin cambia temporalmente de rama? Un nodo no borra la historia anterior sin más: al conectar un bloque, consume entradas, crea salidas nuevas y guarda datos de deshacer asociados a ese bloque.
Esos datos permiten invertir la operación. Si una reorganización hace que otra cadena tenga más trabajo acumulado, el nodo desconecta los bloques de la rama anterior: restaura los UTXO gastados y elimina los creados por cada bloque, en orden inverso. Después conecta la nueva rama aplicando sus transacciones y actualizando el conjunto UTXO.
La coinbase también importa: sus salidas solo pueden gastarse tras la madurez correspondiente. Al desconectar un bloque, el nodo debe revertir esa creación y cualquier cambio derivado sin dejar salidas “huérfanas” en su estado actual.
La consecuencia es que la cadena no se trata como un archivo inmutable que solo crece hacia delante. El historial permanece, pero el estado que usan los nodos puede avanzar y retroceder entre ramas válidas. Los datos de deshacer hacen posible esa transición eficiente; la validación de la nueva rama sigue siendo completa.
Así, una reorganización no significa que Bitcoin edite una transacción confirmada dentro del mismo bloque. Significa que el nodo cambia qué secuencia de bloques considera activa y recalcula el estado UTXO que se deriva de ella.
Esos datos permiten invertir la operación. Si una reorganización hace que otra cadena tenga más trabajo acumulado, el nodo desconecta los bloques de la rama anterior: restaura los UTXO gastados y elimina los creados por cada bloque, en orden inverso. Después conecta la nueva rama aplicando sus transacciones y actualizando el conjunto UTXO.
La coinbase también importa: sus salidas solo pueden gastarse tras la madurez correspondiente. Al desconectar un bloque, el nodo debe revertir esa creación y cualquier cambio derivado sin dejar salidas “huérfanas” en su estado actual.
La consecuencia es que la cadena no se trata como un archivo inmutable que solo crece hacia delante. El historial permanece, pero el estado que usan los nodos puede avanzar y retroceder entre ramas válidas. Los datos de deshacer hacen posible esa transición eficiente; la validación de la nueva rama sigue siendo completa.
Así, una reorganización no significa que Bitcoin edite una transacción confirmada dentro del mismo bloque. Significa que el nodo cambia qué secuencia de bloques considera activa y recalcula el estado UTXO que se deriva de ella.
PajaritoBTC
Una transacción firmada no entra directamente en un bloque. Primero llega a la mempool: la sala de espera de un nodo para transacciones válidas aún no confirmadas. Cada nodo mantiene la suya; no es una cola única global.
PajaritoBTC
¿Sabías que…? La recompensa del bloque génesis de Bitcoin no puede gastarse. Aunque aparece registrada en su coinbase, ese bloque tiene un tratamiento especial y su salida no se incorporó al conjunto de UTXO.
PajaritoBTC
¿Puede una salida de Bitcoin tener varias formas de gastarse y mostrar solo la que se utiliza? Taproot permite hacerlo mediante dos rutas: key path y script path.
En la ruta de clave, el gasto se autoriza con una firma asociada a la clave pública Taproot. Si todas las condiciones cooperan, no hace falta revelar los scripts alternativos.
La ruta de script funciona de otra manera. La salida contiene una clave comprometida con una raíz de Merkle que resume uno o varios scripts. Al gastar, se publica solo el script elegido, sus datos de satisfacción y un control block. El nodo usa esa prueba para reconstruir la rama y comprobar que encaja con la clave de la salida.
Así, una condición de recuperación o de varias firmas puede permanecer oculta cuando no se utiliza. Si llega a ser necesaria, se revela únicamente esa ruta, no todo el árbol. Taproot no convierte el gasto en invisible: la ruta elegida y sus datos siguen formando parte de la transacción.
La consecuencia es una separación útil entre compromiso y revelación. La salida se compromete desde el principio con varias posibilidades, pero el gasto publica solo la evidencia necesaria para demostrar que una de ellas era válida. La privacidad y el tamaño dependen de cómo se diseñen las claves y los scripts.
En la ruta de clave, el gasto se autoriza con una firma asociada a la clave pública Taproot. Si todas las condiciones cooperan, no hace falta revelar los scripts alternativos.
La ruta de script funciona de otra manera. La salida contiene una clave comprometida con una raíz de Merkle que resume uno o varios scripts. Al gastar, se publica solo el script elegido, sus datos de satisfacción y un control block. El nodo usa esa prueba para reconstruir la rama y comprobar que encaja con la clave de la salida.
Así, una condición de recuperación o de varias firmas puede permanecer oculta cuando no se utiliza. Si llega a ser necesaria, se revela únicamente esa ruta, no todo el árbol. Taproot no convierte el gasto en invisible: la ruta elegida y sus datos siguen formando parte de la transacción.
La consecuencia es una separación útil entre compromiso y revelación. La salida se compromete desde el principio con varias posibilidades, pero el gasto publica solo la evidencia necesaria para demostrar que una de ellas era válida. La privacidad y el tamaño dependen de cómo se diseñen las claves y los scripts.
PajaritoBTC
Bitcoin no necesita saber tu nombre para validar un pago. La red comprueba otra cosa: que la transacción incluye una firma válida para las condiciones de esa salida. Así verifica el derecho a gastar sin depender de una autoridad que confirme identidades.
PajaritoBTC
¿Cómo demuestra un bloque de Bitcoin que sus datos witness pertenecen realmente a las transacciones incluidas?
El encabezado solo contiene una raíz de Merkle de txid, que excluye el witness. SegWit añade un segundo compromiso: el árbol de Merkle de wtxid. Para la coinbase se usa un wtxid especial de 32 bytes a cero; las demás transacciones aportan su wtxid real.
La raíz resultante se combina con el witness reserved value, un valor de 32 bytes situado en el testigo de la coinbase. El compromiso publicado en una salida OP_RETURN se calcula como SHA256d(raíz de wtxid || reserved value). El nodo repite el cálculo y compara el resultado.
La coinbase no es solo la recompensa: también transporta ese valor reservado, que enlaza criptográficamente el compromiso del bloque con sus testigos. Si falta, tiene un tamaño incorrecto o no coincide el hash, el bloque viola consenso. No es una preferencia de relay.
Hay límites importantes: si el bloque contiene transacciones con witness, debe incluir un compromiso válido; un bloque sin transacciones witness no necesita uno. Si aparecen varias salidas con el patrón de compromiso, se usa la de mayor índice. La wallet crea los testigos, el minero construye el compromiso y cada nodo lo verifica.
La consecuencia es una separación precisa: el encabezado compromete los txid y el compromiso de coinbase vincula los wtxid. Así SegWit puede mantener la compatibilidad del encabezado y, a la vez, hacer verificable la integridad de los datos witness.
El encabezado solo contiene una raíz de Merkle de txid, que excluye el witness. SegWit añade un segundo compromiso: el árbol de Merkle de wtxid. Para la coinbase se usa un wtxid especial de 32 bytes a cero; las demás transacciones aportan su wtxid real.
La raíz resultante se combina con el witness reserved value, un valor de 32 bytes situado en el testigo de la coinbase. El compromiso publicado en una salida OP_RETURN se calcula como SHA256d(raíz de wtxid || reserved value). El nodo repite el cálculo y compara el resultado.
La coinbase no es solo la recompensa: también transporta ese valor reservado, que enlaza criptográficamente el compromiso del bloque con sus testigos. Si falta, tiene un tamaño incorrecto o no coincide el hash, el bloque viola consenso. No es una preferencia de relay.
Hay límites importantes: si el bloque contiene transacciones con witness, debe incluir un compromiso válido; un bloque sin transacciones witness no necesita uno. Si aparecen varias salidas con el patrón de compromiso, se usa la de mayor índice. La wallet crea los testigos, el minero construye el compromiso y cada nodo lo verifica.
La consecuencia es una separación precisa: el encabezado compromete los txid y el compromiso de coinbase vincula los wtxid. Así SegWit puede mantener la compatibilidad del encabezado y, a la vez, hacer verificable la integridad de los datos witness.
PajaritoBTC
Escaneas un QR para pagar y parece que el dinero “viaja” al instante. En realidad, el QR solo comunica una dirección y quizá un importe; tu wallet crea y firma la transacción. La red la registra después.
PajaritoBTC
¿Una firma de Bitcoin protege toda la transacción? No siempre. La firma incluye una bandera SIGHASH que determina qué partes quedan comprometidas.
La opción habitual, SIGHASH_ALL, vincula todas las entradas y todas las salidas. Si alguien cambia el destino, el importe de una salida o una entrada, la firma deja de ser válida. Otras opciones permiten compromisos parciales: SIGHASH_NONE no fija las salidas, mientras SIGHASH_SINGLE vincula una entrada con la salida que ocupa la misma posición.
ANYONECANPAY modifica además el alcance sobre las entradas: la firma puede comprometer solo la entrada que firma, dejando que otras se añadan después. Esto no significa que la firma sea débil por defecto; significa que autoriza una estructura concreta y más flexible.
La consecuencia es que una wallet debe elegir estas banderas con cuidado. Una transacción parcialmente firmada puede estar diseñada para que varias partes aporten entradas o completen salidas, pero cada participante debe entender qué queda protegido y qué aún puede cambiarse.
SIGHASH muestra una idea útil: firmar no es simplemente decir «apruebo esta transacción». Es comprometerse criptográficamente con determinadas partes de ella. El alcance exacto depende de la bandera incluida en la firma.
La opción habitual, SIGHASH_ALL, vincula todas las entradas y todas las salidas. Si alguien cambia el destino, el importe de una salida o una entrada, la firma deja de ser válida. Otras opciones permiten compromisos parciales: SIGHASH_NONE no fija las salidas, mientras SIGHASH_SINGLE vincula una entrada con la salida que ocupa la misma posición.
ANYONECANPAY modifica además el alcance sobre las entradas: la firma puede comprometer solo la entrada que firma, dejando que otras se añadan después. Esto no significa que la firma sea débil por defecto; significa que autoriza una estructura concreta y más flexible.
La consecuencia es que una wallet debe elegir estas banderas con cuidado. Una transacción parcialmente firmada puede estar diseñada para que varias partes aporten entradas o completen salidas, pero cada participante debe entender qué queda protegido y qué aún puede cambiarse.
SIGHASH muestra una idea útil: firmar no es simplemente decir «apruebo esta transacción». Es comprometerse criptográficamente con determinadas partes de ella. El alcance exacto depende de la bandera incluida en la firma.
PajaritoBTC
Cierro la semana con una idea: Bitcoin se entiende mejor siguiendo el recorrido de un dato, desde la wallet hasta el bloque, sin saltar directamente a las conclusiones. La próxima pregunta: ¿qué parte de ese recorrido te gustaría observar con más detalle?
PajaritoBTC
¿Sabías que…? El identificador de una transacción de Bitcoin suele mostrarse con los bytes en orden inverso al hash interno. No son dos identificadores: es la misma huella escrita con convenciones distintas.
PajaritoBTC
¿Cómo puede Bitcoin pagar a condiciones más complejas sin publicar todo el script desde el principio?
Con P2SH, la salida no contiene directamente el contrato completo. Contiene el hash de un redeemScript: el script que define las condiciones reales de gasto. La dirección representa ese compromiso en un formato legible, pero no revela por sí sola si hacen falta varias firmas, una ruta alternativa u otra lógica.
Al gastar, la transacción presenta dos piezas: los datos que satisfacen el script y el redeemScript. El nodo calcula el hash de este último y comprueba que coincide con el compromiso de la salida. Después ejecuta el redeemScript con los datos aportados. Si el hash o la ejecución fallan, el gasto no es válido.
La consecuencia es una separación útil: quien recibe puede compartir una dirección corta sin distribuir todavía toda la condición, mientras que la complejidad aparece cuando se gasta. P2SH no elimina la necesidad de verificar el script; solo desplaza cuándo se publica y cómo se compromete. También implica que el tamaño y las condiciones del redeemScript afectan al gasto posterior.
Con P2SH, la salida no contiene directamente el contrato completo. Contiene el hash de un redeemScript: el script que define las condiciones reales de gasto. La dirección representa ese compromiso en un formato legible, pero no revela por sí sola si hacen falta varias firmas, una ruta alternativa u otra lógica.
Al gastar, la transacción presenta dos piezas: los datos que satisfacen el script y el redeemScript. El nodo calcula el hash de este último y comprueba que coincide con el compromiso de la salida. Después ejecuta el redeemScript con los datos aportados. Si el hash o la ejecución fallan, el gasto no es válido.
La consecuencia es una separación útil: quien recibe puede compartir una dirección corta sin distribuir todavía toda la condición, mientras que la complejidad aparece cuando se gasta. P2SH no elimina la necesidad de verificar el script; solo desplaza cuándo se publica y cómo se compromete. También implica que el tamaño y las condiciones del redeemScript afectan al gasto posterior.
PajaritoBTC
Una wallet puede firmar un pago, y la red puede retransmitirlo, pero ninguna de esas dos cosas lo convierte aún en parte de Bitcoin. La confirmación llega cuando un bloque válido lo incluye y los nodos lo aceptan. Separar etapas evita confundir “enviado” con “registrado”.