Hola jtimon, ¿podrías explicar cómo hace segwit para aumentar el tamaño de bloque? Puede resultar muy extraño para muchos oír que mantenéis el tamaño de bloque en 1MB pero por otro decís que segwit aumenta el tamaño de bloque. Por un lado se dice que segwit ordena mejor la información y caben más transacciones, también he oído que las transacciones segwit se saltan este límite de 1MB... Al final tenemos un lío tremendo.
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.
