Bitcoin Core v29 vs v30

[MA40]

Hola.

Según he leído, la nueva versión de Bitcoin Core, la v30, prevista para ser lanzada en octubre, propone un cambio muy importante que tiene divididos a los bitcoiners.

Fuente: https://www.criptonoticias.com/tecnologia/bitcoin-core-v30-fragmenta-a-los-bitcoiners-por-que/

Parece ser que todo gira alrededor de aumentar los límites de OP_RETURN, de 83 bytes a 100.000 bytes.

Según los detractores, esto permitiría el spam y datos no deseados en los bloques, afectando la eficiencia y el propósito original de Bitcoin, además de aumentar considerablemente las tarifas de las transacciones.

Por otra parte, también hay beneficios, (aunque yo no los entiendo muy bien - si alguien sabe, por favor que explique).

Bueno… y ahora, a lo que voy: Siempre he oído que las decisiones en Bitcoin se toman por consenso. O sea, que todos tenemos derecho a emitir un voto con nuestra decisión.

Yo personalmente tengo dos nodos corriendo, uno completo y el otro podado. Entonces…, una vez tenga clara mi decisión, ¿de qué forma puedo ejercer mi voto en caso de no estar de acuerdo con este cambio? ¿Mantener la versión v29 de Bitcoin Core y no actualizar nunca? ¿O cómo?

Un saludo.

[famososMuertos]

Creo que el mejor, obviamente hay otros usuarios (LE) aquí que manejan de manera exquisita la parte técnica, pero puedo decir lo siguiente abajo, no sin antes permitirme hacer el tag a @d5000 quien maneja muy bien el tema, ojalá y nos recree con su opinión.

Hola.

Según he leído, la nueva versión de Bitcoin Core, la v30, prevista para ser lanzada en octubre, propone un cambio muy importante que tiene divididos a los bitcoiners.

Fuente: https://www.criptonoticias.com/tecnologia/bitcoin-core-v30-fragmenta-a-los-bitcoiners-por-que/

Parece ser que todo gira alrededor de aumentar los límites de OP_RETURN, de 83 bytes a 100.000 bytes.
:://::::

Te puedo decir, que si, hay una version en camino, pero la fecha no esta "aprobada" la fecha para el lanzamiento de esa version, ahora, eso tiene que ver con la fecha en que sale, no con la actualización de lo que se menciona en la fuente, que si esta señalada, no hay vuelta atrás.

https://bitcoincore.org/en/lifecycle/#schedule (aquí sale esa versión 30, pero su fecha esta en veremos)

:://:::
Bueno… y ahora, a lo que voy: Siempre he oído que las decisiones en Bitcoin se toman por consenso. O sea, que todos tenemos derecho a emitir un voto con nuestra decisión.
:::///

En esa idea, como usuario entiendo que cada actualización que llega a pasado por un consenso, y de hecho cada modificación importante tiene su BIP, en este caso por lo que se, ese, o esa actualización no existe o no tiene ese BIP, porque son propuestas que no necesitan de un consenso, como si sucede cuando se hace un BIP, que genera discusión y debate, y tal parece, que eso no ocurrió con esta modificación que estas señalando.

Luego, de ser así como se menciona, y tal parece que es así, la discusión fue entre los desarrolladores.

:://:::

En cuanto a lo que pregunta ve al minuto 25 y escucha hasta donde quieras.

Pero básicamente tiene relaciòn directa con la implementación de protocolos, hay protocolos que exceden el tamaño existente, y entonces se necesitan ampliar estos bytes, ahora el asunto es ese, no te sirve, entonces vete a otra cadena, simple... pero.

Para todo lo demás @d5000 y @haw... no recuerdo bien su nick completo, y/o @usuario que lo explique en palabras simples.

[Hispo]

La forma en que yo lo veo, aunque el uso de Bitcoin es descentralizado y las claves privadas dan control total sobre los fondos que tenemos, el desarrollo en si de Bitcoin está algo centralizado y la voz que realmente importa es de aquellos que están dentro del equipo de desarrollo de Bitcoin Core.

Creo que la mejor forma que ejercer tu voto o mostrar tu descontento con este tipo de cambios es que simplemente no actualices tu cliente de Bitcoin y continues teniendo tus nodos con la versión anterior, eso es todo.

Por otro lado, ya sería cuestión de abrir otro hilo completamente nuevo para discutir si esta actualización es conveniente para el propósito original de Bitcoin.

[btc-marty]

Por lo que he leido en el foro en ingles.


Aumentar el espacio de OP_RETURN .

Negativo:
Blockchain crecera mas rapidamente en tamaño?
Mas tiempo en sincronizar nodos mas peso. (Sobre esto decir que también es cierto que los pcs y discos van mejorando tambien, habra que aprovecharse de la ley de moore)
Gente diciendo que se usara para spam

Positivo:
Poder hace cosas mas complejas con bitcoin que con el tamaño anterior no se podian, algo de smart contracts o cosilla rollo layer 2?
Que los usurios dejen de usar otros espacio del bloque para meter ese supuesto spam o info y realmente usen op_return como ese espacio y dejen lo demas mas limpio y para lo que es.
Edit: Esa info/spam al ir en OP_return es prunable, en otros sitios no lo era.

Mencion tambien a @d5000 que parte de esto se lo lei a él por alli.
Se ve que maneja, si quiere contarnos algo al respecto.


Yo estoy corriendo nodo prune de core y no se que hacer, creo que paso de moverme, no creo que lo negativo sea para tanto. Me mola el rollo purista pero eso, ley de moore.

[d5000]

Según los detractores, esto permitiría el spam y datos no deseados en los bloques, afectando la eficiencia y el propósito original de Bitcoin, además de aumentar considerablemente las tarifas de las transacciones.

Por otra parte, también hay beneficios, (aunque yo no los entiendo muy bien - si alguien sabe, por favor que explique).

Discutí bastante sobre este tema en el foro inglés así que ahí va mi opinión.

En general el cambio de sacar los límites para OP_RETURN me parece razonable aunque yo hubiera preferido un cambio más gradual (por ejemplo, aumentar el límite primero a 1 kB).

Lo que hay que saber antes que nada, es que OP_RETURN no es el único método para insertar datos como imágenes y videos a la blockchain. Es sin embargo el más conveniente para los nodos, como explicaré más abajo.

Existe además el método Taproot, que todos conocemos por la ola de Ordinals. Consiste básicamente en meter los datos en el campo dónde va la firma digital, y este campo desde que se implementó Taproot, tiene más espacio que antes (por eso vimos los NFTs enormes en 2023).

Pero existe un tercer método mucho más "dañino" que es insertar los datos en claves públicas truchas. Por ejemplo se puede usar P2MS (un antiguo método para multisig), pero también P2PK o hasta P2TR. Este método se popularizó un poco en 2023 con Bitcoin Stamps o Stampchain. El gran problema es que estos datos no solo se quedarán para siempre en la blockchain porque el software no lo puede distinguir de claves públicas "reales" que se necesitan para la verificación del estado de la blockchain. Sino que además se almacenan en otra base de datos, el UTXO set, que son datos de los "outputs" de transacciones que los nodos cargan a la memoria para la validación de transacciones nuevas.

En teoría podés meter varios kB en claves públicas de este tipo, es decir sirve para imágenes y videos. Y este método no se puede prevenir con ningún tipo de "filtro" al estilo de los que se emplean en Knots.

Como ya bien dijo btc_marty, OP_RETURN tiene la ventaja que los datos que se almacenan con este método se pueden ignorar y "prunear". Pero hoy en día, las reglas para "transacciones estándar" (de esto estamos hablando aquí) le imponen más límites a este método que a los métodos más "dañinos".

La intención del cambio de v30 es por ende intentar que los desarolladores de NFTs, tokens etc. usen OP_RETURN para sus "creaciones" y no usen el método de las claves públicas truchas. Si Knots pasara a ser el cliente BTC más popular, es probable que los creadores de NFTs se vuelquen a mecanismos como el de Stampchain y eso aumente drásticamente el costo para los que operan nodos de Bitcoin, poniendo en peligro la descentralización.

[darbitmobilerecovery]

Gracias por traer el tema a la sección local y gracias a todos por als opiniones, porque la verdad que el otro día navegando por tw me apareció una discusión al respecto y se había puesto bastante seria la cosa.

Porque al parecer muchos del núcleo duro se están oponiendo fervientemente a esta modificación alegando que rompe el legado de satoshi y bla bla. Como todo cambio siempre va a provocar resistencia, como yo lo veo es que algunos cambios son necesarios el problema es como se usan esos cambios y como se controlan. Es verdad que en cierta manera se abre la ventana a ciertas cosas, pero tambien considero que es necesario retocar algunas cosas para aggiornarse.

Estoy de acuerdo con d5000 en el sentido de que el salto parece algo grande y se pudiera haber ido mas paso a paso, pero bueno eso tal vez supondría estar votando mas seguido o tocando mas sobre la marcha y de esta forma solo se hace una vez para muchos años.

[Hispo]

¿Alguien ha pensado en la implicaciones legales de almacenar información en un nodo local que cualquiera pudiese subir desde cualquier parte del mundo?
Es algo que se ha traído a la mesa antes, alguien podría, de forma mal intencionada, pagar una cantifad relativamente baja de dinero con la finalidad de llegar los nodos de Bitcoin alrededor del mundo con material ilegal.
Es posible hacer filtro de ello, claro está, pero la mayoría de los nodos por defafult to hacen tan cosa y simplemente se soportan la carga de cualquier cantidad de información guardada en la Blockchain de Bitcoin.

[d5000]

Es verdad que en cierta manera se abre la ventana a ciertas cosas,

A mi entender no se abre ninguna ventana que no estaba abierta antes. Con Ordinals podés crear NFTs de todo tipo y hay herramientas que lo facilitan bastante. Y aún si Luke hubiera podido implementar un filtro perfecto para Ordinals, siempre se podía usar Bitcoin Stamps para insertar imágenes de bastante tamaño (~100 kB), también está todo a tu disposición. Bitcoin Stamps es un poquito más caro en cuánto a fees, pero el "hack de Taproot" aún con OP_RETURN "liberado" sigue siendo el método más barato.

¿Alguien ha pensado en la implicaciones legales de almacenar información en un nodo local que cualquiera pudiese subir desde cualquier parte del mundo?

Ya hay contenido ilegal en la blockchain. Y como escribí arriba la ventana para cualquier tipo de contenido ya esta abierta desde hace rato, aún desde antes que los Ordinals existieran.

Hubo una discusión si es más fácil insertar datos contiguos con OP_RETURN que con Taproot, porque en el caso de Taproot si pasás datos de una foto directamente a un archivo de imagenes (tipo PNG) sin procesarla aparecerían unos puntitos rojos como se ilustra acá y en esta imágen. Sin embargo, no parece haber diferencia en lo legal. Pero es una de las razones por las que yo hubiera preferido un aumento a 512 B o 1 kB primero.

Lo que me preocupa un poco es que está tan politizada la discusión que me puedo imaginar que alguien trate de "vengarse" justo insertando datos ilegales apenas llegue 0.30.

[darxiaomi]

¿Alguien ha pensado en la implicaciones legales de almacenar información en un nodo local que cualquiera pudiese subir desde cualquier parte del mundo?
Es algo que se ha traído a la mesa antes, alguien podría, de forma mal intencionada, pagar una cantifad relativamente baja de dinero con la finalidad de llegar los nodos de Bitcoin alrededor del mundo con material ilegal.
Es posible hacer filtro de ello, claro está, pero la mayoría de los nodos por defafult to hacen tan cosa y simplemente se soportan la carga de cualquier cantidad de información guardada en la Blockchain de Bitcoin.

Es verdad lo que planteas pero como también es verdad que hoy en dia en la darkweb la hay, el tema es que no sea de tan facil acceso o tan publico. Es imposible impedir que algo de esto pase lamentablemente, tan solo se puede intentar suturar o dejarlo encerrado lo maximo posible.

La realidad es que el 99.9% de las personas jamas llegara a ese contenido.

[famososMuertos]

::/OP/::He visto esta actualización de la version v29.1  en el norte Bitcoin Core 29.1 https://bitcointalk.org/index.php?topic=5558598.0

Que es de "mantenimiento", digo por el ".1", viendo eso podemos intuir que los cambios importantes que generan la version 30 podría lanzarse el otro año, especulando, y no este año, tomando en cuenta que incluso podrían existir versiones de mantenimiento antes de la principal V30.

[Perejil]

Hola. Mi duda es (para alguien que al leer lo que decís arriba le suena a chino) si recomendáis actualizar a la 30 o es mejor esperar (solo tengo un nodo "pruned").

[d5000]

Hola. Mi duda es (para alguien que al leer lo que decís arriba le suena a chino) si recomendáis actualizar a la 30 o es mejor esperar (solo tengo un nodo "pruned").

Depende de cual sea tu objetivo ...

Todavía no hay necesidad de cambiar a 30. Hay muchos nodos que aún corren con la versión 28. Pero si querés estar al día con nuevas funciones, sí recomendaría pasarte a 30 en los próximos meses.

En cuanto al cambio de OP_RETURN hay dos cosas a tener en cuenta:

1) Si querés que tu nodo corra con el menor consumo de recursos (ancho de banda, computación ...) posible, es recomendable elegir una configuración que se asemeje a la de los mineros, porque debido al mecanismo de los "bloques compactos" esto evita tener que descargar transacciones dos veces al recibir nuevos bloques. Es decir: Si los mineros comienzan ahora a aceptar transacciones con datos OP_RETURN de >80 bytes e incluse de >1 kB, es recomendable usar Core 30 sin modificar la configuración de datacarriersize.

Tendría que analizar los bloques nuevos si eso es el caso ... Quizá alguien ya se dedicó a eso. Voy a preguntar "en el norte", ya que hay muchos hilos abiertos sobre el tema.

2) La otra pregunta es si querés participar en el "juego" de incentivar o no incentivar transacciones con datos, como NFTs (con imagenes, videos, audios etc.).

Si la respuesta es sí, mi recomendación sería actualizar a Bitcoin 30 pero con datacarriersize en un valor que te parezca oportuno. 83 (bytes) sería el número que se asemeja a la configuración de Bitcoin 29. 256, 512 o 1024 serían configuraciones que permiten algunos tipos de transacciones que antes no pasaban (como "anclajes" de cadenas laterales) pero no imágenes ni videos.

Lo que quiero decir es que no hace falta usar una versión obsoleta ni cambiar a Knots para seguir en control sobre esa configuración.

Ah, y Bitcoin 30 se publicó el 12 o 13 de octubre. Con los cambios anunciados en OP_RETURN, pero sin que datacarriersize haya quedado "deprecated" (obsoleto). Por ahora esta configuración se queda.

[famososMuertos]

:://::: un Perejil esa explicación que nos deja dcinco000 , en serio sin querer usar el Nick que pregunta de manera "disructiva"  

Creo que en el tema de las actualizaciones, al menos en mi caso a veces me cuesta actualizar sin revisar bien la trascendencia de la nueva actualización en mi competencia de uso y conocimiento, pero en todo caso uno puede mantener su versión a pesar de que te quieran poner nervioso con la idea de que si no actualizas la frase " estás expuesto" es tu (el) karma.

En todo caso, uno debe leer la numeración de las versiones, son fundamentales para que todos entiendan la relevancia, el riesgo o la importancia de la actualización. Al menos claro para los mortales que no tenemos Perejil en ese conocimiento profundo.

En esa idea de aquí en adelante todo lo que coloque en negrita lo he tomado de GS/(IA) en la colaboración para desarrollar mi idea de manera coherente y académica (*)

Dicho eso podemos comprender las actualizaciones desde lo que se conoce como Versionado Semántico ( por su denominación en inglés se conoce como SemVer):

Y aquí es donde viene lo que por experiencia de años conozco y desde temprano en mi cultura de seguridad aprendí, que la mayoría de Software utilizan el estándar mencionado para "comunicar" los cambios que trae la versión.

Que en la idea que nos compete es la versión de 3 números, que cada uno indica un tipo de importancia y relevancia:

MAYOR . MENOR . PARCHE

1. El Número MAYOR (Mayor: Cambios Incompatibles)

Cuando este número cambia (ejemplo: de 1.5.2 a 2.0.0), es la señal más clara de que la actualización es significativa y potencialmente problemática.
Riesgo: Alto. El desarrollador advierte que si actualizas, algo dejará de funcionar como lo hacía antes.

Motivo: Se elimina código antiguo, se cambian APIs (interfaces de programación), o el producto se reestructura a un nivel tan profundo que los usuarios y otros programas deben adaptarse.

Como puedes notar es el número más importante, pero así y todo la holgura de su importancia queda a discreción, pero debe hacerse, no hoy, pero mañana quizás si.

2. El Número MENOR (Menor: Nuevas Funcionalidades)

Cuando este número cambia (ejemplo: de 1.5.2 a 1.6.0), significa que la aplicación se ha hecho más capaz, pero aún mantiene compatibilidad hacia atrás.

Riesgo: Medio. Es generalmente seguro. Todo lo que funcionaba antes, debería seguir funcionando.

Motivo: Se añaden características, mejoras en la interfaz o se introducen nuevas herramientas que puedes elegir usar o no.

Ejemplo: Una aplicación de ofimática añade una nueva herramienta de análisis de datos

La información se entiende por si sola e incluso el ejemplo aclara cualquier duda, pero es como su nombre mismo en la descripción 'menor'.

3. El Número PARCHE (Parche: Corrección de Errores)

Cuando este número cambia (ejemplo: de 1.5.2 a 1.5.3), es la actualización más discreta y, paradójicamente, a menudo la más urgente.

Riesgo: Bajo. Son correcciones quirúrgicas; solo arreglan fallos.

Motivo: Se corrigió un bug (fallo) que causaba cierres inesperados o, crucialmente, se tapó una vulnerabilidad de seguridad crítica.

Urgencia: Si el parche corrige un fallo de seguridad importante, la actualización se vuelve urgente, ya que no instalarla te deja expuesto a riesgos.

Perejil ( cualquier usuario) ahí tienes esa explicación algo menos directo a lo que preguntaste, es más bien del tipo Cilantro, que por cierto no pretende contraponerse a lo antes mencionado, por d5cerocerocero para nada, de hecho gracias sos (SOS) mi ídolo en estos temas, el SOS es porque de verdad tus respuestas nos salvan y nos enseñan, Gracias por esa explicación d5000.

Finalmente me gustó repasar ese concepto, como dije no hay links ya que me lo repase vía IA porque tenía mis lagunas para traer el aporte en mi recuerdos.

En fin, a pesar de OP-Return bienvenida la V 30.0.0  

^{(Me quedé un poco extenso, pero ya saben dónde está la sustancia, uno queriendo ser espejo de sus ídolos)}

[Artemis3]

La única forma de mantener una negación plausible, es mantener nodos podados. Ya que correr un nodo completo te expone a peligros sobre contenido no deseado (ej: pedofilia).

Ya me dirás tu como ayudará a la descentralización la eliminación de los nodos completos. Tal vez no hacer nada hubiera sido mejor, de todas todas, no hacía falta facilitar el trabajo a los spammer...

Aunque supongo que habrá gente que se pasará al knots aunque sea por un tema de principios.

[btc-marty]

Como esta este tema?

Tengo el timeline/algoritmo de X lleno gente o bots discutiendo si bitcoin ahora se llenara de spam blablabla.

El Adam Back discutiendo con muchos criticos de la v30. Llevo poco en Bitcoin. No se si esto es comun en cambios de version o este esta siendo especial.

[d5000]

Ya me dirás tu como ayudará a la descentralización la eliminación de los nodos completos.

Yo creo que al final no los necesitaremos más. Habrá maneras de verificar la cadena completa sin conocer todos los datos de todas las transacciones. Y OP_RETURN es justo lo que menos hace falta para verificar la cadena (calcular la parte del merkle tree/el txid es suficiente).

Tal vez no hacer nada hubiera sido mejor, de todas todas, no hacía falta facilitar el trabajo a los spammer...

No creo que se les facilitó nada. Ordinals ya contaba con varias herramientas para inscribir lo que sea. Stampchain igual. Y si Luke activaba un filtro se organizaban los datos un poco diferente y listo. "El ratón siempre le gana al gato.", como dijo uno de los spammers (creo que fue mikeinspace, el creador de Stampchain), y tenía razón.

Igual hubo una novedad en los últimos días:

Como esta este tema?

Hubo una idea para un BIP que restringiría varias formas de almacenar datos (Taproot Inscriptions, y OP_RETURN) a través de un mecanismo de consenso. Esto es diferente a los "filtros de Luke" que trabajaban con las "políticas" (policy) de cada nodo, es decir cada nodo podía decidir si aplicaba estas reglas o no. Si el filtro es "por consenso", significa que todos los nodos tienen que seguir sus reglas, sino no se aceptarán bloques/transacciones.

El BIP estaba muy mal hecho, hubiera confiscado varios coins, y por ende no tiene chances de ser aceptado así. Aunque simpatizo un poco con la idea detrás. Pero no hubiera tampoco eliminado al spam tipo Spamchain que usa claves públicas falsas.

Se discute en el foro inglés aquí.