Segregated Witness es una propuesta (BIP-141) diseñada para resolver el problema de maleabilidad de las transacciones de la cadena de bloques de Bitcoin.
1. ¿Qué es la maleabilidad de las transacciones?
Es decir, el contenido de la transacción no ha cambiado, pero el ID de la transacción sí ha cambiado. Debido a la simetría de la curva elíptica en el algoritmo de firma ECDSA utilizado en la red Bitcoin, siempre se pueden calcular dos firmas válidas para firmar una transacción, y estas dos firmas válidas también se pueden calcular entre sí. Después de transmitir una transacción, publique una transacción con el mismo contenido usando firmas diferentes. Las dos transacciones tienen el mismo contenido pero diferentes ID de transacción, lo que engañará a los participantes de la red.
2. La extensión de la transacción cambia la firma, pero el contenido de la transacción permanece sin cambios. Al final, la red seguirá confirmando el contenido de la transacción. La segunda firma es diferente pero el contenido de la transacción es el mismo y no tendrá ningún impacto. En cuanto a la seguridad de la transacción, de hecho, la red también confirmará el contenido de la transacción. No habrá problema de doble gasto (el mismo dinero se gasta dos veces), entonces, ¿cuál será el impacto real de la extensión de la transacción?
De hecho, se debe principalmente a que muchos servicios de Bitcoin (como intercambios y servicios de automatización en cadena de terceros) dependen de los ID de transacciones como identificadores de transacciones. Un ejemplo es que Little A inició un retiro de moneda del intercambio y luego se transmitió la transacción de su retiro de moneda. Antes de que el nodo verificara su transacción, Little A llevó a cabo un ataque escalable, que resultó ser la nueva transacción generada por. El ataque. La transacción se confirma primero, y aunque la nueva transacción le permitirá obtener monedas, la red rechazará la transacción anterior. Sin embargo, Little A se quejó ante el intercambio de que no había recibido las monedas. El intercambio vio que la transacción anterior para transferir dinero a Little A fue efectivamente rechazada, por lo que le remitió otra cantidad de monedas.
3. Parece que el problema en realidad se debe a que el ID de transacción se utiliza como identificador de transacción. ¿Es factible no utilizar el ID de transacción como identificador de transacción?
¿Analizar el contenido del bloque BTC, como usar la altura del bloque + la posición de la transacción para determinar la identidad? ¿O determinar la identidad usted mismo en función del hash de entrada + salida de la transacción? De hecho, estos pueden usarse como identificadores únicos, pero son ineficientes en la práctica o no son tan convenientes y seguros como los ID de transacciones (los ID de transacciones se registrarán directamente en el contenido del bloque y nunca cambiarán después de cargarse en la cadena).
4. ¿Cómo resuelve segwit el problema de la escalabilidad de las transacciones?
Segwit resuelve eficazmente este problema al separar los datos de la firma de la transacción (testigo) del bloque, y cambiar la firma ya no afectará la ID de la transacción. Al mismo tiempo, segwit también reduce el tamaño del bloque hasta cierto punto y mejora las capacidades de procesamiento de transacciones (por ejemplo, spv puede procesar más contenido de transacciones con el mismo ancho de banda).
5. ¿Cómo se solucionaba este problema antes de segwit?
Después de que falla una transacción, debe informar un mensaje de error basado en la falla de la transacción en la cadena de bloques y verificar si dicha transacción se ha iniciado en la red dentro de un corto período de tiempo para determinar si ha sufrido un ataque de extensión de transacción. Al mismo tiempo, también debes intentar evitar hacer lógica en transacciones no confirmadas o transacciones confirmadas en unos pocos bloques. Pero estos métodos no resuelven fundamentalmente el problema.
