Se han dado mucha prisa, calladitos pero currando: https://github.com/bitcoin/bitcoin/pull/7910
Falta que los mineros quieran aceptarlo, con lo que aún quedarían unos meses para que empezáramos a verlo en funcionamiento real.
Hace unos días leí que ya estaba testeándose:
E incluso ya han salido bloques de 3.6MB: https://segnet.smartbit.com.au/blocks?sort=size
¿Se ha metido en la 0.12.1 ya?
Lo malo de segwit es tendrían q hacerlo en un hardfork y lo van ha hacer de forma “chapucera” en un softfork.
Entiendo q esos 3.6 mb de bloque son porque se ha aumentado el tamaño del bloque porque lo q tengo entendido es q el tamaño del bloque seguira siendonde 1 mb aunque se integre segwit.
@johnlu nopis, todavía no se ha incluido en la versión actual.
En el roadmap vamos por el primer 0.12.x que corresponde con “Deploy OP_CHECKSEQUENCEVERIFY (BIPs 68 & 112) + BIP113 as first BIP9 versionbits soft fork” que me corrija alguien si me equivoco.
@franckuestein @Wopin lo de 3,6 mb no puede ser por que el bloque va a seguir siendo de 1 mb. Esto tiene que ser en una testnet y aun así no entiendo a que se refiere, quizás es una medida teórica.
@wopin Lo de que lo hagan en un softfork entiendo que es para mantener retrocompatibilidad. La verdad que el tema de soft vs hard sería un debate interesante, pero soy de la opinión que lo “duro” mejor cuanto menos.
Creo que hay planeado un hardfork para aumentar el tamaño de bloque para 2017… pero imagino que con la implementación de lighting network y las colored coins habrá mucho tráfico que salga de la blockchain “primaria” para incorporarse a canales secundarios.
Esto se está poniendo interesante… y creo que ya no hay quien lo pare.
Edito:
Tiene que ser una testnet si o si, fijaos en el número de bloque, son números muy bajos y distintos de la cadena principal. Y pa rematar la recompensa son 50btc… que tiempos aquellos!!!
Sí, sí. Obviamente las pruebas se están haciendo en una testnet
Sorry por el “captain obvious”.
Sigo buscando el sentido de los 3,6 MB de los bloques…
@nashos todo lo q he leido de segwit apunta a q deberia de ser un hardfork. Haciendo el softfork se va a implementar el codigo de manera superficial y el codigo va a quedar sucio, es de lo q mas se quejan los devs, sin embargo deberian integrarlo bien en el nucleo pero hace falta hardfork.
Con hardfork hay q teber mas cuidado pero no deberia dar problemas si todo el.mundo hace lo correcto en el momento indicado.
Yo creo q esos 3.6 indica q de la forma antigua es como si el bloque fuese de 3.6mb, nada mas. Pero es raro porque como.mucho dijeron q podrian aumentar la capacidad relativa en 0.6mb.
El que se haga como softfork en vez de hardfork es, como ya indiqué, por retrocompatibilidad. En el caso de que se decidiese por hardfork se obtendrían todas las ventajas del nuevo protocolo, ya que todo el mundo lo usaría, pero dejando fuera otros métodos. Tal y como indica el nombre segregated witness (testigo segregado) hay una parte de la información que se divide, eliminando las firmas de las transacciones históricas para reducir con ello el tamaño total de la cadena de bloques en un 60%.
En cuanto al tamaño, tal y como se indica en el enlace que incluí en mi anterior comentario, se podría llegar hasta los 4MB, que me imagino que serán los 3.6 que se ven en la segnet.
The current proposal for soft fork segregated witness (segwit) replaces the block size limit with a new block cost limit, counting each byte of witness data as 1 unit of cost and UTXO transaction data as 4 units; as a result, the maximum size of a block becomes just under 4 MB.
However, blocks are not expected to consist entirely of witness data, so blocks near 4 MB in size would be unlikely.
According to some calculations performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6 MB and a block filled with 2-of-2 multisignature transactions would be about 2.0 MB. It is further likely that future scaling improvements, such as Lightning, may slightly improve the ratio such that filled blocks become larger than 2 MB.
Cuando se introdujo las direcciones multifirma, si se hubiese optado por hardfork, ya nadie podría tener una dirección que no fuese multifirma, pero se optó por conservar esa “cualidad”. Una caja fuerte con más de un cierre es más segura que una que solo tiene un cierre, pero aun así puede haber gente que por cualquier motivo prefiera la de un solo cierre. Es una manera de ver como se pueden implementar nuevos métodos conservando los antiguos o bien de un plumazo cargarte una alternativa por que las consideraciones que estimes.
Aparte segwit trae consigo:
-
Solucionar la maleabilidad de las transacciones.
-
Implementar las actualizaciones de lenguajes del script más fácilmente.
-
Permite las pruebas de fraude.
-
Reducir los requisitos de ancho de banda para los clientes ligeros y para la sincronización inicial de la cadena de bloques.
Esto supongo que sera funcionalidad aparte de segwit, no tiene nada que ver con al finalidad de segwit.
Entiendo que es parte de segwit.
En el caso de la maleabilidad, el problema que argumentó Mark Karpeles como problema de Mt Gox, es el hecho de que se separen las firmas de las transacciones lo que lo resuelve el referido problema si no he entendido mal.
El hecho de que en los bloques se elimine información hará que la cadena de bloques sea menor… por lo tanto menos ancho de banda (esto es discutible, ya que los bloques tenderán a llenarse de nuevo).
En estos artículos seguro que lo explican mejor de lo que yo pueda hacerlo.
Gracias @nashos, ya habia leido los articulos de oroyfinanzas y creo q es el mejor sitio donde explica todo el entramado del segwit.
Como te comente antes esos puntos no son parte de la funcionalidad o del alcance de segwit ya q el objetivo era eliminar info de las tx que entre comillas sobraba, vamos eso creo yo a lo mejor me equivoco, pero no significa q no sean importantes, son muy importantes. Los habran metido junto a segwit en la testnet.
Lo q estoy viendo es q se habla mucho de esos 4 megas lo cual es mentira. El bloque seguira siendo de 1 mega solo q habran conseguido q entren hasta 4 veces mas transacciones dentro del bloque de 1 mega. Lo veo “publicidad engañosa”. Aparte, no se como narices algo q habian estimado de 1.6 megas de la antigua informacion ahora son 4!!!
Mi modo de verlo y explicarlo, chapucero y seguro que con bastantes fallos:
El límite de bloque no cambia, pero con Segwit se hace una especie de “compresión” del bloque para que lo que antes era 1mb ahora sea, pongamos, 0.6mb. El ratio de compresión es variable pero de facto supondrá que por lo menos tenemos capacidad para 2mb, e incluso dicen que están llegando a los 3.6mb aunque no será la norma. Esto supone más TPS ya que el bloque podrá contener más transacciones en el mismo tamaño máximo de bloque.
De paso, aunque no era el objetivo principal, se consiguió resolver un problema bastante importante, el de la maleabilidad de transacciones entre otras mejoras. Es como cuando haces limpieza y ordenas la habitación, no sólo está todo más bonito sino que es más fácil que no se te pierdan las cosas además de que la habitación parece más grande.
Hubiera sido mejor implementarlo con hardfork, pero si se puso tanto problema para el hardfork para subir el límite del tamaño de bloques, que por ahora no se hará hardfork sólo para esto si se puede hacer de otro modo menos problemático.
No existe una “compresión” sino que se eliminan datos, con lo cual se habilita más espacio.
Me quedo con la idea de la habitación
Edito:
Ojo, con otra ventaja, al ser más pequeñas las transacciones el precio de las mismas baja. Al menos mi cliente calcula el precio a pagar en función de los kb de la transacción, si se elimina información = menos kb = mas barato… todo son ventajas
Aquí explican el tema mucho mejor que yo. Lo malo que en inglés.
http://bravenewcoin.com/news/segregated-witness-has-been-released-tackling-bitcoins-transaction-limit/
Tener a Gavin a favor de utilizar SegWit cuanto antes me dice que implementarlo no será ningún dolor para nadie, y doblar o triplicar la capacidad de la red sin exigir mayor gasto a nodos y mineros sino todo lo contrario no está nada mal.
Sacado de reddit:
Pre-segwit:
The maximum allowed size for a serialized block, in bytes
= 1000000;
Post segwit:
The maximum allowed size for a serialized block, in bytes
= 4000000;
Crafty developers think that changing the name of a variable will confuse non programmers. Smart developers know that variables can be named “MAX_BLOCK_SIZE” or “MAX_BLOCK_SERIALIZED_SIZE” or “GREG_MAXWELL” because the symbol is not the thing.
In reality, Core is changing the block size limit without explicit consensus, which as Core devs have repeatedly pointed out, is a “coup” against the “economic social contract” equivalent to “stealing people’s Bitcoin” if there isn’t “overwhelming” community consensus.
So in their own words, Core is stealing your Bitcoin.
Me genera dudas de si solo es temporal en la testnet o lo incluiran en el commit o pull request.
Tienes que especificar que es r/btc y no r/bitcoin.
En primer lugar, no se hará el softfork a menos que el 95% de los mineros estén de acuerdo y las versiones antiguas de Bitcoin Core-QT no se verán afectadas. En segundo lugar, no cambia el límite de bloque.
Weno lo siento si no he puesto si es de uno u otro. A mi no me importa, solo quiero sacar la veracidad de las cosas no estoy para trolear ni nada por el estilo, solo queria q lo debatieramos.
En principio es lo q se ha comentado siempre, bloque a 1 mega. A ver si es q core q es la q esta dando por saco con la subida del tamaño del bloque va y lo pone ahora en 4mb!! Irreal jejej.
La verdad es que dudo que lo suban. Más bien me suena a que quieren hacer creer que con SegWit es lo mismo que subir a 4MB.
Suele importar bastante, en r/btc se leen a menudo cosas sin mucho sentido.