Topic: AMA: Soy un desarrollador de Bitcoin Core que habla español - page 3. (Read 14871 times)

La transacción del minero (coinbase transaction) tiene un hash a una estructura de datos (árbol merkle) con los testigos/witnesses. Como atencedentes parecidos, bip30 incluye el número de bloque (height) en la transacción coinbase. Altcoins usando minado conjunto (merged mining) como namecoin también usaban una estructura similar conteniendo un hash del bloque que se minaba en la otra cadena (aunque eso no tuviese ningún efecto en las reglas de consenso de bitcoin, sólo en las de la cadena alternativa).
Con segwit, para los nodos nuevos la estructura conteniendo los testigos es también parte del bloque. Los nodos antiguos no piden esa parte porque no la saben interpretar (simplemente la ignoran, ni siquiera la reciben).


Casi correcto. Porque, aparte del scriptSig, cada input tiene un nSequence y un puntero al output que gasta (prevout), esos se quedan en su sitio. En realidad el scriptSig también se queda, pero con contenido mínimo para indicar que se está usando segwit y se tiene que mirar en otro sitio.


Lo siento, me expresé mal. Las firmas no son más grandes, son los scriptSig los que son más grandes.
En un input que gaste un scriptPubKey con sólo un checksig normal sólo tienes una firma. En un input gastando un output con multisig tienes varias firmas (y cada una de ellas ocupa su espacio). Cada firma individual ocupa lo mismo (mucho).

Muchas gracias por la explicación!


¿Cómo funciona esto técnicamente? ¿Cómo es eso de, una parte del bloque que "no ven"?



Que es lo mismo que decir: tam_sin_inputs * 3 + tam_con_inputs <= 4M. Es decir, el tamaño de las transacciones sin inputs pero con outputs se multiplica por 3, y así es como se le da más peso a los outputs. Correcto?



Esto no lo entiendo. ¿Hay cambios en la forma de firmar? No puede haberlos, o los nodos antiguos se quedan fuera. ¿O quizá estás hablando implícitamente de multisig?

La ocasión lo merecía, gracias por la explicación.

Muy buena pregunta!
Creo que a veces se ha intentado explicar de forma simplificada o con analogías, y al final eso ha resultado en más confusión. Lo que dice th3nolo, por ejemplo, no es cierto, creo que es el resulado de esas explicaciones sobresimplifcadas de las que hablo. Lo que dice dserrano5 es más cercano a la realidad, pero voy a intentar dar una explicación más detallada para evitar confusión.

Las transacciones tienen outputs e inputs. Los outputs contienen un scriptPubKey, que define lo que necesitarás poner en el scriptSig del input que intente gastar ese output para que el script total, al juntarlos, sea válido.
Por ejemplo, un scriptPubKey podría contener "multisig 2 de 2 con las claves públicas K1 y K2", el scriptSig válido correspondiente en la transacción que gasta ese output contendría las firmas de la transacción con ambas claves, K1 y K2.

Con segwit, los scriptSig (las firmas, como dice dserrano5), se pueden almacenar en una parte del bloque que los nodos antiguos no ven (recuerda que para que sea retrocompatible, todo tiene que seguir funcionando para los nodos antiguos). No es que ese parte esté fuera del bloque, pero a los nodos completos antiguos se lo parece.

El antiguo límite de 1 MB tiene que mantenerse para los nodos antiguos pero a la vez, para los nuevos, se sustituye por otro límite de peso del bloque en vez de tamaño del bloque.
El nuevo límite es...tamaño del bloque sin los testigos separados (segregated witnesses) * 3 + tamaño total del bloque (incluyendo testigos) <= 4000000. Repito: tam_sin_witness * 3 + tam_con_witness <= 4000000

La fórmula está escogida para garantizar dos cosas:

1) que un bloque sin testigos separados de "1 MB" (realmente siempre fue 1000000 bytes) siga siendo válido con esta regla. Si tam_sin_witness es igual a tam_con_witness (es decir, no hay witnesses separados), entonces la fórmula puede ser simplificada a tam_sin_witness * 4 <= 4000000, que es lo mismo que tam_sin_witness <= 1000000, la regla actual.
2) que los testigos separados cuenten menos en el peso que el resto de las transacciones (o que los inputs cuenten menos que los outputs)

El punto 2 es el que consigue que los bloques puedan ser más grandes. ¿Por qué deberían contar menos los testigos separados?

Porque los testigos separados no se quedan en el utxo hasta que sean gastados. Una vez que lees y validas los testigos una vez, los puedes almacenar para compartirlos con otros nodos o los puedes simplemente borrar, porque ya no los necesitas.
Hay nodos que actuán en modo "prunning" (podado), es decir, borrando (podando) bloques antiguos (excepto lo que quede en el utxo, que lo sigues necesitando). Esto es bueno para nodos completos que tienen menos capacidad de almacenamiento.

Esto también es bueno para todos los nodos completos en general, pues todos tienen que mantener el utxo y con esto se cambian los incentivos para hacerlo crecer y decrecer.
Como las firmas son más grandes, los inputs lo son también. Esto lleva a que (sin segwit), es por lo general más barato incluir más outputs y menos inputs. Esto es precisamente lo contrario a lo que se quiere, pues por cada input, se cierra una entrada en el utxo y por cada output, se abre una nueva entrada en el utxo (excepto por casos especiales como OP_RETURN, que no pueden ser gastados y no hace falta ponerlos en el utxo). Los outputs deberían ser más caros que los inputs (pues a todos nos cuesta más mantenerlos en el utxo), pero sin segwit la situación era justo la contraria.

¿Cuánto incremento en tamaño supone esto entonces?

Si pudiese haber bloques que sólo tuviesen testigos/witnesses, el límite máximo sería de 4 MB, pero no es técnicamente posible en la práctica. Creando bloques con muchos inputs que gastan muchos outputs multisig (que tienen más firmas), se han conseguido crear bloques de 3.7 MB en testnet, pero esos mineros de testnet estaban simplemente probando el "peor caso", no se espera que esos bloques sean comunes fuera de testnet.

¿Cuál es un número más realista para bloques "normales" entonces?

En primer lugar habría que ver qué entendemos por un bloque "normal", por lo general se puede que considerar que "normales" son los bloques típicos recientes. Otra consideración es qué usuarios usarán segwit más rápido.
No es descabellado pensar que los que más incentivo tienen para usarlo serán los que más rápido lo empezarán a usar, una vez segwit sea activado. Es el caso de la gente que gasta outputs multisig, porque los inputs de multisig son muy grandes y, por tanto, caros.
Usando segwit, sus inputs resultan más pequeños (o menos pesados) para los mineros y por tanto los aceptarán con comisiones menores que gastando el mismo multisig sin usar segwit.

Suponiendo que todos los usuarios de multisig se pasan a gastarlos con segwit (que les conviene mucho), con el uso porcentual de multisig con el resto de transacciones, parece que podríamos esperar un límite en la práctica de cerca de 2.1 MB. Pero quizá después de activar segwit más gente empieza usar multisig (al ser más barato que antes).
La gente que no usa multisig también puede usar segwit y hacer que sus firmas pesen menos (y también les conviene, simplemente menos). Meses atrás, una cifra que se oía más comunmente era 1.7 MB. ¿Cómo puede haber cambiado? El código no ha cambiado, simplemente el uso porcentual de multisig ha crecido y las estimaciones han cambiado, pero al fin y al cabo esto son sólo estimaciones y cuánto de esos 4 MB teóricos (pero imposibles en la práctica) se usen dependerá del uso que los usuarios hagan de segwit.

Si me he enrollado demasiado...lo siento, pero mejor que sobre explicación a que falte creo yo.
Si me he puesto demasiado técnico, no dudéis en pedir aclaraciones a puntos concretos.

Las transacciones contienen una firma. Bajo segwit, la firma no se almacena en el bloque, sino aparte. De esta forma, caben más transacciones por bloque, lo que a efectos prácticos es como aumentar el tamaño. Los bloques siguen siendo de 1 Mb, y el consumo de disco duro no varía.

Es como si, en lugar de meter botellas de agua en un cajón, almacenas el agua aparte y metes las botellas vacías, aplastadas (pero el incremento de capacidad en el caso de bitcoin no es tan dramático).