Nueva propuesta de escalabilidad plantea activación de SegWit por los usuarios

El arduo camino hacia la escalabilidad de la blockchain de Bitcoin prosigue. Luego de haberse consensuado un acuerdo para la escalabilidad entre una mayoría de representantes del ecosistema la semana pasada, el día de hoy fue publicada una nueva Propuesta para la Mejora de Bitcoin.

Esta nueva BIP (siglas en inglés para Bitcoin Improvement Proposal) fue distribuida a través de la lista de correo de desarrolladores de Bitcoin de la Fundación Linux por el desarrollador Calvin Rechner, buscando dar concreción al acuerdo de escalabilidad alcanzado en el evento Consensus 2017:

También te podría interesar

Únete a Modular 2024, la conferencia de criptomonedas, tecnología e innovación

9 septiembre, 2024

¿A qué precio llegaría bitcoin si gana Donald Trump o Kamala Harris?

9 septiembre, 2024

Esta propuesta está escrita bajo la asunción de que los firmantes del Acuerdo de Escalabilidad Consensus 2017 están genuinamente comprometidos con los términos del acuerdo, y pretende activar las actualizaciones descritas en él.

Calvin Rechner
Desarrollador

El BIP fue denominado Propuesta ómnibus orientada a la compatibilidad. Propone un soft fork activado por los usuarios (UASF, por sus siglas en inglés) el cual sería activado el 1ero de agosto; junto con un hard fork que aumente el límite del tamaño de los bloques a 2MB, el cual se activaría 6 meses después del UASF.

Una de las diferencias principales entre esta alternativa y el acuerdo alcanzado durante Consensus, radica en que la activación de SegWit se realizaría, no por los grupos de minería, sino por aquellos usuarios que corran nodos completos de Bitcoin. De esta manera, se da más apertura a la participación de la comunidad en los cambios que serán realizados al protocolo de Bitcoin, en vez de quedar cerrado al grupo de representantes que estuvieron presentes durante el evento -hecho que ha sido criticado por parte de la comunidad de usuarios.

Esta propuesta, establece el autor, busca alcanzar estos escenarios, manteniendo la máxima compatibilidad con las aproximaciones de despliegue existentes. Esto con el fin de minimizar los riesgos de una escisión en la cadena que dé paso a la creación de dos Bitcoins distintos, tal como sucedió cuando se realizó el hard fork de Ethereum que dio pie a Ethereum Classic.

Rechner, consciente de las opiniones en pugna dentro de la comunidad respecto a la activación de un hard fork, sabe poco probable que su propuesta cale dentro de Bitcoin Core en el futuro inmediato, por lo que propone mantenerla y revisarla en un repositorio separado. Con todo, afirma que está escrita con la intensión de que conserve compatibilidad con futuras actualizaciones de la red para mantener abierta la posibilidad de incluirla en caso de que se consiga un consenso en la comunidad ante esta propuesta en los meses venideros. Habrá que esperar para conocer la acogida de esta propuesta entre los usuarios para continuar el arduo camino para la escalabilidad de Bitcoin.