La dura verdad sobre el drama del hardfork de Luke: No creo que haya nada de malo en construir un cliente _alternativo_ que se sincronice con el último y más pesado chaintip mediante ZK, incluso si eso significa no descargar todo el contenido de los bloques... 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 qué partes se validan normalmente. Incluso si eso significa que el _cliente de referencia_ (Core) se quedaría atascado sincronizando la cadena si los ÚNICOS datos disponibles en toda la red fueran aquellos que mi cliente alternativo alojara. SERÍA un problema si el *cliente de referencia* (o el "cliente de la vasta mayoría") adoptara esto... porque si la vasta mayoría de la red lo ejecutara, podría llevar a situaciones de división de cadenas. También podría ser un problema si el cliente alternativo que adopta esto se conecta con otros nodos en la red, haciéndose pasar por si tuvieran todos los datos de la blockchain, cuando en realidad no los tienen, y tratara de servir pruebas ZK no reconocibles en lugar de datos de transacciones reales a pares desprevenidos por alguna razón. Eso sería equivalente a un ataque de eclipse, pero no tenemos razones para creer que alguien haya planeado o planee algo así. En realidad, tales nodos (si son honestos) probablemente simplemente anunciarían un bit de servicio adecuado que comunica a los nodos que se están sincronizando (IBD) que no tienen todos los datos. Al igual que los nodos Core podados en la red lo hacen (bit de servicio: NODE_NETWORK_LIMITED == la forma en que tu nodo dice "No tengo toda la historia de bloques... tienes que conectarte con alguien más 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 conexiones que transmiten que tienen todos los datos de la blockchain, y expulsarán/rotarán fuera de los pares limitados que no pueden servir la historia completa. En general, siempre es responsabilidad del cliente Core rotar pares y encontrar conexiones honestas en la red, para tener resistencia contra situaciones de ataque de eclipse intencionalmente adversariales, así como adversariales no intencionales en la red. 🔸🔸🔸🔸 Ahora, donde las cosas se complican es si no solo lanzara/construyera/planeara lanzar este cliente alternativo, sino que también hiciera un alarmismo público sobre cómo el cliente de referencia ***garantiza la muerte de Bitcoin*** y también estuviera explorando caminos legales para desincentivar a los nodos o grupos de minería de ejecutar Core. No sé mucho sobre esta última parte (legal), así que no hablaré de ello. 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 de hardfork en una estricta definición técnica porque puede desencadenar una división de cadenas en condiciones poco probables), mientras que otros observan el alarmismo/contexto legal que pinta de manera abarcadora un cuadro bastante nefasto. Fin.

y *qué* porciones se validan normalmente... error tipográfico en el primer párrafo

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