¿Ha habido algún desarrollo o avance en la discusión de los desarrolladores de Bitcoin con respecto a este tema?
El único desarrollador que hizo varios intentos de bloquear Ordinals, con distintas estrategias, es Luke-Jr. Creo que DdmrDdmr, si mal no recuerdo, ya había posteado sobre su mecanismo que publicó en Bitcoin Knots (un cliente alternativo a Bitcoin Core dónde "manda" Luke). En Bitcoin Core este cambio fue
rechazado en septiembre. (Edit: Sí, ya discutimos el tema, a partir de
este post).
El problema es siempre el mismo: No hay mucho que se pueda hacer sin cambiar radicalmente el mecanismo de funcionamiento de Bitcoin.
Si bien se puede
hacer algo contra inscripciones grandes, tales como imágenes, videos y audio, limitando la cantidad de datos por transacción o por output (es la estrategia de Luke), esto solo resuelve una pequeña parte del problema, que ya casi no incide en el nivel de congestión. Además hay mineros y pools que ignoran este tipo de limitaciones, que no son duras sino que son una convención de "standardness", un bloque que contiene una transacción más grande de este límite sigue siendo válido (80 bytes por transacción en el caso de OP_RETURN; lo que hizo Luke era aplicar esta limitación a los datos de Taproot también).
Y el problema actual son las transacciones BRC-20 que son más pequeñas que este límite (50-60 bytes de inscripción por transacción). Eso ya lo discutimos hasta el hartazgo tanto acá como "en el norte", por eso creo que no hace falta repetir los argumentos.
Ahora en las discusiones en el subforo en inglés hubo un par de propuestas que
sí podrían lidiar con el problema, pero cambiarían el funcionamiento de Bitcoin.
Una, el cambio "menos radical", sería cambiar el esquema del "Segwit discount". Actualmente hay transacciones que pagan menos comisiones por byte que otras, que son las que usan "testigos" (Witness) del sub-protocolo Segwit. Las transacciones Ordinals normalmente usan este tipo de inputs y outputs por ende también se benefician.
Tranquilamente se podrían añadir otros tipos de transacciones que podrían "declararse" más baratas aún. Esto se conseguiría si se baja su "peso" en bytes virtuales (vBytes). Por ejemplo, yo en un momento propuse que se añada una clase de transacciones simples de pago, que consista solamente de inputs y outputs del tipo Segwit, sin OP_RETURN y sin contratos que no sean el simple chequeo de firmas, y darles un descuento adicional. (En realidad no es tan fácil, porque lo que se beneficia con descuentos actualmente no son
categorías de transacciones, sino
elementos de las transacciones. Pero sería posible.)
De hecho esto significaría que el tamaño de los bloques pueda aumentar. Si declaramos que las transacciones de este tipo solo pesen la mitad de las transacciones Segwit "comunes", el tamaño máximo de un bloque podría aumentar al doble, es decir teóricamente hasta 8 MB (el límite actual es de 4). Como ya dije no es tan simple pero para tener una idea
La segunda posibilidad es restringir el protocolo.
Lo que se ha propuesto pero actualmente no ayudaría en nada es dar marcha atrás con Taproot. Simplemente el spam se buscaría otro tipo de protocolo sin Taproot, como
Doginals DRC-20 o Counterparty.
Lo que sí ayudaría es cambiar al protocolo de Monero o Grin. En estos protocolos la cantidad de datos arbitrarios que se pueden almacenar en la blockchain es mínima. Es decir las transacciones BRC-20 serían 10 o más veces más caras (en el caso de Grin probablemente 100 veces) que las transacciones comunes de pago. Creo que ahí sí lo pensarían dos veces los spammers si realmente conviene especular con tokens.
Esto sería un cambio extremamente radical: No sería posible ni siquiera Lightning, las cadenas laterales tampoco.
La tercera posibilidad, la que favorezco yo, es avanzar de una vez con la flexibilización del Script (el lenguaje de programación de Bitcoin) para permitir cadenas laterales descentralizadas. Con una sóla cadena lateral podemos multiplicar por cien o más la capacidad de la blockchain sin tener que aumentar el tamaño de los bloques. Existen varias propuestas, algunas ya funcionan en Ethereum, como los rollups, y otras, como Drivechain, solo existen en testnets de distintas altcoins, pero ya se cuenta con algo de experiencia. Hace poco vi una propuesta nueva llamada
L2Ordinals para que al menos los Ordinals se puedan pasar a una cadena lateral, sin perder seguridad. No la he investigado todavía, pero podría ser interesante. Sobre estos temas si se está discutiendo en la lista de correos bitcoin-dev, pero la discusión va lenta.