Cada nodo completo hace cumplir las reglas de Bitcoin por su cuenta. Un nodo completo es una computadora que ejecuta software de Bitcoin, descarga cada bloque y lo contrasta con las reglas de ese software. Rechaza cualquier bloque que incumpla una regla, por mucha potencia de cálculo que se haya usado para crearlo. Los mineros solo eligen qué transacciones válidas entran en un bloque, en qué orden y sobre qué cadena válida construyen. Nadie salvo tú puede cambiar las reglas que aplica tu nodo: para hacerlo, debes instalar otro software. Un cambio solo se extiende por la red cuando deciden adoptarlo suficientes mineros y suficientes operadores de nodos, sobre todo los que aceptan pagos en bitcoin.
Con esto sabrás qué no puede hacer ninguna empresa ni ningún minero con tus bitcoins, como crear monedas de más o gastar las tuyas sin tu clave. Podrás interpretar bien titulares como «los mineros votan una actualización». Y cuando la red se divida, como ocurrió en parte de ella en agosto de 2026, sabrás qué comprobar antes de mover fondos.
Qué hace cada uno: nodos, mineros y usuarios
Los nodos completos comprueban cada bloque
Un nodo contrasta cada bloque nuevo con sus reglas de consenso, las que deciden si un bloque es válido. Entre otras cosas, comprueba que:
- Cada transacción lleve una firma válida de la clave que controla las monedas gastadas (más en claves, direcciones y firmas).
- Ninguna moneda se gaste dos veces.
- El minero no se pague más que las monedas nuevas permitidas a esa altura (3,125 BTC por bloque desde abril de 2024) más las comisiones.
- El bloque respete el límite de tamaño de 4 millones de unidades de peso, una medida en la que los datos de las firmas cuentan menos.
- El bloque tenga suficiente prueba de trabajo y se construya sobre otro que el nodo ya acepte.
El nodo hace esto solo y no necesita permiso de nadie para rechazar un bloque. Hay decenas de miles de nodos completos. De ellos, unos 15 000 a 20 000 aceptan conexiones entrantes (noviembre de 2026).
Los mineros proponen bloques
Un minero usa máquinas especializadas que compiten por añadir el siguiente bloque mediante prueba de trabajo, una costosa carrera de cálculo que conocerás en la lección Cómo protege Bitcoin la prueba de trabajo. Los mineros deciden qué transacciones válidas entran en su bloque, normalmente primero las que mejor pagan, y sobre qué bloque válido construyen: por lo general, el más reciente de la cadena con más trabajo acumulado.
Los mineros pueden dejar transacciones fuera. Un grupo con la mayoría de la potencia de hash (la potencia de cálculo total de la minería de la red) podría reescribir bloques recientes. También podría negarse a construir sobre cualquier bloque que incluya ciertas transacciones: sería censura, no un cambio de reglas, porque esas transacciones seguirían siendo válidas. Pero, por mucha potencia de hash que haya, un bloque inválido no se vuelve aceptable: cada nodo lo descarta, igual que uno con una firma falsificada.
Los usuarios eligen el software
Aquí, usuario significa cualquiera que tenga o acepte bitcoins: tú, un exchange, una tienda o una empresa de billeteras. Todos dependen de un nodo, propio o ajeno, para saber si un pago es real. Por tanto, las reglas de ese nodo determinan qué aceptan como bitcoin. Eso da un peso real a las personas y empresas que aceptan bitcoins como pago: los mineros cobran en monedas, y estas solo valen algo en una cadena que compradores y vendedores acepten.
Los desarrolladores escriben el software y proponen cambios, pero nadie está obligado a instalar lo que escriben.
La tabla resume los cuatro papeles.
| Grupo | Qué decide | Qué no puede hacer |
|---|---|---|
| Nodos completos | Si cada bloque es válido según las reglas del software que ejecutan | Obligar a otro nodo a aceptar o rechazar algo |
| Mineros | Qué transacciones válidas entran en un bloque, su orden y qué cadena válida ampliar | Hacer válido un bloque inválido, crear monedas de más o gastar monedas sin una firma válida |
| Usuarios y empresas | Qué software ejecuta su propio nodo y, por tanto, qué monedas aceptan | Cambiar las reglas de otros |
| Desarrolladores | Qué código escriben y proponen | Obligar a alguien a ejecutarlo |
Por qué los nodos no votan
A menudo leerás que los nodos «votan» sobre bloques o actualizaciones. No es así. Cada nodo aplica sus reglas y guarda todos los bloques que las cumplen. Entre las cadenas que pasan esa comprobación, sigue la que tiene más prueba de trabajo acumulada. El trabajo solo permite elegir entre cadenas válidas. Nunca hace que cuente una inválida.
Además, contar nodos no serviría como votación: cualquiera puede poner en marcha mil nodos en servidores alquilados. El poder de un nodo es más personal. Protege a quien depende de él: un bloque que tu nodo rechace no puede engañarte, hagan lo que hagan los demás.
Reglas de consenso y política de retransmisión
Los nodos aplican dos tipos de reglas, y los debates actuales giran en torno a esa diferencia.
- Las reglas de consenso deciden si un bloque es válido. Dos nodos que discrepen sobre una de ellas acabarán siguiendo cadenas distintas.
- La política de retransmisión decide qué transacciones sin confirmar guarda un nodo en su mempool, la sala de espera de esas transacciones, y transmite a otros nodos. Es una preferencia local que cualquier operador puede cambiar sin salir de la red. Una transacción que tu nodo no retransmita sigue siendo válida y, si un minero la incluye, tu nodo acepta ese bloque.
Cómo cambian las reglas: soft forks y hard forks
Un cambio de las reglas de consenso se llama fork y hay dos tipos (en la lección sobre blockchain encontrarás un diagrama de ambos):
- Un soft fork hace las reglas más estrictas: algunos bloques que antes eran válidos dejan de serlo y ninguno que fuera inválido pasa a ser válido. Los nodos que no se actualizan siguen aceptando los bloques nuevos y permanecen en la misma cadena, pero no comprueban por sí mismos las reglas nuevas.
- Un hard fork relaja las reglas: algo que antes era inválido pasa a ser válido. Los nodos que no se actualizan rechazan los bloques nuevos, así que todos cambian de software o la cadena se divide en dos.
Un soft fork solo funciona sin problemas si la mayoría de la potencia de hash aplica la regla nueva. Si no, los nodos actualizados rechazan los bloques que la incumplen, los antiguos los aceptan y la cadena acaba dividida. Por eso, los soft forks suelen coordinarse mediante la señalización de los mineros, un método definido en BIP 9 (una propuesta de mejora de Bitcoin. Veremos más sobre ellas después). Los mineros activan un bit en el número de versión de la cabecera de cada bloque para indicar que están preparados. Cuando suficientes bloques de un período de 2016 bloques (unas dos semanas) lo han señalado, las reglas nuevas quedan fijadas y entran en vigor un período después. La señalización comprueba la preparación. No es una votación.
SegWit (2017): un soft fork que necesitó un empujón
Segregated Witness (SegWit) trasladó los datos de las firmas a una parte separada de cada transacción y sustituyó el límite de 1 MB por bloque por el de 4 millones de unidades de peso. Su código de activación necesitaba que el 95 % de los bloques de un período señalaran su apoyo, y la señalización se mantuvo por debajo desde noviembre de 2016 hasta el verano de 2017.
Después llegaron dos impulsos. Algunos usuarios y empresas apoyaron BIP 148, un soft fork activado por los usuarios (UASF): a partir del 1 de agosto de 2017, sus nodos rechazarían cualquier bloque que no señalara su apoyo a SegWit. Y en julio de 2017, los mineros con la mayoría de la potencia de hash adoptaron BIP 91, según el cual sus propios nodos rechazaban los bloques sin señalización. SegWit quedó fijado en agosto y se activó en el bloque 481 824, el 24 de agosto de 2017. Los nodos que no se habían actualizado siguieron en la misma cadena. Aún se debate cuánto influyó cada impulso.
Bitcoin Cash (2017): un hard fork que se convirtió en otra moneda
Algunos mineros y empresas querían, en cambio, bloques mucho mayores. Su software elevó el límite de tamaño a 8 MB a partir del 1 de agosto de 2017. También exigía que el primer bloque nuevo superara 1 MB, de modo que los nodos con las reglas existentes de Bitcoin lo rechazarían con certeza. Las cadenas se separaron después del bloque 478 558 y la nueva tomó el nombre Bitcoin Cash (BCH). Quien tuviera bitcoins antes de la división conservó la misma cantidad en ambas cadenas. Bitcoin Cash también añadió protección contra repetición: un cambio en la firma de las transacciones para impedir que un pago de una cadena se copiara en la otra.
Taproot (2021): un soft fork mediante «Speedy Trial»
Taproot añadió las firmas Schnorr, un tipo de firma digital más reciente y eficiente, y un tipo nuevo de salida que revela menos sobre cómo pueden gastarse las monedas. Los desarrolladores usaron un plazo breve de señalización llamado Speedy Trial: entre finales de abril y mediados de agosto de 2021, el 90 % de los bloques de un período de 2016 bloques debían señalar su apoyo. Ese umbral se alcanzó el 12 de junio de 2021. La activación se fijó para el bloque 709 632, unos cinco meses después, para dar tiempo a todos a actualizarse. Taproot entró en funcionamiento el 14 de noviembre de 2021.
Quién propone los cambios y cómo se adoptan
Cualquiera puede proponer un cambio. Las propuestas serias se redactan como una Bitcoin Improvement Proposal (BIP), un documento de diseño numerado en un repositorio público de GitHub. Los editores de las BIP asignan los números, pero «NO evalúan si es probable que la propuesta se adopte». El documento del proceso, BIP 3, es explícito: «Ningún órgano de decisión formal o informal dirige el desarrollo de Bitcoin ni decide la adopción de las BIP».
En la práctica, un cambio de consenso pasa por estos pasos:
- Debate público en la lista de correo bitcoin-dev y el foro Delving Bitcoin, a menudo durante años.
- Especificación y código: la BIP y una implementación, normalmente para Bitcoin Core, el software que ejecutan la mayoría de los nodos.
- Revisión: las directrices de Bitcoin Core exigen que un cambio de consenso tenga «una BIP ampliamente debatida» y «un consenso técnico reconocido de forma general» antes de que sus responsables lo incorporen.
- Publicación con reglas de activación: señalización de los mineros con un umbral, una altura de bloque fija (un «flag day») o ambas cosas.
- Adopción: los operadores de nodos, las empresas y los mineros deciden cada uno si lo ejecutan. Nada llega a tu nodo hasta que lo instalas.
Ningún grupo puede imponer un cambio por sí solo. En 2017, empresas y mineros que representaban más del 80 % de la potencia de hash acordaron duplicar el tamaño de bloque mediante un hard fork (SegWit2x). Los usuarios y desarrolladores se opusieron y, el 8 de noviembre de 2017, los organizadores lo cancelaron, afirmando que «no habían logrado suficiente consenso». En la lección sobre qué ocurre cuando se minan todos los bitcoins verás qué significa esto para el límite de 21 millones.
Por qué es tan difícil cambiar el límite de 21 millones
Ningún nodo cuenta las monedas para compararlas con un total de 21 millones. El límite resulta del calendario de emisión, cuyo cálculo verás en la lección sobre cuántos bitcoins hay. (El código sí contiene el número 21 millones, pero solo para comprobar que las cantidades individuales sean razonables). Cada nodo comprueba que la transacción coinbase de un bloque, la primera, que paga al minero, no entregue más que las monedas nuevas permitidas a esa altura más las comisiones. Si un bloque paga más, Bitcoin Core lo rechaza con el mensaje “coinbase pays too much”.
Elevar el límite sería, por tanto, un hard fork. Los nodos con las reglas actuales rechazarían el primer bloque con monedas de más, así que el cambio solo se aplicaría a quienes decidieran instalarlo. Esas monedas diluirían lo que tiene cada persona, un motivo de peso para negarse. A menos que casi todos cambiaran, el resultado sería otra moneda, como ocurrió con Bitcoin Cash.
La historia muestra la firmeza con la que se defiende esa regla. El 15 de agosto de 2010, un error permitió que el bloque 74 638 creara unos 184 mil millones de bitcoins. Unas cinco horas después del descubrimiento, se publicó una versión corregida del software. La corrección era en sí un soft fork: una comprobación nueva que invalidaba esos bloques. Los nodos que la instalaron rechazaron el bloque. Al día siguiente, la cadena que los mineros reconstruyeron sin él había superado a la defectuosa. Los nodos que no se habían actualizado también pasaron a seguirla porque tenía más trabajo y no incumplía ninguna de sus reglas.
Así que las matemáticas no garantizan el límite. Es una regla que las personas hacen cumplir. Eliminarla exigiría que casi todos los que usan bitcoins eligieran un software que renunciara a ella.
Los debates actuales, a noviembre de 2026
Datos en los bloques: una disputa sobre la política de retransmisión
Algunas transacciones llevan datos ajenos a los pagos, como imágenes (a menudo llamadas inscripciones), y los operadores de nodos discrepan sobre su retransmisión. Uno de los lugares para esos datos es una salida OP_RETURN: una salida es la parte de una transacción que indica adónde van las monedas, mientras que una salida OP_RETURN guarda datos y nunca puede gastarse. Bitcoin Core 30 (publicado el 10 de octubre de 2025) elevó a 100 000 bytes su límite predeterminado de retransmisión para estas salidas, datacarriersize, lo que «en la práctica elimina el límite».
Un comunicado de junio de 2025, firmado por muchos colaboradores de Bitcoin Core, defendía que negarse a retransmitir lo que los mineros incluirán de todos modos solo empuja a los usuarios a buscar otras formas de llegar a ellos, y subrayaba que esto «no supone apoyar ni aprobar el uso de datos no financieros». Algunos operadores que no estaban de acuerdo se pasaron a Bitcoin Knots, una variante de Bitcoin Core con muchos años de trayectoria y filtros de retransmisión más estrictos. Hasta ese momento, la disputa se limitaba a la política de retransmisión: ambos programas seguían la misma cadena.
BIP-110: cuando la disputa se convirtió en un cambio de consenso
BIP-110, el “Reduced Data Temporary Softfork”, fue más allá. Durante alrededor de un año, habría invalidado los bloques que crearan salidas de más de 34 bytes (83 para datos OP_RETURN) o llevaran un dato individual de más de 256 bytes, entre otros límites. Knots 29.3 lo incorporó en mayo de 2026, activado solo después de que el operador lo confirmara. Los bloques 961 632 a 963 647 debían señalar su apoyo y los nodos que lo aplicaran rechazarían los que no lo hicieran: un soft fork activado por los usuarios, como BIP 148.
Los mineros no lo siguieron. En el último período de 2016 bloques anterior a ese plazo, 51 bloques señalaron su apoyo (cerca del 2,5 %), frente al 55 % necesario para fijar la activación. Dentro del plazo, ningún bloque de la cadena que sigue Bitcoin Core señaló su apoyo (según nuestro recuento de los datos de mempool.space). El 8 de agosto de 2026, los nodos que aplicaban la regla rechazaron el bloque 961 632 y se separaron. En las semanas siguientes, su cadena recibió cerca de un bloque cada varios días. El repositorio de las BIP marcó BIP-110 como Closed. La solicitud de incorporación que lo hizo dice que «se separó en una cadena nueva y dejó de avanzar». El boletín Bitcoin Optech lo llamó un «intento de activación fallido».
Después, Knots dio otro paso con un hard fork. Desde el bloque 961 640, la versión 29.4.1 (2 de septiembre de 2026) sustituye la función hash que calculan los mineros para la prueba de trabajo, SHA-256d (SHA-256 aplicada dos veces), por otra, BLAKE2b, y aplica las reglas de BIP-110 a partir de esa altura. Los nodos con las reglas existentes rechazan esos bloques, así que Knots 29.4.1 y posteriores siguen una cadena separada. Sus notas de versión lo llaman «un cambio de protocolo incompatible con las versiones anteriores».
Los dos lados lo describen en términos opuestos. Las notas de versión de Knots dicen que el 8 de agosto «la mayoría de los antiguos mineros abandonaron Bitcoin en masa» y que han estado «promocionando falsamente una altcoin nueva como “Bitcoin”», y lo llaman «el mayor ataque a la red Bitcoin hasta la fecha». El repositorio de las BIP y Optech describen una activación fallida. Bitcoin Core, mempool.space y los mineros que producen alrededor de 1000 EH/s (exahashes, o mil millones de mil millones de intentos, por segundo) siguieron en la cadena SHA-256d, que conservó las reglas existentes y ya supera el bloque 970 000.
Esto muestra que aplicar una regla decide qué cadena sigue tu propio nodo. No obliga a los demás a seguirte. Si ejecutas Knots, consulta la guía cómo comprobar en qué cadena está tu nodo y nuestra comparación de Bitcoin Core y Knots.
Propuestas aún en debate
Entre los soft forks en debate están «Consensus Cleanup», una limpieza de casos límite antiguos (BIP 54), y un tipo de salida para prepararse ante las computadoras cuánticas (BIP 360). Otros añadirían covenants, formas de limitar cómo pueden gastarse las monedas en el futuro (como BIP 119 y BIP 347). Ninguno tiene fecha: Bitcoin Core 32.1 (octubre de 2026) no contiene ninguna activación nueva de soft fork. Un número BIP o el estado “Complete” indican un documento terminado que sus autores recomiendan, no un cambio próximo: BIP 3 lo deja «en manos de la comunidad Bitcoin evaluar, adoptar, ignorar o rechazar».
Qué hacer con esta información
- Comprueba las reglas por tu cuenta cuando importe. Ejecuta tu propio nodo o conecta la billetera a uno en el que confíes (la lección Por qué ejecutar un nodo Bitcoin).
- Lee las notas de versión antes de actualizar. Si mencionan «consenso», «soft fork», «hard fork» o «activación», averigua primero qué cambia y quién lo apoya. Verifica también la descarga (la lección Cómo verificar el software de Bitcoin). En un nodo en funcionamiento,
bitcoin-cli getdeploymentinfoenumera las activaciones de soft forks que sigue el software y sus estados. - Durante una división, espera. Las monedas anteriores a la división existen en ambas cadenas, y un pago firmado de la forma habitual suele poder copiarse en la otra. Espera para enviar, recibir o abrir canales Lightning (la capa de Bitcoin para pagos rápidos) hasta saber qué cadena siguen tu nodo y el de la otra persona.
Ideas clave
- Cada nodo contrasta todos los bloques con sus propias reglas y rechaza los inválidos. Los nodos no votan. Los mineros solo ordenan transacciones válidas y amplían cadenas válidas.
- Las reglas de consenso deciden qué bloques son válidos. La política de retransmisión solo decide qué transmite un nodo.
- Un soft fork hace las reglas más estrictas (SegWit, Taproot). Un hard fork las relaja y quienes no cambian se quedan en la cadena antigua (Bitcoin Cash).
- Las reglas solo cambian cuando las personas eligen otro software. Es muy difícil modificar el límite de 21 millones porque casi nadie renunciaría a él, no porque hacerlo sea imposible.
Comprueba lo que aprendiste
1. Un gran pool de minería anuncia que cada uno de sus bloques creará 4 BTC en monedas nuevas para él, más las comisiones, en lugar de 3,125 BTC. ¿Qué ocurre?
Respuesta
Todos los nodos rechazan esos bloques porque la transacción coinbase paga más de los 3,125 BTC permitidos en monedas nuevas más las comisiones. El pool desperdicia la electricidad que gastó en ellos. Incluso con la mayoría de la potencia de hash, solo produciría una cadena que los nodos actuales ignoran.
2. ¿Por qué los nodos que no se actualizan siguen funcionando después de un soft fork, pero no de un hard fork? ¿Y por qué un soft fork sigue necesitando la mayoría de la potencia de hash?
Respuesta
Un soft fork solo hace las reglas más estrictas, así que los bloques válidos según las reglas nuevas también cumplen las antiguas. Un hard fork hace válido algo que antes no lo era, de modo que los nodos antiguos rechazan los bloques nuevos. Y si la mayoría de los mineros sigue creando bloques que incumplen la regla nueva de un soft fork, los nodos actualizados los rechazan y los antiguos los aceptan, por lo que la cadena se divide.
3. En agosto de 2026, algunos nodos aplicaron BIP-110, pero la cadena que muestra mempool.space siguió sin él. ¿Por qué esos nodos no lograron activarlo?
Respuesta
Los nodos no votan. Cada nodo que aplicaba BIP-110 lo hizo para sí mismo y rechazó los bloques que no señalaban su apoyo. Casi ninguna potencia minera lo señaló, así que esos nodos se separaron en una cadena que recibía cerca de un bloque cada varios días. Todos los demás, incluidos los usuarios de Bitcoin Core y casi toda la potencia de hash, siguieron con las reglas antiguas.
