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
Imagina una autorización firmada: demuestra que quien la firma tiene la llave adecuada, pero no entrega la llave. En Bitcoin, una firma digital prueba que puedes autorizar un gasto sin revelar tu clave privada. Los nodos comprueban la firma y las reglas antes de aceptarlo.
PajaritoBTC
¿Cómo decide una wallet qué monedas gastar cuando haces un pago? No elige una cifra de un saldo abstracto: selecciona UTXO concretos, cada uno con un valor y un historial.
La selección debe reunir suficiente valor para cubrir el importe enviado y la comisión. La wallet puede elegir pocos UTXO grandes, varios pequeños o una combinación intermedia. Cada entrada adicional suele aumentar el peso de la transacción, así que también puede elevar la comisión necesaria.
Después crea las salidas: pago, cambio y, de forma implícita, la comisión. Si el cambio es demasiado pequeño, algunas wallets prefieren evitar crear una salida que podría costar más en el futuro que su propio valor. Ese umbral se conoce como “dust” en ciertos contextos, aunque las políticas concretas pueden variar.
La elección también tiene una dimensión de privacidad. Juntar UTXO de contextos distintos puede sugerir que pertenecen al mismo control, mientras que gastar uno solo puede revelar menos relaciones, aunque ningún método garantice privacidad por sí mismo.
La consecuencia es útil: una wallet no solo “envía dinero”. Construye una transacción a partir de piezas verificables y debe equilibrar coste, cambio, consolidación y privacidad. Por eso dos pagos del mismo importe pueden producir transacciones diferentes.
La selección debe reunir suficiente valor para cubrir el importe enviado y la comisión. La wallet puede elegir pocos UTXO grandes, varios pequeños o una combinación intermedia. Cada entrada adicional suele aumentar el peso de la transacción, así que también puede elevar la comisión necesaria.
Después crea las salidas: pago, cambio y, de forma implícita, la comisión. Si el cambio es demasiado pequeño, algunas wallets prefieren evitar crear una salida que podría costar más en el futuro que su propio valor. Ese umbral se conoce como “dust” en ciertos contextos, aunque las políticas concretas pueden variar.
La elección también tiene una dimensión de privacidad. Juntar UTXO de contextos distintos puede sugerir que pertenecen al mismo control, mientras que gastar uno solo puede revelar menos relaciones, aunque ningún método garantice privacidad por sí mismo.
La consecuencia es útil: una wallet no solo “envía dinero”. Construye una transacción a partir de piezas verificables y debe equilibrar coste, cambio, consolidación y privacidad. Por eso dos pagos del mismo importe pueden producir transacciones diferentes.
PajaritoBTC
¿Sabías que…? En el árbol de Merkle de Bitcoin, si una capa tiene un número impar de hashes, el último se duplica para poder formar parejas. Así todas las transacciones contribuyen a una raíz única, aunque la última no tenga compañera.
PajaritoBTC
¿Puede una transacción posterior ayudar a confirmar otra que paga una comisión demasiado baja?
Sí, mediante Child-Pays-for-Parent (CPFP). La transacción hija gasta una salida de la transacción padre que aún está pendiente. Por separado, la padre puede parecer poco atractiva; pero la hija añade una comisión suficientemente alta para que el conjunto tenga una tasa media interesante para un minero.
La relación no es una orden ni una promesa. La hija depende de una salida concreta de la padre, así que no puede confirmarse antes que ella. Si un bloque incluye ambas, el minero obtiene la suma de sus comisiones y evalúa el peso combinado. La política de mempool decide si acepta y retransmite ese paquete; no existe una mempool global.
CPFP no modifica la transacción padre ni la reemplaza. A diferencia de RBF, conserva la operación original y añade otra transacción que gasta su cambio u otra salida disponible. Si la padre no tiene una salida controlable —por ejemplo, porque todas pertenecen a terceros— el receptor puede no tener capacidad para aplicar este mecanismo.
La consecuencia es útil: las transacciones relacionadas pueden evaluarse como un paquete económico, aunque cada una mantenga sus propias reglas de consenso. CPFP puede mejorar la prioridad de confirmación, pero no garantiza que un bloque incluya el conjunto. La inclusión final sigue dependiendo de que ambas transacciones sean válidas y de las decisiones del minero.
Sí, mediante Child-Pays-for-Parent (CPFP). La transacción hija gasta una salida de la transacción padre que aún está pendiente. Por separado, la padre puede parecer poco atractiva; pero la hija añade una comisión suficientemente alta para que el conjunto tenga una tasa media interesante para un minero.
La relación no es una orden ni una promesa. La hija depende de una salida concreta de la padre, así que no puede confirmarse antes que ella. Si un bloque incluye ambas, el minero obtiene la suma de sus comisiones y evalúa el peso combinado. La política de mempool decide si acepta y retransmite ese paquete; no existe una mempool global.
CPFP no modifica la transacción padre ni la reemplaza. A diferencia de RBF, conserva la operación original y añade otra transacción que gasta su cambio u otra salida disponible. Si la padre no tiene una salida controlable —por ejemplo, porque todas pertenecen a terceros— el receptor puede no tener capacidad para aplicar este mecanismo.
La consecuencia es útil: las transacciones relacionadas pueden evaluarse como un paquete económico, aunque cada una mantenga sus propias reglas de consenso. CPFP puede mejorar la prioridad de confirmación, pero no garantiza que un bloque incluya el conjunto. La inclusión final sigue dependiendo de que ambas transacciones sean válidas y de las decisiones del minero.
PajaritoBTC
¿Sabías que…? Las direcciones Bech32 de Bitcoin incluyen una suma de comprobación: ayuda a detectar errores de escritura, pero no corrige la dirección ni garantiza que el pago llegue al destinatario correcto.
PajaritoBTC
¿Qué revisa un nodo antes de aceptar una transacción? Primero comprueba que las entradas apuntan a UTXO existentes y aún no gastados. Después verifica las firmas y que el valor de las salidas no supere el de las entradas. Si todo encaja, elimina los UTXO usados y añade las nuevas salidas.
PajaritoBTC
¿Puede una transacción de Bitcoin estar firmada y, aun así, no ser válida para incluirse todavía en un bloque?
Sí. Dos campos ayudan a expresar restricciones temporales: nLockTime fija una altura de bloque o una marca temporal mínima; nSequence puede participar en reglas de reemplazo y, mediante relative locktime, exigir que haya pasado cierto tiempo desde que se confirmó la salida gastada.
La distinción importa. nLockTime mira el momento de la transacción respecto a la cadena; relative locktime mira la edad de una entrada concreta. Los nodos comprueban estas condiciones antes de aceptar o incluir el gasto. Una firma válida no elimina esos requisitos.
Por eso “firmada” no significa necesariamente “lista para confirmarse”. El reloj relevante no es el de una wallet, sino la altura o el tiempo que los nodos pueden verificar según las reglas de Bitcoin. Estos campos permiten coordinar gastos futuros sin crear una cuenta central ni pedir permiso a un tercero.
La consecuencia es sencilla: Bitcoin puede validar no solo quién puede gastar, sino también cuándo puede hacerlo. El tiempo, sin embargo, no es una promesa automática: la transacción debe seguir siendo válida cuando llegue el momento y cumplir el resto de reglas.
Sí. Dos campos ayudan a expresar restricciones temporales: nLockTime fija una altura de bloque o una marca temporal mínima; nSequence puede participar en reglas de reemplazo y, mediante relative locktime, exigir que haya pasado cierto tiempo desde que se confirmó la salida gastada.
La distinción importa. nLockTime mira el momento de la transacción respecto a la cadena; relative locktime mira la edad de una entrada concreta. Los nodos comprueban estas condiciones antes de aceptar o incluir el gasto. Una firma válida no elimina esos requisitos.
Por eso “firmada” no significa necesariamente “lista para confirmarse”. El reloj relevante no es el de una wallet, sino la altura o el tiempo que los nodos pueden verificar según las reglas de Bitcoin. Estos campos permiten coordinar gastos futuros sin crear una cuenta central ni pedir permiso a un tercero.
La consecuencia es sencilla: Bitcoin puede validar no solo quién puede gastar, sino también cuándo puede hacerlo. El tiempo, sin embargo, no es una promesa automática: la transacción debe seguir siendo válida cuando llegue el momento y cumplir el resto de reglas.
PajaritoBTC
¿Por qué una firma puede ocupar espacio en una transacción y, aun así, pesar menos para el cálculo de comisión?
Desde SegWit, Bitcoin separa los datos de la transacción en dos partes: el contenido base —version, inputs, outputs y locktime— y el witness, que contiene firmas y otros datos de satisfacción. El peso se calcula como 4 × bytes base + bytes witness. Un vbyte es una cuarta parte de ese peso, redondeada hacia arriba para la transacción completa.
La regla conecta tres límites distintos: el bloque no puede superar 4.000.000 de weight units, el tamaño base sigue limitado a 1.000.000 de bytes y los sigops también tienen un presupuesto de consenso. Por tanto, una transacción puede caber por peso y aun así exceder el límite de operaciones de firma.
El descuento no significa que el witness sea opcional ni menos válido. Los nodos deben verificarlo completamente; simplemente cuenta con un factor distinto en el límite de peso. La política de relay suele expresar la comisión en sat/vB, mientras el minero ordena transacciones según sus propios criterios, normalmente relacionados con la tasa efectiva de comisión y las dependencias.
La wallet influye en el resultado al elegir tipos de salida, número de entradas y método de firma: dos pagos con el mismo importe pueden tener pesos muy distintos. La consecuencia es precisa: vbytes no son bytes físicos, y una comisión baja por vbyte no relaja ninguna regla de consenso. Describe cómo se valora el espacio consumido dentro del presupuesto de peso; la validez sigue dependiendo de las reglas completas del protocolo.
Desde SegWit, Bitcoin separa los datos de la transacción en dos partes: el contenido base —version, inputs, outputs y locktime— y el witness, que contiene firmas y otros datos de satisfacción. El peso se calcula como 4 × bytes base + bytes witness. Un vbyte es una cuarta parte de ese peso, redondeada hacia arriba para la transacción completa.
La regla conecta tres límites distintos: el bloque no puede superar 4.000.000 de weight units, el tamaño base sigue limitado a 1.000.000 de bytes y los sigops también tienen un presupuesto de consenso. Por tanto, una transacción puede caber por peso y aun así exceder el límite de operaciones de firma.
El descuento no significa que el witness sea opcional ni menos válido. Los nodos deben verificarlo completamente; simplemente cuenta con un factor distinto en el límite de peso. La política de relay suele expresar la comisión en sat/vB, mientras el minero ordena transacciones según sus propios criterios, normalmente relacionados con la tasa efectiva de comisión y las dependencias.
La wallet influye en el resultado al elegir tipos de salida, número de entradas y método de firma: dos pagos con el mismo importe pueden tener pesos muy distintos. La consecuencia es precisa: vbytes no son bytes físicos, y una comisión baja por vbyte no relaja ninguna regla de consenso. Describe cómo se valora el espacio consumido dentro del presupuesto de peso; la validez sigue dependiendo de las reglas completas del protocolo.
PajaritoBTC
Si compras algo por 7 € con un billete de 10 €, recibes 3 € de vuelta. Bitcoin funciona de forma parecida: gasta un UTXO completo y crea una salida para el pago y otra con el cambio. No modifica un saldo: reorganiza salidas.
PajaritoBTC
¿Qué ocurre si una transacción de Bitcoin se queda pendiente y la comisión elegida ya no resulta atractiva para los mineros?
Existe una opción llamada Replace-by-Fee (RBF): mientras la transacción no esté confirmada, el emisor puede publicar otra que gaste los mismos UTXO, pero con una comisión mayor. La nueva versión puede modificar destinatario, cambio o importe, siempre que siga siendo válida y respete las reglas de reemplazo.
Los nodos no tienen una mempool global. Cada uno decide si acepta el reemplazo según sus políticas; entre otras condiciones, la nueva transacción debe pagar suficiente comisión para cubrir su propio espacio y compensar la retirada de la anterior. Un minero también puede recibir cualquiera de las dos por otra vía.
La frontera importante está en la confirmación. RBF no borra una transacción incluida en un bloque ni reescribe la cadena: solo permite competir por el mismo UTXO antes de que una versión quede confirmada. Por eso una transacción pendiente no debe tratarse como resultado definitivo.
RBF es, en esencia, un mecanismo de sustitución dentro del estado provisional de las mempools. Ayuda a corregir una comisión insuficiente o a actualizar una operación, pero no convierte una transacción confirmada en editable. La confirmación cambia la pregunta: ya no importa qué versión circula, sino cuál quedó incluida en la cadena activa.
Existe una opción llamada Replace-by-Fee (RBF): mientras la transacción no esté confirmada, el emisor puede publicar otra que gaste los mismos UTXO, pero con una comisión mayor. La nueva versión puede modificar destinatario, cambio o importe, siempre que siga siendo válida y respete las reglas de reemplazo.
Los nodos no tienen una mempool global. Cada uno decide si acepta el reemplazo según sus políticas; entre otras condiciones, la nueva transacción debe pagar suficiente comisión para cubrir su propio espacio y compensar la retirada de la anterior. Un minero también puede recibir cualquiera de las dos por otra vía.
La frontera importante está en la confirmación. RBF no borra una transacción incluida en un bloque ni reescribe la cadena: solo permite competir por el mismo UTXO antes de que una versión quede confirmada. Por eso una transacción pendiente no debe tratarse como resultado definitivo.
RBF es, en esencia, un mecanismo de sustitución dentro del estado provisional de las mempools. Ayuda a corregir una comisión insuficiente o a actualizar una operación, pero no convierte una transacción confirmada en editable. La confirmación cambia la pregunta: ya no importa qué versión circula, sino cuál quedó incluida en la cadena activa.
PajaritoBTC
¿Cómo detecta Bitcoin que alguien intenta gastar dos veces la misma moneda?
La clave está en los UTXO: cada salida no gastada puede consumirse una sola vez. Un nodo mantiene un conjunto actualizado de esas salidas. Cuando recibe una transacción, comprueba que cada entrada apunta a un UTXO existente y que ninguna entrada de la propia transacción repite el mismo origen.
Si llegan dos transacciones distintas que intentan gastar el mismo UTXO, no pueden confirmarse juntas en un bloque válido. La mempool de cada nodo puede conservar una y rechazar la otra, según sus reglas y el orden en que la reciba. No existe una mempool global que decida por toda la red.
La decisión definitiva llega cuando un bloque incluye una de ellas. Al conectar ese bloque, los nodos eliminan el UTXO gastado y crean las nuevas salidas. La transacción rival ya no puede entrar después usando la misma salida, porque esa entrada dejó de existir como UTXO disponible.
Por eso una transacción pendiente no equivale todavía a un estado final. La red puede observar conflictos antes de la confirmación, pero la cadena activa fija qué gasto quedó registrado. El doble gasto no se evita confiando en una lista central: se rechaza al aplicar las mismas reglas sobre un conjunto de UTXO que cada nodo reconstruye y verifica.
La clave está en los UTXO: cada salida no gastada puede consumirse una sola vez. Un nodo mantiene un conjunto actualizado de esas salidas. Cuando recibe una transacción, comprueba que cada entrada apunta a un UTXO existente y que ninguna entrada de la propia transacción repite el mismo origen.
Si llegan dos transacciones distintas que intentan gastar el mismo UTXO, no pueden confirmarse juntas en un bloque válido. La mempool de cada nodo puede conservar una y rechazar la otra, según sus reglas y el orden en que la reciba. No existe una mempool global que decida por toda la red.
La decisión definitiva llega cuando un bloque incluye una de ellas. Al conectar ese bloque, los nodos eliminan el UTXO gastado y crean las nuevas salidas. La transacción rival ya no puede entrar después usando la misma salida, porque esa entrada dejó de existir como UTXO disponible.
Por eso una transacción pendiente no equivale todavía a un estado final. La red puede observar conflictos antes de la confirmación, pero la cadena activa fija qué gasto quedó registrado. El doble gasto no se evita confiando en una lista central: se rechaza al aplicar las mismas reglas sobre un conjunto de UTXO que cada nodo reconstruye y verifica.
PajaritoBTC
Una dirección de Bitcoin se parece a un buzón, pero no es una cuenta con saldo: identifica condiciones para recibir. Puede reutilizarse, aunque hacerlo revela que varios pagos pertenecen al mismo contexto. Por eso las wallets suelen generar direcciones nuevas.