Reglas de consenso

Imagina que alguien gasta los mismos fondos de un pago anterior para pagarte a ti y después a una tienda. Ambos gastos no pueden formar parte de una historia válida. Para comprobarlo, el nodo sigue las salidas de las transacciones: registros de cantidades y de las condiciones para gastarlas. Al recibir un bloque, el nodo comprueba si el bloque cumple sus reglas, no quién lo recomienda. Verifica, entre otras cosas, la disponibilidad de las salidas que se gastan, las condiciones de Bitcoin Script y las firmas exigidas, Proof of Work y la recompensa permitida al minero. Incumplir una regla implica el rechazo. El apoyo de una empresa o una mayoría de votos en internet no cambia el resultado. [1]

El minero selecciona transacciones y busca un bloque; el Full Node comprueba el resultado de forma independiente. Los desarrolladores pueden proponer cambios y publicar software, pero eso por sí solo no modifica las reglas de otros nodos. Cada operador elige qué software ejecutar. Su elección determina lo que acepta su propio nodo, no lo que deben aceptar todos los demás. [2] [1]

El nodo también tiene reglas para las transacciones sin confirmar: cuáles guarda en su Mempool, el conjunto local de transacciones pendientes de confirmación, y cuáles retransmite a otros nodos. Estas reglas locales, llamadas policy, pueden ser más estrictas que el consenso. Que una transacción sea rechazada por el mempool no significa, por sí solo, que sea inválida dentro de un bloque. La política de retransmisión no se aplica al validar bloques. [3]

Un Soft Fork endurece las reglas: los bloques válidos bajo las nuevas también cumplen las anteriores. Sin embargo, los nodos antiguos no comprueban las condiciones nuevas. Un Hard Fork puede permitir, en cambio, un bloque que los nodos antiguos rechazan. El mecanismo de activación ayuda a coordinar el cambio; no garantiza el acuerdo de todos ni sustituye la decisión de cada operador sobre qué software usar. [4]

Tener tu propio Full Node permite comprobar los bloques recibidos en lugar de fiarte de una web de exploración de bloques. Un nodo puede conocer varias ramas, es decir, distintas continuaciones de una historia común. Entre las ramas válidas elige según chainwork, la suma del trabajo atribuido a cada bloque en función de su dificultad de minería. No mide la electricidad realmente consumida ni se limita a contar bloques. Un mayor trabajo no justifica saltarse las reglas. Para llegar al mismo resultado, los nodos deben aplicarlas de forma coherente incluso en casos poco habituales. Un error del programa puede hacer que discrepen sobre qué bloques aceptar. [4] [5]

Un nodo puede negarse a retransmitir una transacción cuya comisión es demasiado baja. Pero si un minero la incluye en un bloque y tanto la transacción como el bloque cumplen el consenso, el nodo acepta el bloque. Si el minero se atribuye más que la cantidad permitida de nuevos bitcoins, llamada Block Subsidy, más las comisiones de las transacciones del bloque, el nodo rechaza el bloque incluso con un Proof of Work válido. La diferencia está en el motivo del rechazo, no en la reputación del minero. [3] [1]