Minería solo para flotas en hosting: qué esperar

Esta guía está escrita para dos tipos de lectores: proveedores de hosting y gestores de flotas que operan máquinas ajenas y deben decidir si ofrecer minería solo, y cómo, y operadores de flotas propias que están comparando el solo con un pool proporcional. Quien mina en casa con uno o dos dispositivos encontrará las matemáticas generales en Mining Variance & Poisson Math; aquí el foco son las flotas, la liquidez, las políticas para clientes, el monitoreo y la elección entre Bitcoin y Bitcoin Cash.

La primera mitad trata los números: qué debe esperar una flota en cada cadena y por qué la media engaña. La segunda mitad, a partir de la sección sobre cómo ofrecer solo a los clientes, es operativa: políticas, precios, monitoreo, el día en que llega un bloque y tres perfiles de flota calculados.

Puntos clave

• El ingreso esperado por terahash es casi el mismo en BTC y BCH. En la instantánea de abajo, 1 PH/s valía unos 39,7 USD al día en BTC y 39,5 USD al día en BCH.
• La distribución no. Un bloque BCH requiere unas 269 veces menos trabajo que un bloque BTC y vale unas 269 veces menos, así que la misma flota encuentra bloques BCH unas 269 veces más a menudo.
• El tiempo esperado es una media, no un calendario. Tras un tiempo esperado aún hay alrededor de un 37 % de probabilidad de ningún bloque; tras tres tiempos esperados, alrededor del 5 %.
• Solo frente a FPPS cambia el momento, no la media. La diferencia de ingreso esperado es la diferencia de comisión: 1 % en solo frente a comisiones FPPS que en la mayoría de los grandes pools están entre aproximadamente el 2 % y el 4 %.
• La liquidez decide el tamaño de la porción. Para tener un 95 % de seguridad de al menos un bloque, una flota necesita reservas para unos tres tiempos esperados.
• Los shares aceptados, no los bloques, dicen que la flota funciona. Semanas sin bloque son normales; semanas con shares aceptados en descenso, no.
• Para los proveedores, el problema de los tickets se resuelve antes del cambio. Una declaración escrita y un panel que muestre los bloques esperados junto a los encontrados convierten un riesgo de soporte en un producto.

La instantánea usada en esta guía

Todas las cifras siguientes provienen de esta instantánea. Los datos de red cambian cada día; para valores actuales usa la calculadora en vivo y el informe mensual de probabilidades.

La dificultad es el dato que más importa, y se lee directamente de la cadena. Las cifras de hashrate de red publicadas por los exploradores son estimaciones derivadas de los tiempos de bloque, y distintas fuentes difieren en varios puntos porcentuales; el tiempo esperado de tu propia flota no depende de ellas.

La única fórmula detrás de todo

El tiempo esperado para que una flota encuentre un bloque es:

Tiempo esperado = dificultad × 2³² ÷ tu hashrate

Para las flotas importan dos detalles:

• Usa el hashrate efectivo, no el nominal. Las paradas, los shares stale y la latencia de red reducen el trabajo que realmente llega al pool. Una flota con un 97 % de uptime tiene el 97 % de su probabilidad nominal, y su tiempo esperado es alrededor de un 3 % más largo.
• La dificultad y el hashrate de red son medidas distintas. La dificultad la fija el protocolo a partir de los tiempos de bloque pasados; el hashrate de red es una estimación de cuánto trabajo se está haciendo ahora. Cadenas con el mismo algoritmo pueden tener dificultades muy distintas, que es exactamente el caso de BTC y BCH.

Para profundizar en el modelo de probabilidad, con simulaciones, consulta Mining Variance & Poisson Math.

Mismo ingreso esperado, distribución muy distinta

Así queda 1 PH/s de hashrate efectivo en cada cadena, en la instantánea:

Los dos ingresos esperados están a menos de medio punto porcentual el uno del otro. No es una coincidencia ni una ley: las mismas máquinas SHA-256 pueden minar cualquiera de las dos cadenas, y los operadores tienden a moverse entre ellas hasta que el ingreso por hash se iguala más o menos. Cuando los precios o la dificultad se mueven, la diferencia se reabre durante un tiempo.

Lo que no se iguala es la forma del ingreso. En esta instantánea, un bloque BTC requiere unas 269 veces más trabajo que un bloque BCH y vale unas 269 veces más. Misma media, experiencia opuesta: en BTC una flota mediana espera años un pago muy grande; en BCH la misma flota cobra muchos pequeños.

Qué debe esperar una flota

La tabla muestra el tiempo esperado por bloque, la espera mediana, el plazo en el que llega un bloque en el 95 % de los casos y la probabilidad de al menos un bloque en 30 días y en un año.

Bitcoin (BTC), dificultad 132,76 T

Bitcoin Cash (BCH), dificultad 494,00 G

De aquí salen directamente dos lecturas. En BTC, por debajo de unos 50 PH/s, el solo sigue siendo una apuesta a largo plazo incluso para una flota profesional: a 10 PH/s la probabilidad de no encontrar ningún bloque en un año entero sigue siendo de alrededor del 57 %. En BCH, a partir de aproximadamente 1 PH/s, el solo deja de ser una lotería y se convierte en un ingreso irregular.

Por qué la media engaña

El tiempo de espera de un bloque sigue una distribución exponencial, y eso tiene consecuencias que sorprenden a casi todo el mundo la primera vez.

La mediana es más corta que la media. La mitad de las esperas termina antes de aproximadamente 0,69 veces el tiempo esperado. Unas pocas esperas muy largas elevan la media.

Las rachas secas largas son normales. Esta es la probabilidad de seguir sin bloque tras un múltiplo dado del tiempo esperado:

Una flota de 1 PH/s en BCH tiene un tiempo esperado de 24,6 días. Pasar 50 días sin bloque, el doble del tiempo esperado, ocurre en aproximadamente uno de cada siete casos. No es señal de que algo esté mal.

La minería no tiene memoria. Cada hash es un intento independiente. Tras tres meses sin bloque, la probabilidad de encontrar uno mañana es exactamente la misma que el primer día. A nadie se le debe nunca un bloque, y una racha afortunada no consume suerte futura.

Cuántos bloques al mes: flotas en BCH

Para flotas lo bastante grandes como para encontrar varios bloques BCH al mes, la pregunta útil pasa a ser cuánto se mueve el recuento mensual. El número de bloques en un periodo sigue una distribución de Poisson, cuya dispersión relativa se reduce a medida que crece el número esperado.

A 1 PH/s, unos tres meses de cada diez terminan sin ningún bloque. A 10 PH/s, un mes con solo siete bloques y un mes con dieciocho son ambos normales. A 100 PH/s el resultado mensual se mantiene a menos de un 15 % de la media aproximadamente nueve meses de cada diez.

La liquidez: el verdadero límite del solo

El hosting y la electricidad se facturan cada mes en moneda fiduciaria. Los ingresos del solo llegan a golpes. La brecha entre ambos es el riesgo práctico del solo para una flota, y se puede dimensionar.

Regla práctica derivada de la distribución exponencial: para tener un 95 % de seguridad de al menos un bloque, una flota debe poder operar durante unos tres tiempos esperados sin ingresos de la porción solo. Para el 99 %, unos 4,6 tiempos esperados.

Dos ejemplos en la instantánea:

• 1 PH/s en BCH: tiempo esperado de 24,6 días, así que unos 2,4 meses de reserva para un 95 % de seguridad. Viable para la mayoría de los operadores.
• 10 PH/s en BTC: tiempo esperado de 21,7 meses, así que unos 5,4 años de reserva para un 95 % de seguridad. No es viable como plan de ingresos; solo como asignación deliberada a largo plazo.

Un ejemplo con supuestos declarados: una flota de 15 J/TH consume unos 15 kW por PH/s, es decir, 360 kWh al día. A 0,07 USD por kWh son unos 25 USD al día, aproximadamente 770 USD al mes, por PH/s. Frente a los aproximadamente 39,5 USD diarios de ingreso esperado en la instantánea, el margen medio es positivo, pero en BCH a 1 PH/s unos tres meses de cada diez no traen bloque, y en BTC casi todos. Sustituye la eficiencia y la tarifa por las tuyas; la estructura del razonamiento es la misma.

Solo frente a FPPS: qué compra la comisión

En valor esperado, el solo y un pool Full Pay Per Share pagan casi lo mismo, porque ambos pagan el subsidio del bloque más las comisiones de transacción en proporción a tu trabajo. Las diferencias son:

• La comisión. La mayoría de las comisiones FPPS publicadas por los grandes pools está entre aproximadamente el 2 % y el 4 %, con al menos un pool vinculado a un exchange que anuncia menos (fuente: comparativa de pools de Simple Mining, actualizada el 23 sep 2026). Frente a una comisión FPPS del 2-4 %, una comisión solo del 1 % conserva entre 1 y 3 puntos porcentuales más del ingreso esperado.
• Qué paga la comisión más alta. Un pool FPPS asume la varianza por ti y paga cada día, haya bloque o no. Es un seguro, y para muchos operadores vale lo que cuesta.
• Las comisiones de transacción. FPPS paga una estimación de las comisiones medias; el solo cobra las comisiones reales de los bloques que encuentras. Con muchos bloques ambos convergen; bloque a bloque difieren.

El solo tiene sentido económico cuando una flota puede absorber la varianza al tamaño que elige, y cuando los puntos porcentuales adicionales, o la preferencia por cobrar directamente de la blockchain, importan al operador.

La estrategia de la porción

Una forma práctica de usar el solo no es mover una flota entera, sino apartar una porción, dimensionada para que por sí sola alcance un ritmo predecible, y mantener el resto en un pool proporcional.

Un ejemplo calculado. Una flota de 10 PH/s pone 1 PH/s en solo en BCH y 9 PH/s en FPPS. La porción tiene un tiempo esperado de unos 25 días y encuentra de media unos 15 bloques al año. Alrededor del 90 % de los ingresos de la flota sigue siendo diario y predecible; la porción añade ingresos irregulares en BCH con un rendimiento esperado algo mejor.

Cómo dimensionar la porción. Parte de la regla de la reserva: elige la porción más grande cuyos tres tiempos esperados puedas financiar cómodamente sin ingresos del solo, y en la que un mal trimestre no cambie tus decisiones.

Déjala tranquila. Aumentar la porción tras una semana afortunada, o retirarla tras un mes seco, no cambia las probabilidades, porque la minería no tiene memoria. Solo cambia cuánto tiempo pasa la porción minando. Decide una vez, pon la decisión por escrito y revísala en fechas fijas, no después de cada resultado.

La dificultad se mueve: BTC y BCH se comportan distinto

• Bitcoin recalcula la dificultad cada 2.016 bloques, aproximadamente cada dos semanas, y la mantiene fija entre medias. Entre dos ajustes, tu tiempo esperado es estable.
• Bitcoin Cash usa ASERT (aserti3-2d), que recalcula la dificultad en cada bloque con una vida media de dos días (especificación; nuestra explicación: ASERT explained). Cuando llega o se va hashrate, la dificultad de BCH lo sigue en pocos días.

Para las grandes flotas en BCH hay una consecuencia que conviene planificar: tu propio hashrate forma parte de la red. En la instantánea, 100 PH/s serían alrededor del 3 % del hashrate de red estimado de BCH, así que moverlos a BCH elevaría la dificultad aproximadamente en la misma proporción en pocos días, alargando en consecuencia tu propio tiempo esperado. En BTC, los mismos 100 PH/s son alrededor del 0,01 % de la red y no tienen efecto visible.

Cinco malas interpretaciones que hacen pensar en una avería

1. Semanas sin bloque, así que alguna máquina está averiada. Revisa primero los shares aceptados. Si los shares que envía la flota corresponden a su hashrate, la flota funciona, y la racha seca es estadística.
2. Hemos esperado tanto que nos toca un bloque. La minería no tiene memoria. La probabilidad de un bloque mañana no depende de cuánto hayas esperado.
3. Nuestro best share fue enorme, así que estuvimos cerca. El best share es el share de mayor dificultad que tu minero ha producido jamás: mide lo raro que era ese hash. No significa que estuviste cerca de un bloque ni predice el siguiente. Más en Best Share Explained.
4. Un pool solo con más hashrate da mejores probabilidades. En solo, el hashrate de otros mineros no te ayuda: tus probabilidades dependen solo de tu propio hashrate efectivo y de la dificultad. En un pool solo importan el uptime, la latencia y las plantillas de bloque correctas.
5. Un mes decide si la estrategia funciona. A 1 PH/s en BCH, un solo mes puede ir de cero a tres bloques sin que ocurra nada anómalo. Juzga una porción solo en periodos de varios tiempos esperados, nunca en uno.

Cómo verificar que la flota funciona sin esperar bloques

• Shares aceptados frente a shares esperados. El trabajo aceptado debe seguir el hashrate de la flota a lo largo de horas y días. Una brecha constante es un problema de configuración o de hardware; la ausencia de bloques no.
• Shares rechazados y stale. Unos pocos puntos porcentuales son habituales; un aumento repentino suele apuntar a latencia de red, un puerto equivocado o una máquina inestable. El umbral exacto es una regla práctica que depende del hardware y de la conexión, no una constante del protocolo.
• Uptime por máquina. Es el hashrate efectivo, no el nominal, el que fija las probabilidades. Una máquina parada un día a la semana pierde alrededor del 14 % de su probabilidad.
• Estadísticas del pool mediante API. Las flotas deberían leer hashrate, workers y bloques encontrados de forma programática, no a ojo. Para SoloFury, los endpoints públicos están documentados en solofury.com/api-docs.

Ofrecer solo a los clientes de hosting: la visión del proveedor

Los proveedores de hosting que han estudiado el solo y han dicho que no suelen dar la misma razón: un cliente nuevo en la minería podría elegir solo sin entender la varianza, no ver pagos durante semanas y abrir un ticket convencido de que las máquinas están averiadas. La preocupación es fundada, y también tiene solución, porque todo lo que el cliente malinterpretaría es predecible y puede explicarse antes del cambio en lugar de después.

Para quién es el solo, y para quién no. El solo encaja con clientes que entienden que la recompensa llega a golpes, que pueden financiar la reserva y que o bien son lo bastante grandes en BCH para ver bloques con regularidad, o bien eligen deliberadamente una apuesta a largo plazo en BTC. No encaja con un cliente primerizo cuyo plan depende de un pago diario. La política más limpia es dejar el solo fuera de la lista por defecto y convertirlo en una opción a petición, para clientes que lo pidan o que superen un umbral de tamaño.

La declaración que evita tickets. Antes de apuntar la primera máquina al solo, el cliente confirma por escrito una breve lista de hechos, en lenguaje sencillo:

• el tiempo esperado por bloque para su hashrate en la cadena elegida, y la fecha de la instantánea con la que se calculó;
• que tras un tiempo esperado todavía hay alrededor de un 37 % de probabilidad de ningún bloque, y tras tres alrededor del 5 %;
• que la métrica que demuestra que las máquinas funcionan son los shares aceptados, no los bloques encontrados;
• que ha apartado los costes operativos de al menos tres tiempos esperados;
• cómo se fija la fecha de revisión, y que los resultados recientes no son motivo para cambiar la porción.

El objetivo es dar al cliente un número con el que comparar en lugar de una sensación, antes de la primera racha seca y no durante ella.

Hacer visible la racha seca. Un cliente que ve en un panel los shares aceptados siguiendo su hashrate, el número de bloques esperados hasta ahora y los bloques realmente encontrados, puede responder por sí mismo a la pregunta de si algo va mal. Esa vista es la medida contra los tickets más eficaz que puede añadir un proveedor, y puede construirse a partir de la API pública del pool.

Modelos de precios y dónde encaja el solo

Tarifa fija de hosting por kilovatio hora. El cliente paga la energía y la operación, se queda con toda la recompensa y elige el pool. El solo encaja sin ningún cambio: los ingresos del proveedor no dependen de cuándo llegan los bloques.

Reparto de ingresos. El proveedor se queda con un porcentaje de lo que minan las máquinas. Algunos proveedores lo cobran a nivel de pool, mediante una integración con un pool proporcional que divide los pagos diarios. Con un pool solo ese mecanismo hoy no existe: la coinbase paga al minero y la comisión del pool, y no hay una tercera salida para el proveedor. Un proveedor con reparto de ingresos puede aun así ofrecer solo de dos formas: facturando su parte a partir de los bloques encontrados, que son públicos on-chain y en la API del pool, o fijando una tarifa plana para la porción solo. En ambos casos el acuerdo debe estar en el contrato antes del primer bloque, no discutirse después.

Selección de pool gestionada. Algunos proveedores eligen el pool por el cliente. En ese modelo, el solo puede ofrecerse como opción explícita con su propia declaración, o excluirse; lo que no funciona es pasar a un cliente a solo sin la explicación anterior.

Configuración de la flota para el solo

• Una dirección de pago por cliente, workers nombrados por máquina. En la mayoría de los pools solo el nombre de usuario es la dirección de pago, y un sufijo identifica al worker. Así las estadísticas por cliente salen solas, y un bloque encontrado por cualquier máquina de ese cliente paga a ese cliente.
• Puertos de alta dificultad para máquinas industriales. El tráfico de shares de un rack de mineros de clase S21/S23 es muy superior al de los dispositivos domésticos. Usa los puertos de alta dificultad o Stratum V2 del pool donde existan, y una dificultad inicial fija para la instalación; reduce el tráfico de red sin cambiar las probabilidades.
• Región más cercana. Los shares stale son trabajo que llega demasiado tarde para contar. Apunta las máquinas a la región del pool con menor latencia desde el sitio y mide la tasa de stale tras el cambio.
• Pool de respaldo. La mayoría de los firmwares admite un pool secundario. Configurar como respaldo la cuenta del cliente en un pool proporcional mantiene productivo el hashrate durante una caída del pool solo, y mantiene informado al cliente de que se usó el respaldo.
• Formatos de conexión según el firmware. Los firmwares Stratum V2 difieren en si esperan host y puerto o una URL completa con la clave de autoridad del pool. Revisa la documentación del pool para cada firmware antes de desplegar un rack entero.

Qué monitorear, por cliente

El indicador de suerte que muestran muchos pools compara el trabajo realizado desde el último bloque con el trabajo esperado por bloque. Un valor por debajo del 100 % significa que la espera actual es más larga que la media; describe el pasado, no es una predicción, y las definiciones varían entre pools.

El día en que llega un bloque

1. Confirma on-chain, no solo en el pool. Comprueba la altura del bloque en un explorador independiente y verifica que la coinbase paga a la dirección del cliente.
2. Espera la madurez. Las recompensas de la coinbase se pueden gastar tras 100 confirmaciones, una regla de consenso tanto en BTC como en BCH: unas 17 horas a diez minutos por bloque.
3. Vigila los huérfanos. Rara vez, un bloque encontrado pierde la carrera con otro bloque a la misma altura y no forma parte de la cadena definitiva. Si tras unas pocas confirmaciones la altura ya no está en la cadena principal, la recompensa no se puede gastar; es una propiedad del protocolo, no del pool.
4. Regístralo. Altura, hash, marca de tiempo, dirección, recompensa y salida de la comisión, para la contabilidad del cliente y para cualquier factura por reparto de ingresos.
5. Explica al cliente qué pasa ahora, incluido que el próximo bloque no es ni más ni menos probable que antes. Nuestra guía de los pasos tras una victoria está en You Found a Block, Now What?.

Tres perfiles de flota calculados

Todas las cifras usan la instantánea del principio de esta guía.

Perfil A: un cliente con 2 PH/s que quiere probar el solo. El proveedor recomienda BCH para toda la asignación o, de forma más prudente, una porción de 500 TH/s. A 2 PH/s en BCH el tiempo esperado es de unos 12 días, unos 30 bloques al año, y una ventana de 30 días trae de cero a cinco bloques en nueve casos de cada diez; un mes sin bloque ocurre aproximadamente una vez de cada once. A 500 TH/s el tiempo esperado es de unos 49 días y un mes sin bloque ocurre más de la mitad de las veces: es el número que debe figurar en la declaración.

Perfil B: un operador con 30 PH/s que quiere el solo como segunda fuente de ingresos. El diez por ciento de la flota, 3 PH/s, va a solo en BCH: tiempo esperado de unos 8 días, unos 45 bloques al año, de uno a siete bloques en un mes típico, y una ventana de 90 días sin bloque es prácticamente imposible si las máquinas funcionan. Los otros 27 PH/s siguen en FPPS. Si el proveedor cobra un reparto de ingresos, la porción de 3 PH/s se factura a partir de los bloques registrados on-chain.

Perfil C: un operador con 150 PH/s que estudia una apuesta a largo plazo en BTC. En BTC, los 150 PH/s completos tienen un tiempo esperado de unos 44 días y unos ocho bloques al año, pero la mitad de los meses termina sin bloque y una racha seca de 90 días ocurre aproximadamente una vez de cada ocho. Una porción de 20 PH/s en BTC tiene un tiempo esperado de unos 11 meses: dos posibilidades de cada tres de al menos un bloque en el primer año, y una de cada tres de un año entero sin nada. Es una asignación deliberada para un operador que puede sostenerla, no un plan de ingresos. Los mismos 20 PH/s en BCH encontrarían en cambio un bloque aproximadamente cada 30 horas.

Un registro de riesgos para el solo a escala de flota

¿BTC o BCH para una porción solo?

La liquidez forma parte de la decisión: BTC y BCH cotizan ambos en los principales exchanges centralizados, lo que importa cuando una flota debe convertir recompensas para pagar facturas en moneda fiduciaria.

Antes de apuntar una flota al solo: una lista de verificación

• Pon la política por escrito. Tamaño de la porción, cadena, fecha de revisión y qué no cuenta como motivo para cambiarla.
• Financia la reserva. Al menos tres tiempos esperados de costes operativos para la porción.
• Acuerda la lectura con el proveedor o el cliente. Todos los implicados deben saber que las rachas secas de dos tiempos esperados son normales, antes de que llegue la primera.
• Usa un wallet que controles. Las recompensas del solo van a la dirección de la configuración del minero; las direcciones de depósito de un exchange pueden funcionar pero añaden una contraparte. Las recompensas se pueden gastar tras la madurez de la coinbase prevista por el protocolo, 100 bloques.
• Planifica la contabilidad. Unos ingresos irregulares pueden cambiar cómo y cuándo se registran las monedas minadas en tu jurisdicción. Consúltalo con un asesor cualificado.
• Configura el monitoreo. Shares aceptados, tasas de rechazados y stale y uptime por máquina, leídos mediante API.

Lo que estas matemáticas no recogen

• Los cambios de dificultad. Cada cifra supone que la dificultad de la instantánea se mantiene. En BTC cambia cada dos semanas; en BCH, de forma continua.
• Los precios. Los valores de bloque en USD son una instantánea, no una previsión.
• Las comisiones de transacción. Las monedas por bloque incluyen una media; los bloques reales varían.
• Los bloques huérfanos. Raros, pero un bloque encontrado puede perder ocasionalmente la carrera con otro bloque a la misma altura. Una latencia baja y un nodo bien conectado reducen el riesgo.
• Tu propio efecto sobre la dificultad, relevante en BCH para flotas por encima de unos pocos puntos porcentuales del hashrate de red.

Cómo gestiona SoloFury el hashrate de las flotas

Esta sección trata de nuestro propio servicio; todo lo anterior se aplica a cualquier pool solo.

• Pagos non-custodial: cuando una máquina encuentra un bloque, la recompensa se paga en la coinbase directamente a la dirección del minero. No hay saldo en el pool, ni paso de retiro, ni registro: la dirección del wallet es el nombre de usuario.
• Comisión del 1 %, pagada como salida separada de la coinbase.
• Puertos Stratum V2 de alta dificultad para máquinas de clase S21/S23: 3343 para BTC y 7343 para BCH. Stratum V1 en todas las monedas, con TLS en todos los puertos.
• Dificultad inicial fija para instalaciones: configura la contraseña como d=50000 para reducir el tráfico de shares.
• 9 regiones de servidores, y una API pública de estadísticas por moneda para el monitoreo de flotas.

Los detalles de configuración están en la página de inicio y en la documentación de la API. Las probabilidades actuales para cualquier hashrate están en la calculadora.

Lecturas relacionadas

• Mining Variance & Poisson Math: el modelo de probabilidad completo, con simulaciones.
• Solo Mining vs Pool Mining: comisiones, métodos de pago y comparación de comisiones efectivas.
• Solo Mining Odds: probabilidades por dispositivo y por cadena.
• ASERT explained: cómo reacciona la dificultad de BCH en cada bloque.
• You Found a Block, Now What?: qué ocurre tras una victoria y cómo verificarla on-chain.