No. No. Seamos precisos. El señalar o no un bloque no supone ningún coste de oportunidad. Cuando llegue el día de activación del SoftFork (si llega), el minero siempre podrá elegir si mantener su palabra o no, así que el hecho de señalar no tiene un coste de oportunidad.
En el momento en que hay riesgo de que pasen normas que no cumples, hay coste real.
Por la cuenta que le trae, ya se molestará el usuario en conocer con cuánto apoyo cuenta en cada uno de los contrapoderes de Bitcoin y si es suficiente para sus prioridades o no.
El problema es que no hay una forma fiable de hacerlo a todos los niveles.
Sigo sin ver el problema, claro está, siempre que sean SoftForks (retrocompatibles)
[...]
¿Cómo que "actualmente"? Que yo sepa, en la propuesta del UASF no se hacía obligatorio nada. ¿Ha cambiado algo al respecto?
¿Puedes enviarme a algún sitio donde pueda leer más sobre esta parte?
No tengo nada aparte de los enlaces de ayer y el código, la verdad. No hay mucho escrito de momento, que yo sepa.
UASF hace el SF obligatorio. De modo que nuevos bloques *creados* no-SegWit serían rechazados por los nodos y mineros UASF tras la activación.
La retrocompatibilidad es parcial: las normas antiguas consideran los bloques nuevos válidos, pero no al reves, y además UASF elimina el elemento opt-in. Es decir, que los mineros que generen transacciones de las antiguas simplemente por seguir operando igual verían sus bloques "orfanados" por los nodos y mineros UASF, que podrían perfectamente estar en minoría.
Sería muy difícil convencer al mercado de que la cadena buena es la corta y la que acaba de cambiar el statu quo.