Segwit binance
El título formal «Testigo Segregado (Capa de Consenso)» tenía el número de Propuesta de Mejora de Bitcoin BIP141.[1] El propósito declarado era prevenir la maleabilidad de las transacciones de bitcoin no intencionadas, permitir la transmisión opcional de datos, y evitar ciertas restricciones del protocolo (como el límite de tamaño de bloque) con un soft fork.[2]
También pretendía mitigar un problema de limitación del tamaño de la cadena de bloques que reduce la velocidad de las transacciones de bitcoin. Lo hace dividiendo la transacción en dos segmentos, eliminando la firma de desbloqueo (datos del «testigo») de la parte original y añadiéndola como una estructura separada al final[3] La sección original seguiría conteniendo los datos del remitente y del receptor, y la nueva estructura del «testigo» contendría los scripts y las firmas. El segmento de datos original se contaría normalmente, pero el segmento «testigo» se contaría, en efecto, como una cuarta parte de su tamaño real.
Cada registro de una unidad de bitcoins se denomina «bloque», y todos los bloques se unen secuencialmente utilizando un hash criptográfico en el bloque anterior y almacenando su resultado en el siguiente. Esto forma una cadena de bloques, o blockchain.[4][¿fuente no fiable?]
La bifurcación de segwit
Bitcoin está lejos de ser perfecto. Tiene varios defectos que debemos abordar. La primera sección de este capítulo explicará algunos de estos defectos. Entre los más críticos están la maleabilidad de las transacciones y las ineficiencias en la verificación de firmas. Ya hemos mencionado la maleabilidad de las transacciones en la sección «Transacciones con bloqueo de tiempo» del capítulo 9: alguien puede cambiar una transacción de forma sutil, pero válida, mientras se está emitiendo, lo que hará que su txid cambie.
Una solución a estos problemas fue presentada en una conferencia de 2015 sobre el escalamiento de Bitcoin. Esta solución se conoce como testigo segregado (segwit), que es un nombre extraño para mover los datos de la firma fuera de las transacciones. Describiré esta solución en detalle: incluye cambios en casi todas las partes de Bitcoin, incluyendo las direcciones de Bitcoin, el formato de las transacciones, el formato de los bloques, el almacenamiento local y el protocolo de red.
Debido a que segwit fue un cambio bastante grande en Bitcoin, no fue trivial desplegarlo sin interrumpir la red. Se diseñó cuidadosamente para que el software antiguo siguiera funcionando y aceptando las transacciones y bloques de segwit, aunque sin verificar ciertas partes de las mismas.
Beneficios de segwit
El título formal «Testigo Segregado (Capa de Consenso)» tenía el número de Propuesta de Mejora de Bitcoin BIP141.[1] El propósito declarado era prevenir la maleabilidad de las transacciones de bitcoin no intencionadas, permitir la transmisión opcional de datos y evitar ciertas restricciones del protocolo (como el límite de tamaño de bloque) con un soft fork.[2]
También pretendía mitigar un problema de limitación del tamaño de la cadena de bloques que reduce la velocidad de las transacciones de bitcoin. Lo hace dividiendo la transacción en dos segmentos, eliminando la firma de desbloqueo (datos del «testigo») de la parte original y añadiéndola como una estructura separada al final[3] La sección original seguiría conteniendo los datos del remitente y del receptor, y la nueva estructura del «testigo» contendría los scripts y las firmas. El segmento de datos original se contaría normalmente, pero el segmento «testigo» se contaría, en efecto, como una cuarta parte de su tamaño real.
Cada registro de una unidad de bitcoins se denomina «bloque», y todos los bloques se unen secuencialmente utilizando un hash criptográfico en el bloque anterior y almacenando su resultado en el siguiente. Esto forma una cadena de bloques, o blockchain.[4][¿fuente no fiable?]
Precio de bitcoin segwit
Sé que normalmente cuando se usan direcciones heredadas las claves públicas por ejemplo estarán bajo Scriptig. Con P2SH, puedo ver que el ScriptSig contiene el hash del redeemScript que debe coincidir con el hash de la dirección en el Output ( creo). Pero no estoy seguro de los datos del testigo.
Para las variantes segwit de una salida (P2PKH se convierte en P2WPKH y P2SH en P2WSH), el testigo contiene los mismos datos que se encontrarían en el scriptSig. Para P2PKH, en el scriptSig, tendría una firma y una pubkey. Lo mismo se encuentra en el testigo para un P2WPKH.
Es importante tener en cuenta que el testigo tendrá un aspecto diferente al del scriptSig. Esto se debe a que no es realmente un script, sino una pila de elementos. Un scriptSig estándar es uno que sólo empuja elementos a la pila. El testigo lleva esto un paso más allá al proporcionar una pila para usar en lugar de tener que ejecutar un script que produce la misma pila.
Esta es una transacción mixta, con tres entradas «normales», y una cuarta entrada de tipo segwit (TX_IN[3]). Por lo tanto, después del campo de versión del tx vemos los bytes «0001», con 0x01 indicando que se incluye una estructura de datos segwit en el tx. En la sección de entrada, hay tres elementos «estándar» siguientes, también con firmas multisig. El cuarto elemento de entrada (TX_IN[3]) es la parte segwit. Los scripts se rellenan sin firmas, sólo con la estructura 0x0020{32-byte scripthash}.
