Estándar y política

Curiosidad

1. ¿Por qué una transacción válida a veces es rechazada por una billetera antes de llegar siquiera a un minero?
2. ¿Qué sucede si una contraparte utiliza un software diferente al tuyo, pero ambos son “correctos”?
3. ¿Cómo puede evitar que los códigos de operación no utilizados estén en el camino del relé proteger las futuras actualizaciones?

Explorar

1. Las reglas de consenso definen la validez; determinan qué puede aparecer en un bloque y ser aceptado por cada nodo. El estándar es una política local separada que dicta qué transacciones un nodo específico retransmite a sus pares y mantiene en su mempool. Una transacción puede ser perfectamente válida según el consenso, pero no estándar según las políticas de retransmisión predeterminadas. Cuando un usuario transmite tal transacción, su propio nodo podría descartarla inmediatamente, aunque técnicamente los mineros podrían incluirla.
2. Los tipos de salida estándar están estrictamente limitados para proteger los nodos de ataques de denegación de servicio y agotamiento de recursos. Estos incluyen P2PKH, P2SH, P2WPKH, P2WSH, P2TR, scripts multisig simples (hasta tres claves) y salidas de datos OP_RETURN de un tamaño específico. Por defecto, no se retransmiten los scripts que utilizan opcodes reservados o desconocidos, o que exceden los límites de tamaño. Este filtrado asegura que el mempool permanezca manejable y evita que actores malintencionados inunden la red con basura compleja y costosa desde el punto de vista computacional.
3. La política no es estática; evoluciona según la implementación de cada nodo. En 2025, los desarrolladores de Bitcoin Core decidieron relajar el límite de tamaño por defecto para las salidas de datos OP_RETURN. Este cambio generó debate entre los operadores de nodos, algunos de los cuales se opusieron a esta ampliación y pasaron a utilizar software alternativo como Bitcoin Knots para mantener límites más estrictos. Esta divergencia ilustra que el estándar es un ajuste local: dos nodos que ejecutan versiones o forks diferentes pueden retransmitir subconjuntos distintos de transacciones válidas sin violar el consenso.
4. Una transacción no estándar pero válida aún puede ser confirmada si evita por completo la red de retransmisión predeterminada. Los mineros han ofrecido servicios de envío directo, lo que permite a los usuarios enviar transacciones directamente a sus bloques, independientemente de las políticas de los nodos. Si una billetera depende del rechazo de lo no estándar como medida de seguridad —suponiendo que un script con apariencia inválida nunca se propagará—, enfrenta un riesgo: una contraparte que utilice el acceso directo a los mineros podría confirmar esa transacción. Esto genera un fork en el comportamiento, no en la verdad, lo que podría llevar a movimientos o pérdidas inesperadas de fondos.
5. El estándar funciona como una válvula de seguridad para futuras actualizaciones tipo soft fork. Al imponer reglas más estrictas ahora —como tratar los opcodes NOP reservados para actualizaciones como no estándar durante la retransmisión—, el protocolo garantiza una transición fluida cuando una actualización endurezca las reglas de consenso. Dado que las transacciones que utilizan esos opcodes reservados no se retransmiten ni se minan por defecto, existen pocas o ninguna cuando un soft fork les da significado; por lo tanto, las nuevas reglas no invalidan nada en lo que la gente confiaba, y es poco probable que los mineros sin actualizar minen un bloque rechazado por las nuevas reglas.
6. Lea usted mismo las verificaciones de política: en el código fuente de Bitcoin Core, policy/policy.cpp contiene IsStandard e IsStandardTx, que enumeran los tipos de salida aceptados y los límites de tamaño; la serie “Waiting for confirmation” de Bitcoin Optech explica el razonamiento detrás de ellos. Compárelas con las reglas de consenso en el código de validación, y observe cuán más estrictas son las reglas de retransmisión.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)