Segwit fue desarrollado en "The Elements Project" con Pieter Wuille (@pwuille) como investigador principal, su implementación en Bitcoin suponía un hard fork, posteriormente Luke Dashjr (@LukeDashjr) propuso la forma de implementarlo como soft fork y tras esto se preparó el BIP para integrarlo en Bitcoin.
Segwit es una actualización del protocolo Bitcoin que modifica la estructura de las transacciones, guarda toda la información susceptible de ser maleable en un nuevo campo "witness data". El id de la transacción se calcula sin contar con este campo por lo que posteriormente no se puede modificar.
Propuesta Diciembre 2015 (bip141)
Segwit fue propuesto mediante un BIP (Bitcoin Improvement Proposals) por Eric Lombrozo (@eric_lombrozo), Johnson Lau (@johnsonlau01) y Pieter Wuille (@pwuille)
Es un soft fork, es decir, los clientes no actualizados pueden coexistir con las versiones actualizadas.
La descripción de segwit se divide en 5 BIP:
- BIP141 - Activado el 24 de Agosto de 2017
- Descripción general
- BIP142 - Reemplazado por el BIP143
- Describe el formato nativo de las direcciones de pay-to-witness-public-key-hash (P2WPKH) y pay-to-witness-script-hash (P2WSH).
- BIP143 - Activado el 24 de Agosto de 2017
- Entra en detalle en la verificación de transacciones en segwit y como resuelve el crecimiento cuadrático del hash de firmas.
- BIP144 - Activado el 24 de Agosto de 2017
- Trata el cambio en los mensajes de red provocados por segwit.
- BIP145
- Cubre los cambios en la llamada JSON-RPC getblocktemplate al cliente bitcoin core.
- Soluciona la maleabilidad de las transacciones. (¿En qué consiste la maleabilidad?)
- Aumenta el tamaño del bloque a 4MB en situación ideal, sobre los 2MB en condiciones normales.
- Facilita la inclusión de nuevos opcodes o modificación de los existentes mediante versionado de scripts.
- Facilita el desarrollo de soluciones de segunda capa.
- Escalado lineal de las operaciones sighash. La cantidad de datos sobre los que se calcula el hash o comprueba la firma crece cuadráticamente el número de inputs no segwit de una transacción. (The Megatransaction: Why Does It Take 25 Seconds?)
- Firma de los input. Anteriormente los input no se firmaban lo que suponía un problema para las carteras hardware que tenían que buscar las cantidades de los input en los output gastados con el tiempo que eso supone.
- Mayor seguridad en multifirma con P2SH
- Reduce el crecimiento de los UTXO (Salidas de transacciones no gastadas)
- Jeff Garzik (@jgarzik) consideró insuficiente a SegWit como solución de escalado.
- Mike Hearn, desarrollador principal del cliente Bitcoin XT calificó a SegWit como "un truco contable", dejó el desarrollo de Bitcoin poco después.
- Jonathan Toomim, desarrollado del cliente Bitcoin Classic comentó que SegWit era "feo y raro", sugirió que sería mejor implementarlo como hard fork.
- Peter Todd (@peterktodd) tenía sus dudas en particular en lo respectivo a minería. [1] [2]
Mientras SegWit se desarrollaba en la comunidad Bitcoin había tensiones en cuanto al tamaño del bloque (1MB), varios mineros y compañias Bitcoin encabezados por Bitcoin Classic preparaban un hard fork para aumentar el tamaño a 2 MB. [1]
El 21 de Febrero de 2016 en una reunión en Hong Kong entre varios desarrolladores de Bitcoin Core, operadores de agrupaciones mineras y miembros de la industria Bitcoin para discutir el problema de escalabilidad se llegó a un acuerdo conocido como "El acuerdo de la mesa redonda de Bitcoin", ese acuerdo consistió en estos puntos:
- SegWit se está desarrollando como soft fork y se lanzará en los próximos 2 meses.
- Se trabajará públicamente junto a toda la comunidad de desarrolladores del protocolo Bitcoin en un hard fork basado en las mejoras de SegWit. Los desarrolladores de Bitcoin Core tendrán una implementación de dicho hard fork para presentar 3 meses después del lanzamiento de SegWit.
- Este hard fork incluirá características que se están tratando como aumentar el tamaño de los datos no testigos (non witness) a los 2 MB y sólo será adoptado si hay un acuerdo de la mayoría la comunidad Bitcoin.
- Los mineros utilizarán SegWit cuando el hard fork se implemente en el cliente Bitcoin Core.
- Solo se utilizarán sistemas compatibles con el consenso de Bitcoin Core que contendrán SegWit y el hard fork.
- Se seguirán investigando tecnologías para usar el espacio en los bloques más eficientemente como las firmas Schnorr.
Meses más tarde, en Julio de 2016 tuvo lugar una reunión entre desarrolladores de Bitcoin Core y operadores de agrupaciones mineras en California. Los desarrolladores de Bitcoin Core salieron de la reunión convencidos de que SegWit sería activado por los mineros.
SegWit se incluyó en la versión 0.13.1 del cliente Bitcoin Core, también se implementó en otros clientes como Knots o Bcoin
Para activar SegWit se utilizó un método llamado "VersionBits" diseñado para minimizar interrupciones en la red. El 95% de los mineros tenían que señalizar su conformidad para que SegWit se activara en la red Bitcoin. Esta señalización iba a comenzar el 15 de Noviembre de 2016.
Se animó a los usuarios a que actualizaran el cliente lo que hicieron la mayoría.
Todo apuntaba a que SegWit se activaría en breve, pero no fue así.
Varios de los participantes de la reunión de Hong Kong cambiaron de opinión.
Un hard fork significa que el protocolo que se es válido deja de serlo tras el momento del hard fork, los desarrolladores ven un peligro en este tipo de actualización y es que todos los clientes deben ir a la nueva versión si hay usuarios que no están de acuerdo pueden quedarse en la versión "vieja" del protocolo y provoca una bifurcación. Para evitar esto se propuso un "soft-hardfork".
Lo malo del soft-hardfork era que se podía aplicar sin que los usuarios pudieran hacer nada, les obligaba a seguir las normas aunque no estuvieran de acuerdo o crear una nueva red. Para evitar esta situación los desarrolladores buscaban la manera de tener confirmación por parte de la comunidad de Bitcoin. Para ello se propusieron 2 soluciones basadas en los bitcoin que controlaban los usuarios, estas soluciones se llamaron "señalización con moneda" (coin-signaling). La primera de las soluciones permitía a los usuarios agregar un dato en las transacciones señalizando su conformidad con el fork, si todas las transacciones durante un periodo de tiempo señalizaban el fork se consideraba que la comunidad lo aprobaba. La segunda solución en la que estuvo trabajando Peter Todd permitía a los usuarios mostrar su posición sin necesidad de realizar transacciones, lo explicó en su blog.
La señalización de apoyo a Segwit por parte de los mineros era escasa y el consorcio minero chino F2Pool hizo un movimiento que varios desarrolladores consideraron una ruptura de acuerdo.
Jihan Wu co-CEO de Bitmain dijo que sólo activaría SegWit si se hacía el hardfork de aumento del tamaño del bloque, otros consorcios como F2Pool, HaoBTC o bitcoin.com tampoco señalizaron el apoyo a SegWit.
En Febrero de 2017 shaolinfry propuso [1][2] una activación provocada por los nodos completos, la mayoría económica.
Shaolinfry propuso cambiar el estándar de activación de soft fork que hasta ese momento era la activación por poder de cómputo a una activación provocada por todos los usuarios.
Una activación de soft fork por parte del usuario tendría un "día de comienzo de activación" en el que los nodos comenzarían a forzar la activación en una fecha posterior, si la mayoría económica forzase dicha activación haría que la minería le siguiera.
La idea empezó a coger fuerza y cuando Samson Mow montó un fondo de recompensas parecía que la propuesta se convertiría en realidad.
La primera semana de Abril de 2017 Gregory Maxwell explicó que había encontrado ASICBOOST implementado en algunos chip de minado, esta tecnología daba una ventaja en el minado a estos chip. SegWit haría incompatible esta manera de utilizar ASICBOOST. Bitmain admitió que había implementado esta tecnología patentada en sus chip, aunque dijo no utilizarla en la red de producción de Bitcoin.
Esta noticia generó mayor interés por parte de la comunidad en activar SegWit.
La propuesta de UASF se discutió en un canal creado para ello en el slack de Bitcoin Core y shaolinfry propuso el BIP148.
La propuesta no tuvo mucho éxito, ninguno de los mayores exchanges se unieron y se oyeron opiniones en contra como la del CEO de bitpay Stephen Pair.
Gregory Maxwell también dijo que el BIP148 le parecía una mala idea.
Parecía que UASF había fracasado pero alguien comenzó a trabajar en una alternativa: BIP149
El debate sobre el aumento del tamaño del bloque continuaba, otro cliente, Bitcoin Unlimited, que apoyaba incrementar el tamaño mediante un hardfork se hizo popular entre la minería, con el apoyo de Bitmain todo indicaba que se iba a realizar el hard fork.
Por esta razón Barry Silbert organizó una reunión aprovechando el evento "Consensus 2017", se invitó a gente de la industria Bitcoin incluyendo minería, pero no desarrolladores de Bitcoin Core.
El resultado de esta reunión se conoce como "el acuerdo de Nueva York" en el que los participantes se comprometieron a una solución que satisfacía a la parte que quería un hard fork y a la parte que quería SegWit. Basada en una idea de Sergio Demian Lerner la propuesta fue la siguiente:
- Activar SegWit cuando más del 80% de los bloques señalen con un 4 en el bit.
- Activar el hardfork que aumenta a 2MB el tamaño del bloque tras 6 meses. No todo el mundo estuvo de acuerdo con esta reunión, estas condiciones eran incompatibles con lo propuesto por los desarrolladores Bitcoin Core cuyo código ya estaba en la mayoría de los nodos de los usuarios.
Mientras, BIP148 había perdido mucho soporte en favor del BIP149 pero no todo el mundo había renunciado al UASF.
La propuesta de shaolinfry incluía la posibilidad de abortar la activación de SegWit si una mayoría no la aceptaba antes de una fecha concreta pero un grupo de usuarios tenía otra idea. Gente como Luke Dashjr) estaban considerando la posibilidad de activar el soft fork independientemente del apoyo.
Sobre mediados de Mayo, Alphonse Pace publicó este artículo sobre la "minoría intolerante", estar teoría presupone que incluso una minoría económica podría hacer que los mineros activaran SegWit ya que sino perderían parte de sus usuarios innecesariamente.
Tras esto y alimentado por el escándalo AsicBoost, el BIP148 empezó a ganar adeptos, se comenzó a calificar al 1 de Agosto como "El día de la independencia de Bitcoin".
El problema era el BIP148 era incompatible con "el acuerdo de Nueva York".
Fue James Hilliard ingeniero de Myrig el que propuso una solución como BIP, el BIP91 que haría compatibles todas las opciones. Mientras la mayoría de los mineros activasen este BIP antes del 1 de Agosto, todos los nodos formarían parte de la misma red. Había poco tiempo ya que la propuesta fue a finales de Mayo, pero Jeff Garzik) se comprometió a sacar el cliente con esta propuesta implementada semanas antes del 1 de Agosto.
A mediados de Julio la minería Bitcoin había perdido la primera fecha límite del BIP148 lo que puso nervioso al mercado, posiblemente provocada por este nerviosismo la minería comenzó a señalizar su apoyo al BIP91 y el 20 de Julio se fijó para activarse 2 días más tarde.
Con BIP91 fijado sólo era cuestión de tiempo que lo hiciera SegWit, esto ocurrió el 9 de Agosto. Bitcoin activaría SegWit 2 semanas más tarde.
- The long road to SegWit
- SegWit explicado
- Segregated Witness: a fork too far
- Segregated witness and deploying it for Bitcoin
- Segwit in Bitcoin: Lessons Learned (PDF)
- The Elements Project: Segregated Witness
- UASF.co
- Bitcoin miners miss the first BIP 148 "deadline"
- Presentación de SegWit de Pieter Wuille (@pwuille)."Scaling Bitcoin", Hong Kong 14-Dic-2015 -VIDEO-
- What is ASICBOOST?
- Op Ed: Here's Why All Rational Miners Will Activate SegWit Through BIP148
- UASF BIP148 Scenarios and Game Theory
- Why I support BIP148