(OroyFinanzas.com) – Dos meses después de que se presentase en Hong Kong la propuesta de Testigos Segregados (Segregated Witness), y muy especialmente tras el anuncio de Bitcoin Classic, los argumentos en contra de esta implementación en el código fuente de Bitcoin, como herramienta para mejorar la capacidad de la red a través de un aumento del tamaño de los bloques, han sido constantes. Bitcoin Magazine ha resumido las principales críticas presentadas por los detractores, añadiendo a cada una de dichas críticas los argumentos que los rebaten. Un interesante análisis para balancear y poner luz sobre las ventajas y desventajas de la implementación de Testigos Segregados, que sigue siendo el objetivo prioritario del desarrollo del Bitcoin Core para los próximos meses.
El código de Testigos Segregados (Segregated Witness) es poco elegante
Uno de los argumentos más puristas en contra de la propuesta de Testigos Segregados es que las líneas de código que son necesarias para desarrollar Testigos Segregados en un soft fork (bifurcación blanda) son poco elegantes. Además, los reacios a esta implementación aseguran que incorpora a los campos del coinbase (la recompensa en bitcoins para los mineros) funciones para las que no estaba diseñado en principio. Adicionalmente, argumentan que esta complejidad de código podría causar nuevos problemas en el protocolo Bitcoin según éste vaya evolucionando en el futuro.
Argumentos que rebaten esta crítica
Aunque es cierto que la mayoría de los desarrolladores están de acuerdo en que la implementación de Testigos Segregados a través de un hard fork (bifurcación dura) sería una solución más elegante y limpia, esto no significa necesariamente que la implementación por la que se ha apostado a través de un soft fork sea poco segura. El equipo de desarrolladores de Bitcoin Core tiene experiencia con soft forks, y el código fuente de Bitcoin ya ha sufrido variaciones en ocasiones anteriores a través de este tipo de bifurcación, por lo que sostienen que no implicaría más riesgo que en otras ocasiones.
Por el contrario, un hard fork elimina la compatibilidad con los softwares anteriores, lo que tiene un riesgo asociado a ello.
El código de Testigos Segregados (Segregated Witness) limita demasiado el desarrollo futuro
La solución de un soft fork con Testigos Segregados impondrá una carga adicional para los desarrolladores tanto ahora como en el futuro. Esto es particularmente cierto para las bibliotecas Bitcoin y para los desarrolladores de carteras, que tendrán que adaptar su software para integrar Testigos Segregados, lo que implica un mayor esfuerzo para ellos que aumentar el tamaño de los bloques con un hard fork.
Argumentos que rebaten esta crítica
Sin embargo, lo cierto es que no parece que la mayoría de los desarrolladores de bibliotecas y cartera Bitcoin consideren la carga añadida de trabajo como un gran problema. Muchos de ellos incluso están muy entusiasmados con la innovación y en líneas generales consideran que los beneficios adicionales que implica hacen que los esfuerzos para actualizar sus aplicaciones valgan la pena.
Con Testigos Segregados el aumento efectivo del tamaño de los bloques Bitcoin no será inmediato
Al igual que la propuesta presentada por Bitcoin Classic, Testigos Segregados ofrece teóricamente hasta 1MB de espacio añadido en cada bloque, lo que supone un total de 2MB. Sin embargo, los críticos con la implementación argumentan que esta capacidad añadida óptima se basa en las transacciones multifirma (multisig). Sin embargo, en la actualidad la mayoría de las transacciones que procesa la red no son multifirma, lo que supone que el aumento de capacidad más realista que traerá consigo Testigos Segregados es de 0,6 MG de espacio adicional en el tamaño de los bloques, es decir, los bloques serán de 1,6 MB.
Además, este espacio adicional podría no ser plenamente utilizado de forma inmediata, ya que se requiere que las carteras y otras aplicaciones hayan incorporado las actualizaciones necesarias en sus respectivos códigos, lo que podría retrasar en el tiempo, el aumento en el tamaño de los bloques.
Por otro lado también aseguran que, si bien el calendario de trabajo planificado para Testigos Segregados está previsto que esté listo para abril de este año, está en el aire que esto sea posible. La solución requiere de mucho código nuevo, así como, de muchas pruebas adicionales antes de que pueda ser incorporado al código fuente. Además, habría que añadir a esto el tiempo que llevará a los mineros la actualización del código, para que la implementación sea efectiva.
Argumentos que rebaten esta crítica
Los defensores de Testigos Segregados, por su parte, argumentan que la versión pública de la testnet o red de pruebas (SegNet) ya está disponible para que cualquiera pueda experimentar con ella, lo que además sugiere que la previsión de trabajo va en buena dirección, y no tendría por qué variar la fecha prevista para su lanzamiento.
Además, muchos desarrolladores de bibliotecas y carteras han estimado que el tiempo para integrar Testigos Segregados en sus aplicaciones podría demorarse entre dos días y varias semanas. Por lo que si la versión final de la implementación está lista en abril, debería dar tiempo a que todos ellos tengan desarrollado ya el código actualizado.
Por lo que tan pronto como se active Testigos Segregados en el Bitcoin Core, todas las carteras y todas las aplicaciones se podrán beneficiar inmediatamente de los beneficios de ésta. Además, no importará si el espacio adicional en los bloques se utiliza o no, algo que además pondrá de relevancia que, si finalmente no se usa ese espacio extra añadido en los bloques, realmente ampliar el tamaño de los bloques no era una necesidad tan imperiosa como muchos han opinado que lo es.
La implementación de Testigos Segregados además podría suponer un creciente uso de las transacciones multifirma, dadas las posibilidades que implica para el desarrollo de los canales de pago y Lightning Network que típicamente hacen uso de ese tipo de transacciones. Y si el uso de las transacciones multifirma aumentase en la red, la capacidad efectiva que supondría la solución haría que el tamaño real de cada bloque aumente hasta los 2MB en el futuro.
Por otro lado, los defensores de Testigos Segregados no comparten con el equipo de desarrollo de Bitcoin Classic los tiempos en los que el hard fork podría implementarse. Si bien, el equipo de Bitcoin Classic asegura que para abril podría desplegarse, sería una decisión arriesgada y agresiva dado que se haría sin encontrar el consenso suficiente en la comunidad. La necesidad de que todos los operadores de nodos completos tengan tiempo para examinar el software y adoptar la actualización, piensan que requerirá un periodo de gracia de entre seis meses y un año.
Testigos Segregados limita los incentivos mineros
La eliminación de las firmas de los bloques originales de 1 MB, aumenta de manera efectiva el tamaño de los bloques Bitcoin. Pero Testigos Segregados introduce un nuevo tipo de tamaño máximo en los bloque, que implica que las transacciones multifirma obtienen un mayor beneficio con la implementación de Testigos y como las transacciones multifirma son utilizadas mayormente por otras capas en el protocolo Bitcoin, esto conllevará que se incentiva el uso de esas capas adicionales. El uso de esas capas adicionales, a largo plazo, tendrá inevitablemente consecuencias, y una de las más criticadas es que su efecto sobre las tasas de minería hará que éstas sean más bajas, que si no existen esas capas adicionales de servicios en el protocolo.
Argumentos que rebaten esta crítica
Testigos Segregados implica un aumento del tamaño de los bloques sin necesidad de implementar un hard fork. Adicionalmente, los datos de los Testigos pueden razonablemente considerarse prescindibles después de un tiempo determinado, lo que posibilita que los nodos completos no tengan la necesidad de almacenarlo para siempre, lo que, según argumentan los defensores de Testigo Segregados, eso implicará que tiene un menor costo para la red por lo que es razonable que las tasas de minería sean más bajas.
Argumentan también que la única manera de que Bitcoin pueda llegar a millones de usuarios a la vez que mantiene su descentralización, y es segura y resistente a la censura, es a través de la creación de capas adicionales. Por lo que entienden que incentivar el desarrollo y el uso de capas añadidas en el protocolo es algo positivo, y no negativo.
Testigos Segregados facilita los ataques de “mineros egoistas”
Uno de los principales argumentos a favor del límite del tamaño de los bloques es las consecuencias que pueda tener para la propagación de los bloques resueltos y la latencia. En resumen: los mayores bloques tienden a aumentar la cantidad de bloques huérfanos, dado que más mineros comienzan a resolver nuevos bloques mientras que el último bloque resuelto se propaga por toda la red. Esto favorece a los mineros más grandes (o pools), dado que son ellos los que tienen más posibilidades de resolver más bloques e inmediatamente pueden comenzar a minar el siguiente bloques y, por lo tanto, no pierden tiempo de procesado en bloques que no son correctos.
Y precisamente esta ventaja de las grandes mineras significa también que éstas podrían tener un incentivo para crear bloques más grandes artificialmente para perjudicar a sus competidores, que aumentarían los niveles de bloques huérfanos y por lo tanto, de tiempo de procesado perdido.
La actual propuesta de Testigos Segregados permite bloques de hasta aproximadamente 2 megabytes – aunque es más probable que sea un poco menos como hemos explicado más arriba. Pero debido a la medida contable específica para ser implementada, los denominados “mineros egoístas” podría crear transacciones sintéticas diseñadas para rellenar hasta 4 MB de datos en un sólo bloque. Como tal, las grandes mineras podrían “atacar” a sus competidores con bloques válidos de 4 MB. Por lo tanto, la implementación de Testigos Segregados, requiere adicionalmente que los mineros y los nodos completos utilicen hardware con un espacio libre de seguridad de 4MB, mientras que, a cambio de ello, la capacidad de transacción real que consiguen es menor. Además añaden que si en el futuro, el límite original del tamaño de bloque se incrementa mediante una hard fork, este riesgo multiplicador probablemente también exista.
Argumentos que rebaten esta crítica
Si 4 MB es lo suficientemente grande como para que un ataque de este tipo tenga éxito, algo que no está del todo claro, este ataque requeriría que el minero que ataque tenga que descartar todas las transacciones reales, lo que le llevaría a perder las tasas de minería de esas transacciones, algo que automáticamente tendría dos consecuencias: por un lado, serviría para desincentivar un ataque de este tipo y además el resto de la red se daría cuenta que se está produciendo dicho ataque.
Y sobre el multiplicador de riesgo que con probabilidad permanecería en un futuro si se implementa un hard fork para ampliar el tamaño real de los bloques, podría ser potencialmente disminuido a través de un soft fork.
Testigos Segregados perjudica la seguridad de los nodos no actualizados
Una quinta preocupación es que un soft fork de Testigos Segregados perjudicaría la seguridad de todos los nodos completos no actualizados. Estos nodos podrán aceptar transacciones con testigos segregados o las operaciones posteriores pero no podrán verificar si los datos de la firma son válidos, por lo tanto dependerían únicamente de la validación de los mineros, lo que implicaría que las transacciones con Testigos no confirmadas podrían ser inseguras ya que no están aún verificadas por los mineros.
Además argumentan que incluso las transacciones con Testigos confirmadas serían menos seguras, ya que los mineros podría a propósito confirmar transacciones no válidas en los bloques con la intención de efectuar doble gasto en los nodos no actualizados. En este caso, un nodo no actualizado creería que estos bloques son válidos hasta que los mineros cambien su potencia de hash a la cadena válida. Pero en el momento en que un nodo no actualizado acepte transacciones de bloques no válidas podría incurrirse en una pérdida de dinero de esas transacciones no confirmadas.
Los costos de este tipo de doble gasto podría parecerse a un ataque del 51 , pero con un impulso adicional. Los mineros atacantes podrían potencialmente aprovechar la potencia de hash de “lo SPV” (de carteras ligeras), que ellos mismos no sabría lo que está pasando, ya que tampoco validan las transacciones. Y el atacante podría aprovechar esos fondos para efectuar un doble gasto. Podrían para ello usar cualquier bitcoin protegido por Testigos Segregados que no necesariamente le perteneciese.
Argumentos que rebaten esta crítica
Un soft fork de Testigos Segregados se dará a conocer públicamente con mucha antelación, y será votado de forma transparente por los mineros. De esta forma, cualquier usuario que ejecuta un nodo completo tendrá tiempo suficiente para tomar las precauciones necesarias.
Los usuarios que ejecutan un nodo no actualizado no deben confiar en las transacciones con cero confirmaciones. Pero de cualquier forma, las transacciones con cero confirmaciones siempre han sido inseguras. De hecho, cualquier persona que quiera llevar a cabo un ataque de doble gasto con las transacciones sin confirmar puede hacerlo con o sin Testigos Segregados.
Por su parte, el riesgo añadido a las transacciones confirmadas puede ser compensado con la espera de un número adicional de confirmaciones.
Asimismo, un usuario que no desee actualizar su nodo completo podría prevenir este tipo de ataques con un software que marque las transacciones sospechosas y rechazar así esas transacciones por completo, hasta que otros nodos completos actualizados confirmen su validez.
Por último, cabe señalar que los hard forks implican un riesgo mucho mayor de transacciones de doble gasto. Cualquier nodo no actualizado podría, en el caso de que existiese un hard fork, recibir transacciones completamente válidas sin darse cuenta en absoluto de que eso está ocurriendo.
Testigos Segregados se desplegará sin el consentimiento explícito del usuario
Aunque podría decirse que con un riesgo pequeño, el deterioro de la seguridad descrito anteriormente existe. Y lo que es quizá más importante: Este deterioro de la seguridad se aplica sin el consentimiento explícito de los usuarios. Incluso si los usuarios se oponen fuertemente a Testigos Segregados y prefieren no actualizar, una mayoría de los mineros podría impulsar el cambio igualmente. Algo que es contrario a la promesa de libertad personal de Bitcoin: la idea de que los operadores de un nodo completo deben tener siempre la posibilidad de negarse a adoptar algún cambio.
Argumentos que rebaten esta crítica
Los soft forks no se pueden prevenir. Los mineros que controlan la mayor parte de la potencia de hash siempre tienen poder de decisión para hacer cumplir nuevas normas, siempre y cuando no se rompan las normas de consenso existentes. Esto es inherente al protocolo Bitcoin, y será posible de la misma manera después de un hard fork.
Por ello, los usuarios que ejecutan los nodos completos deben tener siempre algo de responsabilidad. O bien la responsabilidad de actualizar a la última versión del software, o la responsabilidad de esperar a un número adicional de confirmaciones, o tal vez incluso la responsabilidad de no aceptar ninguna transacción después de que se detecte un soft fork.
Y si bien es técnicamente cierto que los usuarios no necesitan cambiar su software después de un (polémico) hard fork, y pueden optar por “quedarse atrás” en la red original, esto es casi seguro que no sea una opción en la práctica. Además del riesgo de ataques de doble gasto, la disminución de la potencia de hash podría causar que las transacciones no se confirman – o que se confirman muy lentamente.
Un escenario alternativo es que la cadena minoritaria por la potencia de hash lleve a cabo su propio hard fork para cambiar el algoritmo de prueba de trabajo (proof of work). Bitcoin se dividiría entonces en dos redes separadas, y todos los usuarios tendría que actualizar su software para apoyar una de las opciones – o ambas.
© OroyFinanzas.com
