Qué cambia y qué no
La recompensa y los límites por bloque se dividen por diez, así que la emisión y la capacidad por hora no cambian. Para que las reglas que hoy cuentan bloques sigan funcionando, el CHIP agrega los ticks, una unidad de tiempo idealizado.
| Hoy: 10 min | CHIP: 1 min | |
|---|---|---|
| Bloques por día | 144 | 1440 |
| Emisión y capacidad por hora | igual | igual |
| Trabajo detrás de una confirmación | 1 | ≈ 1/10 |
| Primera confirmación: espera de más de 14 min | 24,7 % | < 0,1 % |
| Espera media para igualar 15 confirmaciones de hoy | 150 min | 150 min |
| Crecimiento de la cadena de headers | 4,2 MB/año | 42 MB/año |
| Bloques huérfanos estimados por día | — | 6 a 28 |
La calidad técnica del CHIP es alta. La discusión es si conviene activarlo y si es la forma correcta de resolver lo que dice resolver.
Qué busca el CHIP
Ante la objeción de que su lista de beneficios cambiaba con el tiempo, el autor respondió que el objetivo del CHIP son los bloques más rápidos, y que cada tipo de usuario los aprovecharía de un modo distinto. Estos son los argumentos a favor, en su mejor versión:
- Primera confirmación más rápida
- Para swaps entre cadenas, pasarelas y billeteras multimoneda que no aceptan 0-conf. El 95 % llegaría en menos de tres minutos.
- Confirmaciones múltiples más previsibles
- Para operaciones de alto valor, la espera tendría mucha menos dispersión.
- Recuperación más rápida en DeFi
- Cuando dos usuarios chocan sobre el mismo UTXO, reintentar tomaría de uno a tres minutos en lugar de diez a treinta.
- Una «escala deslizante»
- Elegir con más finura entre velocidad y seguridad: «100 dólares de seguridad en un minuto y 1000 en diez».
- Beneficios secundarios
- Locktime más granular, pagos más frecuentes a pools chicos y un ajuste de dificultad que reacciona antes.
- El costo de no hacer nada
- Los usuarios nuevos comparan con cadenas más rápidas, y cada año más software asume los diez minutos como fijos.
La pregunta no es si estos beneficios existen, sino si justifican lo que cuestan y si este es el modo correcto de obtenerlos.
El problema es real, pero el cambio no lo elimina
En los tres casos que justifican el CHIP, el problema sigue existiendo después del cambio.
2.1Una confirmación: mejora de verdad
El tiempo entre bloques sigue una distribución exponencial: la espera promedio es de diez minutos, pero la dispersión es igual de grande que el promedio. Según el propio CHIP, una de cada cuatro transacciones espera más de 14 minutos, y una de cada siete, más de 20.
Con bloques de un minuto, la primera confirmación llega mucho antes. Ese beneficio es cierto, y conviene reconocerlo.
Exchanges: previsibilidad, no velocidad
Kraken exige hoy 15 confirmaciones de BCH. Con bloques de un minuto, para obtener una seguridad comparable harían falta unas 150. El tiempo medio de espera sería el mismo: unos 150 minutos.
Lo que cambia es la dispersión: con seis confirmaciones de diez minutos, la probabilidad de esperar más de 90 minutos es del 11,6 %; con sesenta de un minuto, del 0,03 %.
2.2DeFi: la colisión sigue ocurriendo
Cuando dos usuarios operan sobre el mismo UTXO, los nodos ven versiones distintas de la mempool y una transacción falla. Con bloques de un minuto el error dura menos, pero sigue apareciendo. En palabras de rnbrady: «deberíamos resolver el problema por completo».
La solución está en la capa donde se genera el problema: ordenar las solicitudes en la aplicación y avisar las colisiones con DSProofs.
2.3Una solución permanente para un problema temporal
Buena parte de los casos que invoca el CHIP dependen de terceros centralizados: exchanges, pasarelas y billeteras multimoneda que exigen confirmaciones. Las últimas actualizaciones de la red, como CashTokens y la introspección nativa, apuntan justamente a depender menos de ellos. Es contradictorio cambiar para siempre una constante del protocolo para acomodar a los actores de los que la red intenta independizarse.
Los costos
Son concretos, y todavía nadie los midió.
3.1Clientes SPV: el costo central
El costo recae con más fuerza justamente sobre las billeteras que menos dependen de terceros.
| Tipo de billetera | Ejemplo | Cómo funciona | Impacto |
|---|---|---|---|
| SPV propiamente dicha | Flowee Pay | Descarga todos los headers y pide bloques filtrados; verifica cada pago sin depender de un servidor. | Alto |
| Protocolo Electrum | Electron Cash | Descarga headers desde un checkpoint. | Medio |
| Móvil con servidor | Muchas | Consulta servidores Fulcrum; el costo pasa al servidor y la dependencia de él crece. | Indirecto |
| Dimensión | 10 min | 1 min |
|---|---|---|
| Almacenamiento de headers | 4,2 MB/año | 42 MB/año |
| Sincronizar un mes | 4300 | 43 000 |
| Pago por NFC con una semana de headers | 80 KB / 1,5 s | 800 KB / 15 s |
3.2Menos trabajo por bloque, poco margen de huérfanos
Una confirmación de un minuto respalda alrededor de una décima parte del trabajo. A Calin Culianu, desarrollador principal de BCHN, le parece «fundamentalmente incorrecto» dividir así una cadena con una fracción mínima del hash total.
Cuanto mayor es la tasa de huérfanos, más ventaja tienen los pools grandes. El peor caso que modela el CHIP queda a seis centésimas del umbral que él mismo define como tolerable. La tasa real recién se conocerá con la red funcionando.
3.3Complejidad permanente
Los ticks resuelven la compatibilidad de los contratos, pero agregan una abstracción que queda para siempre: alturas de bloque, ticks, confirmaciones en bloques y confirmaciones en ticks. Lo que menos le gusta a Culianu es la redefinición de nLockTime, que vuelve «muy difícil razonar» sobre esos campos.
«Para quien lo implementa, es como si hubiera estallado una bomba en el código. Todo se tocó.»
Calin Culianu, BCHN, octubre de 2026
3.4Costos de activación sin cuantificar
El CHIP describe los costos para nodos, minería, exchanges, billeteras, exploradores, indexadores y DeFi como «reales pero acotados», sin números. Que los equipos conozcan la propuesta no es lo mismo que haber estimado cuánto les cuesta adaptarse. El riesgo principal, que el propio CHIP reconoce, es el software que acredita depósitos por cantidad de confirmaciones y pasa a exigir, sin saberlo, una décima parte del trabajo.
3.5Se mejora una experiencia empeorando otra
Para mucha gente, «confirmada» significa «definitiva». Cuando un bloque queda huérfano, un pago honesto no se pierde: vuelve a entrar en el bloque siguiente. Pero el comerciante que esperaba una confirmación lo ve cambiar de estado. Y revertir un pago con una confirmación le cuesta a un atacante unas diez veces menos, sin que nadie se lo avise.
- t = 0Confirmado1 confirmación
- +1 minSin confirmarEl bloque quedó huérfano
- +2 minConfirmadoEntró en el bloque siguiente
Principios
- 2017Bloques de 8 MB, nuevo ajuste de dificultad10 min
- 2018Bloques de 32 MB10 min
- 2019Firmas Schnorr10 min
- 2020ASERT, tercer ajuste de dificultad10 min
- 2022Introspección nativa10 min
- 2023CashTokens10 min
- 2024ABLA, límite de bloque adaptativo10 min
- 2025Límites de la VM y enteros grandes10 min
- 2027?CHIP-2025-031 min
- 4.1 El mecanismo, no la constante
- BCH reemplazó tres veces su algoritmo de dificultad, pero esos cambios mejoraron la forma de sostener los diez minutos; no los redefinieron.
- 4.2 Un parámetro de coordinación
- El tamaño de bloque lo equilibran los incentivos de cada minero, y un límite puede relajarse sin romper nada. El intervalo es necesariamente un acuerdo de toda la red, no cambia los incentivos y volver atrás costaría tanto como el cambio.
- 4.3 0-conf, la respuesta que dimos durante años
- Quien no sigue el foro va a ver que la red que respondía «no hace falta esperar diez minutos» cambió su protocolo para no esperarlos. Esa lectura le resta credibilidad a 0-conf justo donde funciona.
- 4.4 Identidad
- rnbrady, kanat y Zander desaprobaron el cambio con la misma idea: «si no está roto, no lo arregles». Una objeción social persistente es, en sí misma, un costo de coordinación.
Una observación secundaria: la adopción de comercios
En la adopción directa con comerciantes, en Argentina y en otros lugares, el tiempo entre bloques nunca fue un obstáculo real. Entre usuarios, las transacciones se aceptan de inmediato, y herramientas con soporte de 0-conf, como prompt.cash, se usan sin problemas para ventas en línea. Donde 0-conf funciona, la espera de diez minutos no es el obstáculo.
Lo que se puede hacer sin cambiar el intervalo
En casi todos los problemas que invoca, el CHIP mitiga sin eliminar, y en la mayoría hay caminos que no requieren tocar una constante fundacional.
| Problema | Qué hace el CHIP | Alternativa sin cambiar el intervalo |
|---|---|---|
| Primera confirmación lenta y variable (swaps, pasarelas, billeteras multimoneda) | La acelera | DSProofs con evaluación de riesgo y políticas según el monto, que ya usan Bitgree y Thorswap |
| Confirmaciones múltiples en exchanges | Da previsibilidad, no velocidad | Exigir confirmaciones según el valor y el riesgo, no un número fijo |
| Contención de UTXO en DeFi | Acorta la espera; la colisión sigue | Ordenar las solicitudes en la aplicación, repartir la liquidez en varios UTXO, extender los DSProofs a contratos |
| Bloques de una hora o más por caídas de hashrate | Los acorta | Estudiar la reacción del ajuste de dificultad como un problema propio |
| Granularidad del locktime | La mejora | El locktime por tiempo ya existe |
| Primera impresión de los usuarios nuevos | Indirectamente | Billeteras que muestren los pagos con 0-conf como recibidos; comunicación |
Las alternativas no eliminan toda espera, pero reducen los casos que dependen del tiempo de bloque. Y si un tercero no las adopta, nada empeora. Si no se adapta al CHIP, en cambio, sus 15 confirmaciones pasan a valer una décima parte del trabajo sin que lo sepa.
El pedido: no en 2027
Mi pedido es concreto: que el CHIP-2025-03 no haga lock-in el 15 de noviembre de 2026 y que se vuelva a discutir para una actualización futura, una vez agotadas las alternativas. Para activar un cambio así, los beneficios deberían superar con claridad la suma de los costos. Como mínimo, antes de cualquier activación debería cumplirse esto:
- Cuantificar los costos de activación con estimaciones de nodos, pools, exchanges, billeteras, indexadores y DeFi, y con criterios para detectar el software que se rompe en silencio.
- Desplegar primero las mitigaciones para SPV (filtros compactos, sincronización por lotes, CHIP-2026-02) y verificarlas con billeteras reales.
- Evaluar soluciones específicas para la contención en DeFi y para los servicios que exigen confirmaciones.
- Tener una implementación completa y probada en chipnet con tiempo suficiente, con datos reales de huérfanos.
- Lograr un apoyo amplio, que no se limite a la ausencia de objeciones técnicas en el foro.
No es una postura aislada. SW9 no cree necesario forzarlo para el próximo ciclo si la implementación no está lista; Fernando Pelliccioni (Knuth) aprueba el cambio pero es neutral sobre el lock-in; 2qx aprueba «si la implementación está lista a tiempo»; albaDsl condiciona su voto a que Culianu dé por buena la implementación. Postergar un ciclo tiene un costo acotado y recuperable; activar sin cumplir estas condiciones, uno permanente.
Voces del debate
Citas del foro Bitcoin Cash Research que plantean reservas sobre el cambio, con la fecha en que se escribieron.
«Con bloques más rápidos vas a seguir viendo este mensaje de error. Solo va a desaparecer antes. Deberíamos resolver el problema por completo.»
“We should solve the problem completely.”
«Sin sincronización de la mempool, da igual que los bloques sean de un minuto o de diez.»
“Without mempool synchronisation, it doesn’t matter if blocks are a minute or 10 minutes.”
«Agreguen bloques de un minuto y SPV va a morir.»
“Add one minute blocks and SPV will die.”
«Desapruebo, principalmente porque la implementación no está lista, pero también me pregunto si no estamos cediendo demasiado margen de seguridad.»
“…giving up too much of our safety margin with 1-min blocks.”
«Hay que distinguir dos cosas: la velocidad y la percepción de velocidad. El dinero necesita reglas claras, predecibles y estables.»
“…speed and the perception of speed.”
«Para quien lo implementa, es como si hubiera estallado una bomba en el código. Todo se tocó.»
“…it’s like a NUKE went off in the codebase. Everything got touched.”
El ensayo completo
El ensayo desarrolla cada argumento, responde a los contraargumentos y cita sus fuentes en 84 notas, casi todas con enlace al post original.
- Qué busca el CHIP
- El problema es real, pero el cambio no lo elimina
- Los costos
- Principios
- La adopción de comercios
- Lo que se puede hacer sin cambiar el intervalo
- El pedido: no en 2027
- Conclusión
Todavía no, y no en 2027.
Resolver cada problema en la capa donde se genera es más lento y menos vistoso que cambiar una constante, pero ataca las causas y no los síntomas. Quien comparta estas preocupaciones puede decirlo en el foro antes del 15 de noviembre. Postergar la propuesta no la mata: le da el tiempo que necesita para hacerse bien.
Contacto
Si encontrás un error, un dato desactualizado o un argumento que no consideré, escribime.
Fuentes principales
- CHIP-2025-03, texto actual (última edición: 24/10/2026)
- Hilo de discusión del CHIP
- Hilo de declaraciones de apoyo y rechazo
- rnbrady, Kraken y 15 confirmaciones (#150)
- JohnGalt, mempool y NFC (#149)
- rnbrady, resolver el problema (#164)
- Tom Zander, SPV (hilo 2027, #41)
- bitcoincashautist, sincronización por lotes (hilo 2027, #48)
- Calin Culianu, complejidad (#226, #230, #237, #243)
- Calin Culianu, apoyo al CHIP (#243)