Bitcoin será aquel que haya arrastrado con él el mayor consenso económico detrás (y, como los mineros persiguen al consenso económico y no al revés, también la mayor potencia de minado). No hay forma de saber cuál es el "Bitcoin bueno" si, sencillamente, un 5% de los mineros tiene derecho a veto porque, entonces, el Bitcoin bueno será "ninguno". O "cualquiera, siempre que no toque las espectativas de beneficio futuras de los mineros".
Eso es injusto.
Injustísimo. Pero no creo que esto lo solucione.
No ignora la prueba de trabajo. Sin prueba de trabajo, la nueva cadena se quedaría "bloqueada" en el primer bloque. Eso sí, si algo de prueba de trabajo la respalda, entonces esa cadena empezará a crecer (lentamente al principio, hasta que alcanzase la revisión de dificultad) y, si la prueba de trabajo que la respalda termina resultando ser mayoritaria como consecuencia del consenso económico que arrastra, entonces podría llamarse legítimamente "BITCOIN".
Semejante consenso (social, ya que la PoW iría aparte) coordinado entre exchanges y actores económicos me parece una utopía.
UASF no viola las normas de consenso. Lo que, a mi entender, hace UASF es algo legítimo: utiliza toda la red Bitcoin para coordinar la introducción de unas nuevas reglas. Así que, desde mi óptica purista e intolerante, UASF sería una "shitcoin" mientras no alcanzase el 51% de la tasa de minado de Bitcoin.
Toda la red no se va a poner de acuerdo ni de coña, eso es imposible. Basta un solo actor para que eso no ocurra y además no se puede cuantificar de forma fiable cuánto apoyo de la red tiene cada parte.
Eso es así y así hay que reconocerlo. UASF sería una shitcoin que habría empleado la red Bitcoin DE UNA FORMA LEGÍTIMA para coordinar el inicio de sus andanzas. Un purista no puede censurar un uso legítimo de Bitcoin.
Eso sí, si esa shitcoin termina fagocitando consenso económico de Bitcoin y, como consecuencia, termina atesorando más del 51% de la tasa de hash de Bitcoin, entonces pasaría automáticamente a considerarse "BITCOIN".
Esa es mi visión pero, si lo miras fríamente, no es tan diferente de la tuya. Tu umbral para dejar de llamar Bitcoin a unas reglas y pasar a llamárselo a otras reglas es del 95% (el umbral mínimo que establece el sistema de señalizado de bloques). Bien, pues el mío sencillamente es el umbral del 51%. Cuando otro conjunto de reglas reúne suficiente consenso económico anterior como para arrastrar con él el 51% de la tasa de hash, es el nuevo "BITCOIN".
Yo no he dicho eso en ningún momento. UASF es un cambio concreto que no tiene nada que ver con porcentajes de minado y que simplemente los ignora, dando lugar a un comportamiento completamente errático que desacopla nodos-no-mineros de nodos-mineros.
Eso es todo menos elegante y predecible.
Además tú mismo estás diciendo que los mineros seguirían estando en su cadena no-SegWit, que es el conjunto de reglas al que mostraban apoyo antes. ¿Dónde está el problema? Ahí no hay ningún ataque.
El problema es que ese procedimiento es el más caótico posible y durante un tiempo indeterminado no tendríamos ni pajolera idea de qué cadena es la "buena", si es que alguna vez se impone alguna y no tenemos dos cadenas coexistiendo por un período largo de tiempo.
UASF sólamente es un mecanismo de creación de softforks. Supongo yo que algún desarrollador podrá perfectamente sacar UASF-BIPXXX para apoyar explícitamente a un determinado fork y, una vez allí, siempre puedes replantearte apoyar otros forks o no.
Mañana mismo puedo sacar otro SF que comparta los bits con SegWit y UASF no sería capaz de saber cuál es el código bueno (en este caso sí por el mero renombre, pero en otros casos podría pasar que no). Al ser un SF entraría automáticamente en los nodos que así lo dispusieran. No hay forma de cuantificar qué huevones está pasando, ni veto, ni supervisión. La correspondencia entre bits y código ahora mismo se supervisa por los mismos mineros, que no anuncian cosas que no saben lo que son (supuestamente). En ese hipotético escenario no hay referencias. Habría que poner un comité central para decidir qué código se atribuye una versión determinada en el espacio versionbits. Ahora mismo, esto es informal porque esos cambios no se aplican automáticamente. Si la capacidad de apropiarse una versión fuera poner algo en github, habría que chapar el repositorio para "untrusted users".
A mi me parece más elegante este método porque es más previsible y tras*parente.
:
:
:
A mí me parece lo menos previsible y tras*parente que se ha visto en este mundillo, que ya es decir. Sin entrar en valoraciones sobre la elegancia del método.
La verdad es que ya estoy hasta quemado de discutir este tema de lo absurdo que me parece. No entiendo cómo nadie que no quiera cargarse este tema lo propone, simplemente se me escapa.
