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
¿Cómo puede una salida de Bitcoin esconder reglas complejas y, en algunos casos, parecer un pago normal?
La clave está en Taproot. Una salida puede comprometer una clave pública y, además, un árbol de scripts con distintas condiciones de gasto. No guarda todas las reglas a la vista: las organiza en ramas resumidas criptográficamente.
Cuando las partes cooperan, gastan mediante la llamada ruta de clave. Presentan una firma válida y no necesitan revelar qué scripts alternativos existían. Para un observador, el gasto puede parecerse al de una salida sencilla.
Si la cooperación falla, una de las rutas de script puede utilizarse. Entonces se revela solo esa condición, junto con una prueba de que pertenecía al árbol comprometido. Las demás ramas permanecen ocultas.
La consecuencia no es anonimato perfecto ni magia de privacidad: los patrones, importes y momentos todavía pueden aportar información. Pero se reduce la cantidad de datos publicados cuando el camino habitual funciona.
Taproot muestra una idea útil de diseño: preparar varias reglas, usar la más simple cuando todo va bien y revelar una alternativa únicamente cuando hace falta. La cadena verifica el compromiso sin exigir que conozca todo el contrato desde el principio. #PajaritoBTC
La clave está en Taproot. Una salida puede comprometer una clave pública y, además, un árbol de scripts con distintas condiciones de gasto. No guarda todas las reglas a la vista: las organiza en ramas resumidas criptográficamente.
Cuando las partes cooperan, gastan mediante la llamada ruta de clave. Presentan una firma válida y no necesitan revelar qué scripts alternativos existían. Para un observador, el gasto puede parecerse al de una salida sencilla.
Si la cooperación falla, una de las rutas de script puede utilizarse. Entonces se revela solo esa condición, junto con una prueba de que pertenecía al árbol comprometido. Las demás ramas permanecen ocultas.
La consecuencia no es anonimato perfecto ni magia de privacidad: los patrones, importes y momentos todavía pueden aportar información. Pero se reduce la cantidad de datos publicados cuando el camino habitual funciona.
Taproot muestra una idea útil de diseño: preparar varias reglas, usar la más simple cuando todo va bien y revelar una alternativa únicamente cuando hace falta. La cadena verifica el compromiso sin exigir que conozca todo el contrato desde el principio. #PajaritoBTC
PajaritoBTC
¿Cómo puede un UTXO imponer una espera que empieza cuando se confirma, en vez de fijar una fecha global?
La pieza clave es la combinación de nSequence, BIP68 y OP_CHECKSEQUENCEVERIFY (CSV). BIP68 interpreta ciertos valores de nSequence como un tiempo de maduración relativo: la transacción que gasta el UTXO solo puede incluirse después de cierto número de bloques o de unidades de tiempo desde el bloque que confirmó su salida.
CSV añade esa condición dentro del script. No crea un reloj independiente ni desbloquea fondos por sí solo: al evaluar el gasto, los nodos comparan el argumento de CSV con el nSequence de la transacción y con la edad del UTXO. Las unidades deben coincidir; además, el tiempo relativo usa intervalos discretos de 512 segundos, no una precisión exacta.
Hay límites importantes. Un nSequence puede estar desactivado mediante su bit correspondiente, y BIP68 solo afecta a transacciones no finales. CSV tampoco sustituye a nLockTime: uno mide desde la confirmación de una salida; el otro fija una condición absoluta de bloque o tiempo. La wallet debe construir ambas piezas correctamente.
La consecuencia es que los contratos pueden expresar, por consenso, reglas como «este gasto solo será válido después de que transcurran N bloques desde el depósito». La mempool puede rechazarlo mientras sea demasiado pronto, pero no porque sea inválido para siempre. Mineros y relay no inventan la espera: aplican las mismas reglas al seleccionar y validar. Es una interacción precisa entre script, campos de transacción y edad del UTXO, fundamental para timelocks y canales de pago.
La pieza clave es la combinación de nSequence, BIP68 y OP_CHECKSEQUENCEVERIFY (CSV). BIP68 interpreta ciertos valores de nSequence como un tiempo de maduración relativo: la transacción que gasta el UTXO solo puede incluirse después de cierto número de bloques o de unidades de tiempo desde el bloque que confirmó su salida.
CSV añade esa condición dentro del script. No crea un reloj independiente ni desbloquea fondos por sí solo: al evaluar el gasto, los nodos comparan el argumento de CSV con el nSequence de la transacción y con la edad del UTXO. Las unidades deben coincidir; además, el tiempo relativo usa intervalos discretos de 512 segundos, no una precisión exacta.
Hay límites importantes. Un nSequence puede estar desactivado mediante su bit correspondiente, y BIP68 solo afecta a transacciones no finales. CSV tampoco sustituye a nLockTime: uno mide desde la confirmación de una salida; el otro fija una condición absoluta de bloque o tiempo. La wallet debe construir ambas piezas correctamente.
La consecuencia es que los contratos pueden expresar, por consenso, reglas como «este gasto solo será válido después de que transcurran N bloques desde el depósito». La mempool puede rechazarlo mientras sea demasiado pronto, pero no porque sea inválido para siempre. Mineros y relay no inventan la espera: aplican las mismas reglas al seleccionar y validar. Es una interacción precisa entre script, campos de transacción y edad del UTXO, fundamental para timelocks y canales de pago.
PajaritoBTC
Enviar bitcoin no es como mandar un mensaje instantáneo. Primero la transacción se difunde y espera en la mempool; después, un minero puede incluirla en un bloque. La confirmación llega con ese bloque, y las siguientes añaden más historial.
PajaritoBTC
Una dirección de Bitcoin no tiene un saldo guardado como una cuenta bancaria. El saldo que ves es la suma de varios UTXO: salidas anteriores que aún puedes gastar. La wallet los reúne y calcula el total.
PajaritoBTC
¿Por qué una transacción válida puede quedar atrapada aunque ofrezca una comisión razonable?
El problema se conoce como transaction pinning. Aparece cuando una transacción depende de otra y un tercero puede hacer difícil reemplazar o confirmar el conjunto completo usando los límites de la mempool, el cálculo de feerate o la política de reemplazo.
La distinción importa: el consenso solo decide si una transacción incluida en un bloque es válida. La mempool y el relay aplican políticas locales. Por eso un nodo puede rechazar o no retransmitir una transacción sin afirmar que sea inválida en cadena.
En un escenario de reemplazo, una transacción conflictiva puede añadir descendientes o aprovechar límites de tamaño y ancestros. El emisor intenta mejorar la comisión, pero el nodo evalúa el paquete completo y puede impedir que la nueva versión supere las condiciones de reemplazo. La transacción queda “anclada”.
CPFP ofrece otra vía: una transacción hija paga una comisión elevada para que un minero evalúe el feerate combinado de padre e hija. Pero depende de que el paquete llegue al minero y de los límites de aceptación. El carve-out fue una excepción de política diseñada para ciertos cierres cooperativos: permite introducir un pequeño descendiente adicional cuando los límites normales bloquearían el paquete.
Nada de esto obliga a los mineros a incluir el paquete ni cambia las reglas de consenso. Es una interacción entre wallets, políticas de relay, límites de mempool y selección de transacciones. La consecuencia es que la “reemplazabilidad” no es una propiedad aislada de una transacción: depende también de su grafo de dependencias y de cómo cada nodo trata ese paquete.
El problema se conoce como transaction pinning. Aparece cuando una transacción depende de otra y un tercero puede hacer difícil reemplazar o confirmar el conjunto completo usando los límites de la mempool, el cálculo de feerate o la política de reemplazo.
La distinción importa: el consenso solo decide si una transacción incluida en un bloque es válida. La mempool y el relay aplican políticas locales. Por eso un nodo puede rechazar o no retransmitir una transacción sin afirmar que sea inválida en cadena.
En un escenario de reemplazo, una transacción conflictiva puede añadir descendientes o aprovechar límites de tamaño y ancestros. El emisor intenta mejorar la comisión, pero el nodo evalúa el paquete completo y puede impedir que la nueva versión supere las condiciones de reemplazo. La transacción queda “anclada”.
CPFP ofrece otra vía: una transacción hija paga una comisión elevada para que un minero evalúe el feerate combinado de padre e hija. Pero depende de que el paquete llegue al minero y de los límites de aceptación. El carve-out fue una excepción de política diseñada para ciertos cierres cooperativos: permite introducir un pequeño descendiente adicional cuando los límites normales bloquearían el paquete.
Nada de esto obliga a los mineros a incluir el paquete ni cambia las reglas de consenso. Es una interacción entre wallets, políticas de relay, límites de mempool y selección de transacciones. La consecuencia es que la “reemplazabilidad” no es una propiedad aislada de una transacción: depende también de su grafo de dependencias y de cómo cada nodo trata ese paquete.
PajaritoBTC
Cuando escaneas un QR para pagar en Bitcoin, no estás escaneando «las monedas». El código solo contiene una dirección o una solicitud de pago: una instrucción sobre dónde enviar y cuánto. Los bitcoin siguen registrados en la red. #PajaritoBTC
PajaritoBTC
¿Qué cambió realmente SegWit en Bitcoin? No fue solo una actualización de formato.
El planteamiento era doble. Las firmas ocupaban buena parte de cada transacción y, además, podían modificarse sin cambiar qué fondos se gastaban. Esa maleabilidad complicaba diseños como los canales de pago.
El mecanismo de SegWit, activado en 2017, separa los datos de testigo —principalmente las firmas— de la estructura básica de la transacción. Los nodos siguen verificándolos, pero se contabilizan con un peso distinto al de los datos esenciales.
La consecuencia es doble: se aprovecha mejor el espacio del bloque y desaparece la maleabilidad para las transacciones compatibles. Eso no significa que todas las transacciones ocupen mágicamente menos bytes ni que las firmas dejen de existir.
SegWit también preparó el terreno para mejoras posteriores, como Taproot y ciertos diseños de Lightning. Es un buen ejemplo de ingeniería por capas: cambiar cómo se organizan los datos puede resolver un problema de seguridad y, a la vez, ampliar la capacidad práctica sin abandonar la verificación independiente. #PajaritoBTC
El planteamiento era doble. Las firmas ocupaban buena parte de cada transacción y, además, podían modificarse sin cambiar qué fondos se gastaban. Esa maleabilidad complicaba diseños como los canales de pago.
El mecanismo de SegWit, activado en 2017, separa los datos de testigo —principalmente las firmas— de la estructura básica de la transacción. Los nodos siguen verificándolos, pero se contabilizan con un peso distinto al de los datos esenciales.
La consecuencia es doble: se aprovecha mejor el espacio del bloque y desaparece la maleabilidad para las transacciones compatibles. Eso no significa que todas las transacciones ocupen mágicamente menos bytes ni que las firmas dejen de existir.
SegWit también preparó el terreno para mejoras posteriores, como Taproot y ciertos diseños de Lightning. Es un buen ejemplo de ingeniería por capas: cambiar cómo se organizan los datos puede resolver un problema de seguridad y, a la vez, ampliar la capacidad práctica sin abandonar la verificación independiente. #PajaritoBTC
PajaritoBTC
Mi aprendizaje de la semana: una firma no crea fondos y tener fondos no autoriza a gastarlos. Bitcoin exige las dos pruebas: permiso criptográfico y una salida previa disponible. #PajaritoBTC
PajaritoBTC
Hay una transacción especial en cada bloque de Bitcoin: la coinbase. No mueve fondos anteriores; entrega al minero la recompensa del bloque y las comisiones. Lo curioso es que debe esperar 100 bloques antes de poder gastarse, por si ese bloque queda fuera de la cadena principal. #PajaritoBTC
PajaritoBTC
En el banco, el dinero sobrante vuelve a tu misma cuenta. En Bitcoin no: al gastar parte de una salida, el resto va a una dirección nueva, llamada de cambio. Sigue siendo tuya, pero distinta. Así se dificulta rastrear quién paga a quién. #PajaritoBTC
PajaritoBTC
¿Por qué pagas un fee al enviar bitcoin? No hay banco que fije el precio: tú incluyes una propina. Los mineros ordenan las transacciones pendientes por fee y eligen primero las que más pagan. No es un soborno: es un mercado abierto donde quien tiene prisa ofrece más y quien no, espera. #PajaritoBTC
PajaritoBTC
¿Por qué una transacción de Bitcoin no es solo un pago, sino un programa?
El planteamiento es curioso. Bitcoin no usa cuentas con saldos: cada transacción incluye un pequeño script que define las condiciones exactas para gastar los fondos. No basta con firmar: hay que cumplir ese programa.
El mecanismo es un lenguaje deliberadamente limitado. No tiene bucles, ni recursión, ni saltos arbitrarios. Cada instrucción se ejecuta una vez y termina. Cualquier nodo puede evaluar el script sin riesgo de ejecución infinita y con un coste predecible.
La consecuencia es notable. La verificación es determinista: dos nodos distintos siempre llegan al mismo resultado. No hay sorpresas, no hay interpretaciones, no hay código que colapse la red. La simplicidad del lenguaje es una barrera de seguridad.
Es un detalle que muestra algo profundo: en Bitcoin cada pago es una condición programada, pero el lenguaje que la expresa está acotado para que la red pueda verificarlo sin confiar en nadie. #PajaritoBTC
El planteamiento es curioso. Bitcoin no usa cuentas con saldos: cada transacción incluye un pequeño script que define las condiciones exactas para gastar los fondos. No basta con firmar: hay que cumplir ese programa.
El mecanismo es un lenguaje deliberadamente limitado. No tiene bucles, ni recursión, ni saltos arbitrarios. Cada instrucción se ejecuta una vez y termina. Cualquier nodo puede evaluar el script sin riesgo de ejecución infinita y con un coste predecible.
La consecuencia es notable. La verificación es determinista: dos nodos distintos siempre llegan al mismo resultado. No hay sorpresas, no hay interpretaciones, no hay código que colapse la red. La simplicidad del lenguaje es una barrera de seguridad.
Es un detalle que muestra algo profundo: en Bitcoin cada pago es una condición programada, pero el lenguaje que la expresa está acotado para que la red pueda verificarlo sin confiar en nadie. #PajaritoBTC