Índice del curso · 13 lecciones
Fundamentos de Bitcoin

¿Quién hace cumplir las reglas de Bitcoin y cómo cambian?

Una mano comprueba la esquina de un bloque de madera con una escuadra de acero sin marcas, sobre una mesa de nogal.

Esta lección es una traducción del original en inglés, que es el texto de referencia. Leer en inglés

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.

Los desarrolladores escriben nuevas versiones del software. Tú eliges qué versión ejecuta tu nodo y la instalas. Los mineros eligen transacciones válidas, construyen bloques y envían cada bloque nuevo a tu nodo. Este contrasta cada bloque con las reglas de la versión que instalaste: añade a tu cadena el que las cumple todas y rechaza el que incumple cualquiera, por mucho trabajo que lleve detrás. Solo tú puedes cambiar las reglas que comprueba tu nodo, instalando otro software.
Los desarrolladores escriben, tú eliges, los mineros proponen y tu nodo comprueba. Las reglas nuevas solo llegan a tu nodo mediante el software que instalas, y el bloque de un minero solo entra en tu cadena si las cumple. Los exchanges, las tiendas y las empresas de billeteras eligen de la misma forma para sus propios nodos.

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.

Una cadena se divide en tres ramas. La superior tiene más bloques y, por tanto, más trabajo, pero su primer bloque crea 4 BTC en monedas nuevas, más de lo permitido. Tu nodo la ignora junto con todos los bloques construidos encima. La rama central es válida y tiene más trabajo que las demás ramas válidas: tu nodo la sigue. La inferior es válida, pero tiene menos trabajo, así que queda atrás. Primero las reglas y después el trabajo: este solo sirve para elegir entre cadenas que cumplen las reglas.
Los nodos no votan: primero filtran y después siguen el trabajo. Ignoran una rama que tenga un bloque inválido, por larga que llegue a ser. Entre las restantes, tu nodo sigue la que tiene más prueba de trabajo acumulada.

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.
Dos casos. Primero, dos nodos tienen distinta política de retransmisión: tu nodo no transmite una transacción y otro sí. Siguen en una sola cadena, porque ambos aceptan el bloque en el que un minero incluye esa transacción. Segundo, dos nodos tienen distintas reglas de consenso: tu nodo rechaza un bloque nuevo por inválido y otro lo acepta como válido. La cadena se divide en dos y cada nodo sigue los bloques que acepta. Solo las reglas de consenso pueden dividir la cadena. La política de retransmisión es una preferencia local.
La política de retransmisión es una preferencia. Las reglas de consenso deciden qué bloques cuentan. Los nodos pueden tener políticas de retransmisión distintas y aun así coincidir en todos los bloques. Si discrepan sobre una regla de consenso, dejan de aceptar los mismos bloques.

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.

Dos resultados de un soft fork. Primero, la mayoría de la potencia de hash aplica la regla nueva, como con Taproot: el umbral de señalización del 90 % se alcanzó el 12 de junio de 2021 y la regla entró en vigor el 14 de noviembre de 2021. Todos los bloques nuevos la cumplen, así que los nodos con la regla y los que no la tienen aceptan los mismos bloques y hay una sola cadena. Segundo, la mayoría de la potencia de hash ignora la regla nueva, como con BIP-110: alrededor del 2,5 % de los bloques señalaron su apoyo (51 de 2016), frente al 55 % necesario, y la regla entró en vigor el 8 de agosto de 2026. Los nodos con la regla rechazan el primer bloque que la incumple y siguen los bloques que crean unos pocos mineros, más o menos uno cada varios días. Los nodos sin esa regla siguen los bloques de la mayoría de la potencia de hash. El resultado son dos cadenas. Sin la mayoría de esa potencia, aplicar un soft fork divide la cadena.
Un soft fork necesita el apoyo de la mayoría de la potencia de hash. Los mineros señalan primero que están preparados. Cuando lo están casi todos, los nodos con la regla nueva y los que no la tienen siguen juntos. Cuando no, los nodos que la aplican de todos modos acaban en una cadena propia. Más adelante en esta lección verás lo ocurrido con Taproot y BIP-110.

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:

  1. Debate público en la lista de correo bitcoin-dev y el foro Delving Bitcoin, a menudo durante años.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Tres momentos de 2010. 1, 15 de agosto de 2010: un error permite que el bloque 74 638 cree unos 184 mil millones de bitcoins y los nodos lo aceptan. 2, unas cinco horas después del descubrimiento: una versión corregida invalida esos bloques, lo que constituye un soft fork, y los mineros vuelven a empezar desde el bloque anterior. 3, al día siguiente: la cadena reconstruida tiene más trabajo que la defectuosa e incluso los nodos sin la corrección pasan a seguirla porque no incumple ninguna regla. El límite es una regla que las personas hacen cumplir: se mantuvo porque los nodos y mineros ejecutaron la corrección.
En 2010, un error creó unos 184 mil millones de bitcoins y las personas lo deshicieron en un día. La corrección fue una comprobación nueva que invalidó esos bloques. Los mineros reconstruyeron la cadena sin el bloque defectuoso y todos los nodos acabaron siguiendo la cadena reconstruida.

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.

Los cambios de reglas de esta lección, agrupados por resultado. Se mantuvo una sola cadena porque la mayoría de la potencia de hash aplicó el cambio: la corrección del desbordamiento de 2010, SegWit en 2017 y Taproot en 2021, todos soft forks. Se separaron y solo los siguieron quienes los ejecutaron: Bitcoin Cash en 2017, un hard fork. BIP-110 en 2026, un soft fork que siguieron pocos mineros. Y la prueba de trabajo BLAKE2b de Knots en 2026, un hard fork. Se canceló antes de activarse: SegWit2x en 2017, un hard fork. Un cambio solo se extiende cuando lo ejecutan suficientes operadores de nodos y mineros.
Todos los cambios de esta lección tuvieron uno de tres resultados. Los soft forks que aplicó la mayoría de la potencia de hash conservaron una sola cadena. Los cambios que solo ejecutaron algunas personas las dejaron en una cadena propia, y SegWit2x se canceló antes de activarse.

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 getdeploymentinfo enumera 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.
Una cadena se divide en dos. Tus monedas anteriores a la división existen en ambas cadenas. Pagas a alguien en una de ellas. El mismo pago firmado suele poder copiarse en la otra, donde también gasta tus monedas y paga a la misma persona. Durante una división, espera hasta saber qué cadena siguen tu nodo y el de la otra persona.
Durante una división, las mismas monedas existen en ambas cadenas. Un pago firmado de la forma habitual suele poder copiarse en la otra, donde también gasta tus monedas. Espera 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.