Una transacción non-SegWit tiene la siguiente estructura:

[nVersion (LE)][nInputs][txins][nOutputs][txouts][nLockTime (LE)]

Donde:

txins = [
for i in nInputs:
	+ iOutpoint (LE),
	+ iOutput (LE),
	+ ScriptSigSize,
	+ ScriptSig,
	+ Sequence (LE),
]

txouts = [
for i in nOutputs:
	+ Amount (LE),
	+ ScriptPubKeySize,
	+ ScriptPubKey,
]

Mientras que una SegWit tendrá esta estructura:

[nVersion (LE)][marker][flag][nInputs][txins][nOutputs][txouts][witness][nLockTime (LE)]

Donde:

witness = [
for i in nInputs:
	+ nStackItems[i]
		+ StackItemSize
		+ StackItem
]

Aparecen los campos marker y flag, los cuales deben tener los valores 0x00 y 0x01 respectivamente, para indicar que es una transacción SegWit. Por ahora estos campos siempre se ponen con estos valores, a la espera de que una futura actualización los emplee.

La proto-transacción es el conjunto de información sobre el que se firma digitalmente. La transacción final será —en líneas generales— el resultado de añadir a la proto-transacción, las firmas digitales.

Una proto-transacción non-SegWit tiene la siguiente estructura (para un input de este tipo): [2]

[nVersion (LE)][nInputs][txins][nOutputs][txouts][nLockTime (LE)][sigHashType]

Donde:

txins = [
for i in nInputs:
	+ iOutpoint,
	+ iOutput (LE),
	+ iPrevScriptPubKeySize,
	+ iPrevScriptPubKey,
	+ iSequence (LE),
]

txouts = [
for i in nOutputs:
	+ Amount (LE),
	+ ScriptPubKeySize,
	+ ScriptPubKey,
]

Una proto-transacción SegWit tiene la siguiente estructura (para un input de este tipo): [3]

[nVersion (LE)][hashPrevouts][hashSequences][txin][hashOutputs][nLockTime (LE)][sigHashType]

Donde:

hashPrevouts = dSHA256[
for i in nInputs:
	iOutpoint ‖ iOutput (LE) ‖
]

hashSequences = dSHA256[
for i in nInputs:
	iSequence (LE) ‖
]

txin = [
+ iOutpoint,
+ iOutput (LE),
+ iPrevScriptPubKeySize,
+ iPrevScriptPubKey,
+ iPrevOutputValue (LE), 
+ iSequence (LE),
]

hashOutputs = dSHA256[
for i in nOutputs:
	iAmount (LE) ‖ iScriptPubKeySize ‖ iScriptPubKey ‖
]

El símbolo «‖», implica concatenar previo ser aplicado el dSHA256. El símbolo "," implica crear una lista de elementos que más tarde se concatenarán al serializar la transacción o proto-transacción.

Una gran diferencia a la hora de serializar la proto-transacción es que con un input SegWit, a diferencia de un input non-SegWit, solo se incluye en el apartado de [txins] el input que se está firmando, y ningún caso se hará algún tipo de referencia al resto. Los demás inputs se vinculan con [hashPrevouts], a no ser que el sigHash Type sea ANYONECANPAY. Aunque esta forma de serializar también tiene sus detalles, para las transacciones más comunes (las que tienen sigHash Type ALL) se reduce la cantidad de operaciones a realizar, dado que:

[hashPrevouts], [hashSequences] y [hashOutputs] serán lo mismo para todos los inputs SegWit.

Cuando se incluye la información del input ([txin]), no hace falta estar permutando que scriptPubKey están vacíos y cuales no, puesto que solo se incluye ese input.

Se elimina la necesidad de volver a calcular los valores [hashPrevouts], [hashSequences] y [hashOutputs] y además, se elimina un bucle for que iba iterando por los inputs, reduciendo la complejidad. Tal y como se establece en el BIP143 [4], la complejidad se reduce de O(n^2) a O(n), resolviendo de esta forma el "Quadratic SigHash Scaling Bug".

Para inputs que no son SegWit la forma de serializar se mantiene.

SegWit_v0, que corresponde a P2WPKH y a P2WSH, las versiones SegWit de los previos P2PKH y P2SH.

SegWit_v1, que corresponde a P2TR.

Un script en Bitcoin es válido siempre y cuando sea distinto de cero. Por tanto, aunque las cláusulas empleadas para bloquear los fondos sean OP_0 OP_PUSH14 <20-byte-key-hash>, como el resultado de las mismas no es cero, el nodo non-SegWit lo dará como válido. Mientras que la clave pública no sea cero, todo bien. Dado que el scriptSig está vacío (0x00), lo que habrá en el stack será el OP_0 abajo y encima el hash de la clave pública. El nodo non-SegWit no entenderá nada, pero lo dará por válido.

Curiosidad: Si todos los nodos y mineros volvieran a una versión de Bitcoin previa a SegWit, los fondos bloqueados en condiciones de gasto SegWit estarían desprotegidos.

La actualización de SegWit trajo una nueva forma de medir la información (los bytes) y la cantidad máxima de bytes que puede haber en un bloque.

Donde antes había un límite de un 1MB por bloque, ahora ese límite se cambia a 4 millones de unidades de peso (WU, Weight Units).

Para medir lo que ocupa una transacción se hará lo siguiente:

Cada byte que ocupan los campos SegWit: [marker][flag][witness], contará como una unidad de peso (1 WU)

Cada byte que ocupan el resto de campos, contará como cuatro unidades de peso (4WU)

El total de [non-SegWit fields * 4 + SegWit fields * 1] será el peso de la transacción.

Es decir, se le está dando un descuento del 75% al espacio ocupado por los campos SegWit. Dado que los campos SegWit, principalmente el [witness] es gran parte de la transacción -las firmas ocupan mucho espacio- , estaremos consiguiendo aumentar el tamaño de bloque: lo que antes ocupaba 1 byte ahora ocupa 4WU, mientras que las nuevas partes ocupan 1WU por cada byte.

Si el bloque estuviera compuesto solo por transacciones non-SegWit, cabrían el mismo número de transacciones, ocupando como máximo 1MB (o 4MWU). Para un nodo non-SegWit, el tamaño de bloque sigue siendo el mismo.

Y ahora, manteniendo ese mismo límite, se incluye más información dado que para un nodo non-SegWit, los campos SegWit no existen. Esto es, a la vista de un nodo non-SegWit, hay más transacciones pero con menos información cada una de ellas.

El aumento efectivo de bloque es a 1.8MB de media. [5]

Tal y como lo entiendo, es una forma elegante de aumentar el tamaño de bloque sin realizar un hardfork. En realidad no estás aumentando el tamaño, solo estás dejando de incluir en un bloque non-SegWit cierta información que los nodos SegWit sí que tienen que almacenar. Para un nodo non-SegWit la máxima cantidad de información que puede entrar en un bloque sigue siendo de 1MB, dado que los bytes de información que le llegan son los que se multiplican por 4 al convertirlos en WU, manteniendo la paridad.

Esto es, eliminar todo lo que puedas de la transacción sin que esta deje de tener sentido, que se mantenga válida para los nodos antiguos y que contenga la suficiente información como para que no sea posible engañar.

En los bloques, para mantener la compatibilidad, la merkle root sigue siendo el resultado de los hashes en árbol de los txid de cada transacción.

Como los nodos non-SegWit no ven los campos SegWit, el txid de una transacción será dSHA256 de todos los campos que sí le llegan a un nodo non-SegWit.

Como consecuencia, se crea un nuevo concepto: el wtxid (witness txid). Este representa el dSHA256 de toda la transacción SegWit. Lo calcularán los nodos SegWit. Si una transacción es non-SegWit, el txid y el wtxid coincidirán.

Se plantea un problema: en los txid que finalmente componen la merkle root no se están teniendo en cuenta, y por tanto vinculando, los campos SegWit. Esto es, podrían ser modificados a posteriori sin invalidar el bloque.

Es por ello que se obliga a los mineros SegWit a calcular un nuevo elemento: el witness merkle root —siendo este el resumen en formato merkle root de los wtxid—, e incluir su hash como una salida OP_RETURN en la transacción coinbase. De esta forma, todos los campos de la transacción sean SegWit o no, están ligados al bloque en su conjunto y no pueden ser modificados.



Witness Merkle Root

En esta salida OP_Return es el resultado de dSHA256(witnessMerkleRoot ‖ witnessReservedValue), siendo el witnessReservedValue un campo de información todavía no empleado. [6]

Dado que el OP_Return y su contenido son elementos compatibles con nodos non-SegWit, esta forma de vincular la witness merkle root es también parte de que SegWit sea un soft-fork.

Con la activación de SegWit, al incluir en el merkle root el witness merkle root, se revertía por completo cualquier ventaja que tuviera un minero de usar la técnica "Covert" del ASIC Boost, dado que si cambia el orden de las transacciones a tal fin, tiene que volver a calcular el witness merkle root.

Firmar digitalmente con valor "k" distinto:

A la hora de firmar digitalmente, se emplea un valor aleatorio denominado "k". Debe ser mantenido en secreto, ya que constituye el compromiso de ocultación que evita la extracción de la clave privada. Este valor debe ser aleatorio y se puede modificar a voluntad del firmante. Un cambio en el mismo supone la creación de una firma plenamente distinta, aunque igualmente válida.

Invertir el valor "s" de la firma digital:

Una firma digital está compuesta por dos valores, "r" y "s". El valor "r" es la coordenada x del valor "R" en la curva elíptica y depende únicamente del valor "k". El valor "s" depende del valor "r", la clave privada, el valor "k" y el mensaje a firmar.

La verificación de una firma digital consiste en extraer un valor "v" de un cálculo con r, s, la clave pública y el mensaje, tal que "r" sea igual a ese valor. Esto es, se realizarán unos cálculos sobre la curva elíptica de tal forma que la coordenada x de R, el valor "r", sea igual a la coordenada x de V, el valor "v". A tal fin estaremos sumando puntos en la curva elíptica que dependen del valor s.

Dado que solo importa la coordenada x del valor V (el valor "v"), un valor de s invertido resultará en la misma coordenada x pero con una distinta coordenada y.

La inversa de s se puede obtener fácilmente calculando: n (Orden de la Curva Elíptica) menos s.

Con este método, un individuo ajeno a una transacción non-SegWit puede perpetrar el ataque de maleabilidad. Toma s, lo invierte y vuelve a mandar la transacción: sigue siendo válida, pero el txid ya ha cambiado.

Sin embargo este método fue paliado mucho antes de que SegWit lo resolviera: de los dos posibles valores de s, la reglas de estandarización obligaban a que en las firmas digitales siempre se incluyera aquel que fuera más bajo —conocido como Low S—. [7]

Se vincula la firma a la cantidad del input a gastar con el campo iPrevOutputValue

El ScriptpPubKey de la proto-transacción SegWit no es el Locking Script de tipo SegWit (OP_0 <20-byte-key-hash>), sino el Locking Script del tipo P2PKH (OP_DUP OP_HASH160 <20-byte-key-hash> OP_EQUALVERIFY OP_CHECKSIG).

SINGLE no se vincula al indice del input en cuestión de manera directa, sino que con hashPrevouts y txin ya se vincula a ese indice (se consigue el mismo efecto) y el hashOutputs será solo el dSHA256 del output con el mismo índice (si nInputs <= nOutputs). Si es SINGLE | ANYONECANPAY, se podrán intercambiar libremente los pares input-output de este tipo siempre que el par mantenga el input y el output en el mismo índice.

Si es ANYONECANPAY, hashPrevouts será el valor 0, expresado en un número de 32bytes: 0x0000000000000000000000000000000000000000000000000000000000000000

Si es ANYONECANPAY o SINGLE o NONE, hashSequences será el valor 0, expresado en un número de 32bytes, es decir, no se vinculan para estos casos los nSequence del resto de inputs: 0x0000000000000000000000000000000000000000000000000000000000000000

Si es NONE o SINGLE (con indiceInput > nOutputs), hashOutputs será el valor 0, expresado en un número de 32bytes: 0x0000000000000000000000000000000000000000000000000000000000000000