Pool de respaldo y failover: para qué sirven el segundo y tercer slot del ASIC

Casi cualquier firmware de ASIC trae tres campos para la dirección del pool. Normalmente solo se llena uno. El segundo y el tercero quedan vacíos o duplican la misma dirección, lo que los hace inútiles. Es el seguro más barato de la minería: configurarlo lleva cinco minutos, no cuesta nada, y salva de un tiempo de inactividad cuando el pool principal cae.

A continuación explicamos el mecanismo de conmutación, calculamos el costo del tiempo de inactividad con nuestra fórmula y, por separado, tratamos un punto que casi nadie explica: qué le pasa a tu contribución en PPLNS cuando el minero pasa al respaldo.

Qué son los tres slots de pool en el ASIC

Los tres slots son una lista de prioridad. El minero mantiene la conexión stratum con la primera dirección. Si la conexión se cae o el pool deja de entregar tareas, el firmware prueba la segunda dirección, luego la tercera. No hay nada más inteligente que eso: es un recorrido secuencial de arriba hacia abajo, sin balanceo y sin repartir el hashrate entre pools.

Algo clave sobre la conmutación: no es instantánea. El minero primero debe determinar que realmente no hay conexión. Espera a que expire un timeout, a veces intenta reconectarse varias veces a la primera dirección, y recién después pasa a la siguiente. La duración de esa ventana depende del firmware y de la versión, no hay un estándar único. Consulta el valor concreto en la interfaz web de tu equipo, en la sección de configuración del pool, o en los logs: ahí se ve cuántos segundos después del corte el minero empezó a golpear la segunda dirección.

De esto se saca una conclusión práctica. El failover no protege contra caídas cortas de un par de segundos. Protege contra situaciones que duran minutos y horas: el pool cayó, tiene problemas de DNS, tu proveedor perdió la ruta hacia un data center concreto. Cómo distinguir un problema del lado del pool de uno del lado propio se explica en detalle en el artículo el pool está caído: diagnóstico paso a paso.

Segundo punto: la mayoría de los firmwares vuelve automáticamente al primer pool cuando este se recupera. Es decir, el respaldo funciona como una plataforma temporal, no como una mudanza. Pero hay que verificar ese comportamiento en tu propio modelo, porque también depende del firmware.

Cuánto cuesta una hora de inactividad

Partimos de la fórmula básica de producción esperada. Ingreso por período con un hashrate dado:

```

BTC = H * 86400 * R / (D * 2^32)

```

donde H es el hashrate en hashes por segundo, 86400 son los segundos del día, R es la recompensa por bloque en BTC, D es la dificultad de la red. La fórmula da una esperanza matemática, no una garantía: a volúmenes pequeños la producción real oscila alrededor de este número.

Sustituimos con la red al 08.09.2026: dificultad de 127,45 billones, recompensa de 3,125 BTC, hashrate de red de 930,73 EH/s, participación de comisiones en el bloque de 0,66 por ciento. Con estos parámetros, 100 TH/s producen 0,00004932 BTC al día. Al tipo de cambio de 78.349 dólares, son 3,86 dólares al día, es decir, 16,1 centavos por hora.

Después, aritmética simple según la escala:

En un S21 doméstico, la diferencia entre 1% y 5% de inactividad al mes se mide en un par de dólares, y a esa escala el failover es más una cuestión de higiene que de dinero. En diez petahashes, esos mismos porcentajes se convierten en cientos de dólares al mes, y configurar el segundo slot se paga solo con la primera avería. Puedes probar tus propias cifras en la calculadora de rentabilidad, poniendo tu hashrate y el precio de la electricidad.

También hay que recordar que la inactividad no es gratis en gastos: el equipo que está caído en el pool sigue consumiendo energía si el minero gira en vacío tratando de reconectarse.

Qué pasa con la contribución en PPLNS al pasar al respaldo

Respuesta directa: en PPLNS, los shares que ya enviaste no se anulan en el momento de la desconexión. Permanecen en la ventana y siguen participando en el reparto de los bloques que el pool encuentre en el corto plazo, y luego se van desplazando gradualmente por los nuevos shares de otros mineros. Un pasaje corto al respaldo cuesta bastante menos de lo que se suele pensar. Uno largo consume la contribución por completo.

Así funciona el mecanismo. PPLNS no paga por el share en sí, sino por la proporción de tus shares dentro de los últimos N shares del pool en el momento en que se encuentra un bloque. Mientras tus shares estén dentro de esa ventana, cada bloque encontrado te trae una parte de la recompensa. En cuanto el flujo de shares de otros desplaza los tuyos fuera de la ventana, dejan de contar. No es una penalización ni una anulación, es un desplazamiento natural de la ventana.

El tamaño de la ventana varía entre pools, y se formula de distintas maneras. Según nuestro análisis de la documentación:

De aquí sale una regla práctica: cuanto más ancha sea la ventana del pool principal, con más tranquilidad se pueden sobrellevar pasajes cortos al respaldo. En Ocean, una ventana de ocho dificultades de red significa que un share en promedio alcanza a participar del reparto varias veces, y una caída de conexión de diez minutos casi no quita nada. Con una ventana corta, la misma caída cuesta más.

Y al revés: un pasaje al respaldo de varias horas significa que, al momento de volver, casi no queda nada de tu contribución en la ventana del pool principal, y la acumulación empieza de nuevo. Por eso las averías largas duelen más en PPLNS que en PPS y FPPS, donde el pago no depende de si el pool encontró un bloque.

Una aclaración importante: la mayoría de los pools grandes de BTC no trabajan por defecto en PPLNS, sino en FPPS o PPS+. Si estás en FPPS, toda esta aritmética de la ventana no te aplica, y pasar al respaldo cuesta exactamente lo que no minaste durante la inactividad, ni más ni menos.

Cómo elegir un pool de respaldo

Respuesta directa: elige un respaldo con el mismo esquema de pago que el pool principal, pero no trates de buscar un pool del mismo tamaño. Que coincida el esquema es importante porque de eso depende cómo se calcula el ingreso durante el tiempo de inactividad, y si tendrás que lidiar con dos modelos de pago distintos en la misma semana. El tamaño del pool no influye en esto.

Por qué el esquema importa más que el tamaño. Si el pool principal está en FPPS y el respaldo en PPLNS, cada conmutación empieza a acumular contribución en una ventana ajena desde cero, y al volver esa contribución queda sin aprovechar del todo. Además es más difícil conciliar los reportes: en FPPS el ingreso es parejo, en PPLNS está ligado a los hallazgos de bloques. Un esquema igual hace comparables a las dos plataformas.

Por qué el tamaño no es crítico. El hashrate del pool afecta la varianza del pago: un pool pequeño encuentra bloques con menos frecuencia, así que el ingreso es más irregular. Pero el respaldo, por definición, funciona en episodios cortos. Durante dos horas de inactividad, la varianza de un pool pequeño no te va a arruinar nada, porque en FPPS no existe en absoluto, y en PPLNS la contribución de un par de horas es modesta de todos modos.

En qué fijarse de verdad al elegir un respaldo:

1. El esquema de pago coincide con el del pool principal.
2. El umbral de pago es alcanzable. Es la trampa principal, se detalla más abajo.
3. La ubicación geográfica de los servidores difiere del pool principal. Un respaldo en el mismo data center que el principal no salva de una avería del data center.
4. El registro no exige un proceso de KYC de una semana de duración, si no el respaldo no se podrá activar rápido.
5. La comisión y los umbrales se conocen de antemano. Se pueden comparar por pool en nuestros análisis de comisiones y pagos mínimos.

Sobre si vale la pena cambiar de pool en general y por qué las mudanzas frecuentes no son gratis, hay un análisis aparte: el costo de cambiar de pool.

Vale la pena poner solo u otro pool en el tercer slot

Respuesta directa: tiene sentido que el tercer slot no sea una copia del segundo, sino un seguro contra otro tipo de falla. El segundo slot cubre la caída de un pool concreto. El tercero debe cubrir la situación en que ambos están inaccesibles, por ejemplo por un problema de ruta hacia una región o un bloqueo del lado del proveedor.

Opciones razonables para el tercer slot:

1. Un pool de otra jurisdicción y con otra infraestructura de red. La opción más práctica para la mayoría.
2. Un pool solo. Tiene sentido si estás dispuesto, por principio, a un ingreso nulo la mayor parte del tiempo a cambio de una oportunidad de lotería de encontrar un bloque. Como modo permanente para un hashrate pequeño, es una apuesta consciente, no un cálculo. Como tercer slot que se activa en horas raras de avería, el solo cuesta aproximadamente lo mismo que esas horas de inactividad de la tabla de arriba.
3. El mismo pool, pero otra dirección de su endpoint stratum en otra región. Esto protege de una falla regional, pero no de una avería del pool entero.

Muchos usan la opción 3 como segundo slot, y no está mal. Pero entonces el tercer slot debe ser obligatoriamente de otro pool, si no toda la lista queda atada a un solo operador.

Errores típicos al configurar el failover

1. La misma dirección en los tres slots. Es lo más frecuente. La lista parece completa, pero no hay protección: cae el pool, caen las tres entradas.
2. Respaldo con un worker no verificado. El login se puso de memoria, con un error de tipeo o apuntando a una subcuenta inexistente. Mientras el pool principal está vivo, el error no se manifiesta. En el momento de la avería, el minero conmuta y recibe un rechazo de autorización.
3. Un umbral de pago al que nunca llegarás. Si el respaldo paga a partir de una suma que tu hashrate va a juntar en años de averías raras, el dinero simplemente se acumula en el saldo. En algunos pools, el resto por debajo del umbral no se pierde y espera el siguiente ciclo, pero en otros hay reglas sobre cuentas inactivas y direcciones de pago no configuradas, hasta el punto de perder derechos sobre lo acumulado según los términos de servicio. Lee los términos del pool concreto antes de ponerlo como respaldo.
4. Failover configurado, pero nunca probado. La categoría más lamentable, porque la persona está convencida de estar protegida.
5. Respaldo con la misma dirección de pago y el mismo correo que el principal, sin verificar el acceso por separado. Si perdiste el acceso a la cuenta justo en el momento de la avería, el slot configurado sirve de poco.
6. Respaldo agregado solo en parte de los equipos. En una granja de treinta ASIC, configurar por plantilla garantiza uniformidad; recorrer uno por uno a mano casi siempre deja huecos.

Cómo verificar que el failover funciona

Respuesta directa: hay que verificarlo cortando la conexión al pool principal de forma forzada, no con teoría. La forma más segura es cambiar temporalmente el orden de los slots o bloquear la dirección del pool principal en el router, ver que el minero pasó a la segunda dirección y empezó a entregar shares aceptados, y luego devolver todo como estaba.

Orden de acciones:

1. Asegúrate de que el worker en el pool de respaldo esté creado y visible en su panel. Lo más simple es apuntar un minero al respaldo durante diez minutos y ver que aparece hashrate en ese worker.
2. Anota el estado actual: direcciones en los tres slots, nombres de workers, hashrate actual en el pool principal.
3. Bloquea el acceso al pool principal. Opciones: una regla en el router por dominio o IP, desactivar un puerto concreto, o reemplazar temporalmente la dirección del primer slot por una que no funcione.
4. Cronometra. Anota en cuántos segundos el minero pasó a la segunda dirección. Ese es tu timeout real de failover, y es el valor que hay que tener en cuenta al estimar las pérdidas.
5. Verifica en el panel del pool de respaldo que los shares del worker están llegando y se reconocen como válidos. La simple existencia de conexión no es suficiente.
6. Quita el bloqueo y observa si el minero vuelve solo al primer slot. Si no, el retorno es manual, y hay que tenerlo en cuenta en el procedimiento.
7. Repite lo mismo para el tercer slot, bloqueando el primer y el segundo pool.
8. Anota los resultados y la fecha de la verificación. Repite después de cada actualización de firmware: el comportamiento del failover cambia de versión en versión.

Es conveniente combinar la verificación con trabajos planificados, cuando parte del hashrate ya está inactivo. El costo de la verificación misma se calcula con la misma tabla: diez minutos a 10 PH/s son unos 2,7 dólares, un gasto único a cambio de la certeza de que la protección funciona.

En resumen

Tres slots en lugar de uno no aumentan el ingreso. Eliminan del gráfico las caídas que, de otro modo, se prolongan hasta que uno mismo nota el problema a mano. Con un hashrate pequeño, la ganancia se mide en unidades de dólares al mes; con uno industrial, en cientos y miles.

Conviene tener presentes tres cosas. La conmutación no es instantánea, sino que sigue el timeout del firmware, y su valor hay que medirlo en el propio equipo. En PPLNS, un pasaje corto al respaldo cuesta menos de lo que parece, porque los shares envejecen en la ventana gradualmente, no se anulan de golpe. Y un failover configurado pero nunca probado no es protección, es solo su imitación.

Para calcular cuánto cuesta la inactividad en tu configuración concreta, usa la calculadora, y para comparar las condiciones de los pools para respaldo, mira la sección de comparación de pools.