Dura verdad re: Drama de bifurcación dura de Luke: No creo que haya nada de malo en construir un cliente _alternativo_ que se sincronice con la última y más pesada información de cadena por medio de ZK, incluso si eso significa no descargar todo el contenido del bloque ... ni siquiera si hay un consorcio centralizado (multisig) que tiene control sobre qué partes de la cadena se validan a través de ZK y las partes se validan normalmente Incluso si eso significa que el _reference client_ (Core) se atascaría sincronizando la cadena si los ÚNICOS datos disponibles en toda la red fueran los que alojó mi cliente alternativo Sería un problema si el *cliente de referencia* (o el "cliente de la gran mayoría") adoptara esto... Porque si la gran mayoría de la red lo ejecutara, podría conducir a situaciones de división de la cadena También podría ser un problema si el cliente alternativo que adopta esto se empareja con otros nodos en la red, haciéndose pasar por si tienen los datos completos de la cadena de bloques, cuando en realidad no los tienen, y tratara de servir pruebas ZK irreconocibles en lugar de datos reales de tx a pares desprevenidos por alguna razón Eso equivaldría a un ataque de eclipse, pero no tenemos ninguna razón para creer que alguien haya planeado o planee algo por el estilo En realidad, tales nodos (si son honestos) probablemente simplemente anunciarían un bit de servicio adecuado que comunica a los nodos de sincronización (IBD) que no tienen todos los datos Al igual que los nodos principales podados en la red (bit de servicio: NODE_NETWORK_LIMITED == la forma en que su nodo dice "No tengo todo el historial de bloques ... tienes que mirar con otra persona si quieres hacer una sincronización completa") No soy un experto en la mecánica de sincronización de Core, pero creo que los nodos Core ya priorizan las conexiones que transmiten que tienen los datos completos de la cadena de bloques, y desalojarán/rotarán de los pares limitados que no pueden servir a la historia completa En general, siempre es responsabilidad del cliente principal rotar pares y encontrar conexiones honestas en la red, tener resistencia contra situaciones similares a ataques de eclipse intencionalmente adversarios y no intencionalmente adversarios en la red 🔸🔸🔸🔸 Ahora, donde las cosas se ponen feas es si no solo lancé/construí/planeé lanzar este cliente alternativo, sino que también infundí miedo públicamente sobre cómo el cliente de referencia ***garantiza la muerte de Bitcoin*** y también estaba explorando caminos legales para desincentivar a los nodos o grupos de minería a ejecutar Core. No sé mucho sobre esta última parte (legal), así que no hablaré de ella. De todos modos, esa es la esencia de por qué algunas personas dirán que lo que Luke estaba planeando no era un hardfork de censura (y solo un cliente hardforking en una definición técnica estricta porque puede desencadenar una división de cadena en condiciones poco probables), mientras que otros observan el contexto legal / alarmista que lo abarca todo pinta una imagen bastante nefasta. Fin.

y *cuáles* porciones se validan normalmente... Error tipográfico en el primer párrafo

En el caso de Knots, lo anterior podría muy bien ser una característica opcional, no algo que todos los nodos harían de forma predeterminada.