Cómo funciona realmente un pool de minería de Bitcoin: del share al pago

La explicación estándar es la siguiente: los mineros combinan su hashrate, encuentran un bloque juntos y reparten la recompensa. Nada en esa frase es falso, pero tampoco se deduce nada útil de ella. No explica por qué cobras en los días en que el pool no encuentra ningún bloque. No explica por qué el panel muestra un hashrate distinto al de tu máquina. No explica de dónde sale una suerte del 78%, ni por qué a veces esa cifra no tiene nada que ver con tu monedero.

Lo que sigue es la cadena completa: qué sale físicamente de tu máquina, cómo se cuenta, en qué se convierte y en qué momento se transforma en una transacción hacia tu dirección. Sin metáforas de boletos de lotería.

POOL BTC no es un pool. Comparamos las condiciones de otros operadores y calculamos cuánto le cuestan a un minero, así que aquí no se vende a ningún operador ni se acusa a ninguno. Solo mecánica, y aritmética que puedes rehacer tú mismo.

Seis cosas que importan

1. Un share y un bloque son el mismo objeto. Solo difiere la altura del listón.
2. El pool te asigna un listón personal y fácil para poder ver tu trabajo cada pocos segundos en lugar de una vez por siglo.
3. El pool construye el bloque, no tú. Tu hardware itera números dentro de un encabezado que llega ya terminado.
4. Un esquema de pago es una regla sobre quién carga con el riesgo de la mala suerte: tú o el operador.
5. La comisión se descuenta de la recompensa bruta, así que en términos absolutos escala con el precio y con tu hashrate.
6. La suerte es una estadística, no un comportamiento del operador. En FPPS nunca afecta tu pago en absoluto.

¿Qué es un share y en qué se diferencia de un bloque válido?

Un share es un encabezado de bloque cuyo hash cayó por debajo de un objetivo fácil que el pool te asignó personalmente. Un bloque es el mismo encabezado cuyo hash cayó por debajo del objetivo de toda la red. Solo difiere la altura del listón: el trabajo, el formato de datos y la validación son idénticos. Cualquier share que llegue a superar el objetivo de la red se convierte automáticamente en un bloque válido.

Un encabezado de bloque de Bitcoin tiene 80 bytes y contiene seis campos: versión, hash del bloque anterior, raíz de Merkle, marca de tiempo, nBits y nonce. nBits es una codificación compacta del objetivo actual de la red, y se expande al número de 256 bits que el doble SHA-256 del encabezado tiene que quedar por debajo.

Tu ASIC toma ese encabezado y cambia lo único que tiene permitido cambiar: el nonce (4 bytes), extranonce2 (el pool fija su longitud al conectarse, y se incorpora a la raíz de Merkle a través de la transacción coinbase) y, si el pool y el firmware admiten version rolling, algunos bits del campo de versión. Cada encabezado candidato se hashea dos veces y se compara contra el objetivo.

El pool comprueba dos objetivos en cada envío. El share entrante se compara contra tu objetivo personal (si lo supera, se cuenta en tu contabilidad) y contra el objetivo de la red (si también lo supera, el pool publica un bloque de inmediato). No existe un acto separado de "buscar un bloque". Un bloque es un subproducto del flujo normal de shares.

Una consecuencia no evidente: un pool no puede ocultar un bloque que encontró sin descartar el share mismo. La transacción coinbase de su plantilla lleva las propias direcciones y la etiqueta del pool, y cualquier bloque construido a partir de esa plantilla aparece en los exploradores bajo la misma marca. El procedimiento práctico para comprobarlo está en nuestro artículo sobre verificar que un pool paga con justicia.

Según el cálculo de POOL BTC, con una dificultad de red de 127,450,789,715,843 y una dificultad de share de 65,536, un bloque requiere en promedio unos 1.94 mil millones de shares. No es una estimación de orden de magnitud, sino una división directa: dificultad de red entre dificultad de share, porque ambas se expresan en la misma unidad de trabajo esperado.

¿Qué es la dificultad de share, y por qué el pool la ajusta a la máquina (vardiff)?

La dificultad de share es un multiplicador que indica cuánto más fácil es tu objetivo asignado que el objetivo base de Bitcoin. A dificultad 1, un share requiere en promedio 2^32 hashes, unos 4.295 mil millones. A dificultad 65,536 requiere 65,536 veces eso. El pool mueve este número para que tu flujo de envíos siga siendo cómodo de contabilizar.

El mecanismo de ajuste se llama vardiff, por dificultad variable. El pool observa con qué frecuencia envías y sube o baja tu dificultad, buscando un intervalo cómodo entre shares. Si se fija demasiado baja, una granja grande inunda el servidor de tráfico. Si se fija demasiado alta, las estadísticas de una máquina pequeña se vuelven ruidosas: si un share sale una vez cada dos minutos, el gráfico de hashrate por hora oscilará decenas de puntos porcentuales solo por azar.

Según el cálculo de POOL BTC, una máquina de 100 TH/s a dificultad de share 65,536 envía unos 21.3 shares por minuto, aproximadamente uno cada 2.8 segundos. La aritmética: 100 TH/s son 10^14 hashes por segundo, divididos entre 65,536 × 2^32 = 2.815 × 10^14 hashes esperados por share, lo que da 0.355 shares por segundo.

La misma máquina a distintas dificultades de share:

Y a una dificultad fija de 65,536, en distintos hashrates:

Lo que conviene retener: la dificultad de share no afecta tus ingresos. Afecta la rapidez con la que la estimación del pool converge hacia tu hashrate real. Duplica la dificultad y enviarás la mitad de shares con el doble de peso cada uno. El producto no cambia.

¿Quién construye la plantilla del bloque, y qué entra en un bloque?

Bajo el Stratum V1 clásico, el pool construye toda la plantilla. Ejecuta su propio nodo de Bitcoin, selecciona transacciones de la mempool, construye una transacción coinbase que paga a sus propias direcciones y calcula el árbol de Merkle. Lo que llega al minero no es una lista de transacciones, sino un conjunto de ramas de Merkle más las dos mitades de la coinbase. El minero no puede, físicamente, seleccionar ni rechazar una transacción.

El mensaje mining.notify que distribuye el trabajo lleva un job id, el hash del bloque anterior, ambas mitades de la transacción coinbase, la lista de ramas de Merkle, la versión, nBits, el tiempo y una bandera clean_jobs. El minero inserta su extranonce2 entre las mitades de la coinbase, recalcula la raíz de Merkle a partir de las ramas y ensambla el encabezado.

Esa bandera clean_jobs explica la mitad de lo que parece extraño en los registros del minero. Cuando aparece un nuevo bloque en la red, el pool envía un trabajo nuevo con clean_jobs en true, y a partir de ese instante todo el trabajo sobre el trabajo anterior deja de tener valor. Los shares enviados después contra el trabajo antiguo vuelven rechazados como stale.

Lo que hay realmente dentro del bloque: la transacción coinbase (el subsidio más la suma de las comisiones de cada transacción incluida, con el subsidio en 3.125 BTC a fecha de 24.09.2026) y un conjunto de transacciones de la mempool, normalmente ordenadas por comisión por byte virtual. La porción de comisiones sobre la recompensa total del bloque es pequeña en este momento. Según mempool.space, el 08.09.2026 era del 0.66% en los últimos 4,320 bloques y del 0.57% en los últimos 144, y a lo largo del mes la cifra se mantuvo entre 0.66% y 0.73%. Otros agregadores que miran ventanas de un solo día reportan entre 0.40% y 0.56%, porque usan un denominador distinto. Aquí no hay una única cifra correcta, solo una cifra con una ventana y una fuente indicadas.

La única parte del protocolo que le quita al pool la construcción de la plantilla es Job Declaration, parte de Stratum V2. Funciona en producción en un puñado de pools, y no debe confundirse con que un pool anuncie que "admite Stratum V2". Las tres cifras de adopción distintas detrás de esos anuncios se desglosan en nuestro artículo sobre Stratum V2 y quién elige las transacciones.

¿Cómo mide el pool la contribución de un minero y la convierte en un pago?

El pool mantiene un registro de los shares aceptados con sus pesos, vinculado a tu worker. En el momento de la liquidación (el final del período diario para la familia PPS, el instante en que se encuentra un bloque para PPLNS) calcula tu parte según su fórmula, resta la comisión, acredita un saldo interno y envía una transacción una vez que ese saldo supera el umbral de pago.

El recorrido completo de un share, del ASIC a las monedas en tu monedero:

1. El pool envía mining.notify con un trabajo y la dificultad actual de tu worker.
2. El ASIC itera el nonce, extranonce2 y los bits de versión hasta que el doble SHA-256 del encabezado cae por debajo de tu objetivo.
3. El ASIC envía mining.submit: job id, extranonce2, time, nonce.
4. El pool comprueba que el trabajo esté vigente, que el share no sea un duplicado y que el hash esté realmente por debajo de tu objetivo. Al mismo tiempo lo compara contra el objetivo de la red.
5. El share aceptado se registra con un peso igual a su dificultad.
6. El pool acredita tu parte: una tarifa fija por share o una porción de la recompensa de un bloque encontrado, según el esquema.
7. La comisión del pool se descuenta de ese crédito, calculada sobre el monto bruto.
8. Lo que queda pasa al saldo interno, que normalmente se muestra como "no pagado" en el panel.
9. Una vez que el saldo supera el umbral, el pool construye una transacción, descuenta la comisión de red según su propia política y la envía a tu dirección.
10. Tras las confirmaciones, el monto por fin es tuyo. Hasta ese momento es un pasivo del operador, no tu dinero.

Los pasos nueve y diez merecen una pausa. Entre "acreditado" y "llegado" se sitúa el umbral de pago, y con poco hashrate ese umbral se convierte en un período de espera.

Según el cálculo de POOL BTC, una máquina de 100 TH/s con un hashrate de red de 930.73 EH/s y un subsidio de 3.125 BTC gana 0.00004835 BTC al día en subsidio bruto (parámetros de red: mempool.space, instantánea del 08.09.2026). Sumando la porción de comisiones del 0.66%, sube a 0.00004867 BTC, y tras una comisión de pool del 2% quedan 0.0000477 BTC al día. Contra el umbral de 0.001 BTC publicado por F2Pool, AntPool y Luxor, el primer pago llega alrededor del día 21 de funcionamiento ininterrumpido. Contra el umbral de Ocean, indicado en fuentes secundarias como 0.01048576 BTC, la espera sería de unos 220 días.

Esto no es una crítica a Ocean, que también paga por Lightning sin umbral. Ilustra que un umbral de pago significa una cosa para una sola máquina y algo completamente distinto para una granja de 10 PH/s. Puedes comparar el umbral con tu propio hashrate y calcular el intervalo entre pagos en la calculadora de POOL BTC.

¿En qué se diferencian mecánicamente PPS, FPPS, PPLNS y SOLO, más allá del marketing?

Un esquema de pago responde exactamente a una pregunta: quién carga con el riesgo de que los bloques lleguen más tarde de lo esperado. Bajo PPS y FPPS, el operador asume ese riesgo y te vende previsibilidad a cambio de una comisión más alta. Bajo PPLNS y TIDES, el riesgo se queda con los mineros y se reparte a lo largo de una ventana de shares. Bajo SOLO es enteramente tuyo, sin ningún tipo de promediado.

La diferencia mecánica aparece en dos lugares. Primero, bajo FPPS la tarifa por share se conoce de antemano, así que el crédito diario tiene que ser plano a hashrate constante, y cualquier escalón en ese gráfico es un cambio de dificultad de red o un problema de tu lado. Segundo, una ventana PPLNS se define en unidades de trabajo y no de tiempo, así que a medida que sube la dificultad de red, la ventana se encoge en horas por sí sola.

La forma en que los operadores realmente redactan sus ventanas varía más de lo que se suele suponer. ViaBTC dice oficialmente "las últimas 5 rondas de dificultad". Ocean documenta su ventana como ocho veces la dificultad del bloque en shares. AntPool y F2Pool hablan de "las últimas N rondas de dificultad" sin publicar N. Braiins solo opera BTC en FPPS desde diciembre de 2023 y no ofrece ningún esquema al estilo PPLNS.

Las fórmulas de cada esquema, junto con lo que ocurre con tus shares cuando dejas un pool, se cubren en nuestro artículo dedicado sobre esquemas de pago. La distribución del riesgo descrita arriba es la parte que importa aquí.

¿De dónde sale la comisión del pool y qué cubre?

La comisión del pool es un porcentaje que el operador retiene de la recompensa bruta antes de la distribución. Paga los nodos de Bitcoin y los servidores stratum en varias regiones, un equipo de guardia, el riesgo de varianza que el operador absorbe bajo los esquemas PPS y la infraestructura de liquidación. Las tarifas en los grandes pools se sitúan entre el 1% y el 4%, y compararlas directamente entre esquemas no funciona.

El detalle que la gente pasa por alto: la comisión se descuenta del crédito bruto, no de la ganancia ni de lo que queda tras la electricidad. Así que el mismo porcentaje significa dinero absoluto distinto a precios y hashrates distintos, y esto también explica por qué los esquemas PPS cobran más. En ese porcentaje va incluido el precio de que el operador garantice tu pago en una mala semana.

Lo que está confirmado sobre pools específicos en esta instantánea:

Según el cálculo de POOL BTC, la brecha entre una comisión del 2% y una del 4% en una máquina de 100 TH/s es de 0.00000097 BTC al día, unos 0.000355 BTC al año. Esa cifra parece trivial hasta que la multiplicas por el número de máquinas: en una granja de 100 ASICs idénticos, esos mismos dos puntos porcentuales suman 0.0355 BTC al año.

Por qué clasificar los pools por un solo porcentaje sigue fallando se desarrolla en nuestro artículo sobre comisiones y una puntuación de pool con cuatro factores: el umbral de pago, la política de comisión de red y el margen de conversión automática pesan más a menudo que la propia diferencia porcentual.

¿Qué son la suerte y la varianza, y por qué un pool puede quedarse corto respecto a lo esperado en una semana?

La suerte es la razón entre el costo esperado en shares y los shares realmente gastados en los bloques encontrados, expresada como porcentaje. Un valor del 78% significa que los bloques le costaron al pool más trabajo del esperado, y 130% que le costaron menos. La varianza es la dispersión estadística de la que sale la suerte. El descubrimiento de bloques es un proceso de Poisson, así que la desviación es inevitable y solo se reduce a medida que crece la muestra.

Una propiedad útil de la distribución de Poisson: la desviación estándar es igual a la raíz cuadrada de la expectativa. Por eso la dispersión relativa cae con la raíz cuadrada del número de bloques, no en proporción al hashrate.

Según el cálculo de POOL BTC, con un hashrate de red de 930.73 EH/s y 1,008 bloques por semana:

La primera fila es la misma máquina de 100 TH/s, minando en solitario: el tiempo esperado hasta un bloque con una dificultad de 127.45 billones es de unos 173 años, y la probabilidad de encontrar uno en una semana cualquiera es de aproximadamente 0.011%.

La última fila corresponde a Foundry USA. Según la tabla de ChainBulletin para el 08.09.2026 (reproducida en el artículo de KuCoin del 10.09.2026), el pool controla alrededor de 244.6 EH/s, cerca del 27% de la red, con AntPool cerca de 156 EH/s y F2Pool cerca de 127 EH/s. El coeficiente de Nakamoto, el número de pools que producen más de la mitad de todos los bloques, se sitúa en 3 según el informe de D-Central para el primer semestre de 2026.

De esa tabla salen dos conclusiones. Un pool de 10 EH/s perfectamente honesto y sin incidentes cerrará aproximadamente una semana de cada tres por debajo del 70% o por encima del 130% de suerte, y ese es un comportamiento normal para una variable aleatoria. Al mismo tiempo, si estás en FPPS, nada de esta fila te aplica, porque se te paga una tarifa por share, encuentre el pool un bloque o no. La suerte en FPPS es una métrica del operador, no la tuya.

Lo inverso también es cierto. Una sola semana de suerte no demuestra nada en ningún sentido. Una muestra significativa para discutir la honestidad de un pool PPLNS empieza en un trimestre.

¿Qué pasa cuando te desconectas: shares stale, tasa de rechazo, failover?

Cuando la conexión se cae, el ASIC sigue hasheando contra el último trabajo que recibió, pero no hay adónde enviar los resultados, así que ese trabajo se pierde. Cuando la conexión vuelve, los shares contra el trabajo desactualizado se rechazan como stale. Tu saldo acumulado no se toca: permanece en la cuenta esperando el umbral de pago. Lo que pierdes es el trabajo actual, más tu posición en la ventana si estás en PPLNS.

Las razones por las que un pool rechaza un share significan cosas distintas y conviene separarlas en tus registros:

1. Stale, o job not found: el share llegó contra un trabajo que ya no está vigente. Suele ser red, latencia o un bloque nuevo en la red.
2. Low difficulty share: el hash no alcanzó tu objetivo actual. A menudo es una desincronización justo después de un cambio de vardiff.
3. Duplicate share: la misma combinación de nonce y extranonce2 enviada dos veces. Es señal de un problema de firmware o un fallo del controlador.
4. Above target: el encabezado falla la validación directamente. Suele ser hardware llevado demasiado lejos en overclock o temperatura.

Cada operador fija su propio criterio de normalidad para los rechazos, y no existe un umbral de la industria. AntPool considera normal menos del 1% y además cita una tasa promedio de stale del 0.5% o menor. ViaBTC dice que dentro del 3% está bien. F2Pool considera razonable una tasa de shares retrasados de aproximadamente el 2%. Braiins y Luxor no publican un umbral numérico.

Según el cálculo de POOL BTC, cada 2 puntos porcentuales de tasa de rechazo cuestan exactamente lo mismo que 2 puntos porcentuales de comisión del pool, porque ambos se descuentan del crédito bruto. Para una máquina de 100 TH/s eso son los mismos 0.000355 BTC al año. Un pool al 2% con una mala ruta hacia su servidor pierde frente a uno al 3% con una ruta estable.

Lo que hace que el failover sea menos opcional de lo que parece. La configuración stratum de un ASIC admite varias direcciones de pool, y el firmware pasa a la siguiente cuando la principal se cae. Llena todas las ranuras disponibles y mantén al menos un respaldo con un operador distinto o, como mínimo, en una región distinta, o ambos fallarán al mismo tiempo. El firmware de fábrica de Antminer tiene tres ranuras (Pool 1, 2 y 3, según el soporte de Bitmain), y Whatsminer tiene las mismas tres.

Un detalle específico de PPLNS: dejar un pool no quema tus shares como penalización. Simplemente van saliendo de la ventana a medida que llega trabajo nuevo. Ocean lo documenta explícitamente: dice que los shares nunca se eliminan del registro y que simplemente dejan de contar una vez que el volumen de trabajo los empuja más allá del límite de la ventana. El efecto práctico es el mismo, pero "el pool se queda con tus shares" es una descripción incorrecta.

¿En qué se diferencia un pool del hosting y de la minería en la nube?

Un pool es coordinación de trabajo: el hardware es tuyo, esté donde esté, y el pool reparte trabajos y paga por los shares aceptados. El hosting es un sitio: el hardware sigue siendo tuyo, pero la energía, la refrigeración y la conectividad pertenecen a otro, y tú sigues eligiendo el pool. La minería en la nube es un contrato: no eres dueño de ningún hardware, solo tienes la promesa de una contraparte de pagarte un flujo.

Hosting más un pool es un arreglo normal, y los dos no compiten entre sí. La minería en la nube queda aparte porque elimina el único eslabón verificable de toda la cadena: la correspondencia entre tu hardware, tus shares y las monedas en la blockchain. Con un pool y con el hosting ese eslabón se mantiene, y puedes recalcularlo tú mismo.

Cómo leer las condiciones de un pool al elegir, y qué mirar además del porcentaje, se cubre en nuestra comparación de 12 pools.

Preguntas frecuentes sobre la mecánica de los pools de minería

¿Puede un pool robar un bloque que encontró y no decir nada?

Un bloque construido a partir de la plantilla de un pool lleva una transacción coinbase con las direcciones y la etiqueta de ese pool, y aparece en cualquier explorador. Ocultarlo no es posible. Lo que de verdad no se puede comprobar desde fuera es la contabilidad interna: la porción de un minero concreto en una ventana PPLNS y el hashrate real del pool siguen siendo su propio reporte.

¿La dificultad de share afecta mis ingresos?

No. La dificultad de share solo cambia la frecuencia y el peso de los envíos, y el producto se mantiene igual. Duplica la dificultad y enviarás la mitad de shares, cada uno con el doble de valor. Sí afecta la precisión estadística: una dificultad demasiado alta vuelve ruidoso el gráfico de hashrate de una máquina pequeña.

¿Por qué el panel del pool muestra menos hashrate que mi ASIC?

Tu máquina reporta la velocidad de hash instantánea, mientras que el pool estima tu hashrate a posteriori, a partir de los shares aceptados en una ventana de promediado. Por construcción, no pueden coincidir. Los shares rechazados y stale amplían aún más la brecha, igual que la latencia hacia el servidor stratum. Compara una cifra diaria con otra cifra diaria.

¿Qué pasa con mis shares si me voy antes de que el pool encuentre un bloque?

En PPS y FPPS, nada: se te acreditó una tarifa por cada share aceptado y ya está en tu saldo. En PPLNS tus shares se quedan en la ventana y participan en los bloques encontrados después de que te vas, hasta que trabajo nuevo los empuja más allá del límite. El saldo acumulado no se quema, espera al umbral.

¿Por qué el pool necesita mi hashrate si paga por shares?

No conoce tu hashrate directamente. El pool lo deriva del flujo de shares: shares aceptados multiplicados por su dificultad, dividido entre la longitud de la ventana. Es una estimación y no una medición, y precisamente por eso un gráfico de cinco minutos salta mientras que uno diario se ve suave.

Qué queda sin confirmar en nuestros datos a fecha de 24.09.2026

1. Los porcentajes de comisión en Luxor y Foundry USA. Ninguno publica una sola cifra: Luxor llama a su comisión un descuento sobre el FPPS spot, Foundry fija precios por nivel de hashrate.
2. El umbral de pago de EMCD: los artículos del centro de ayuda que deberían indicarlo devolvieron 404 el 24.09.2026.
3. El 3% de Kryptex viene de nuestra comprobación manual del 29.08.2026; el 24.09.2026 el porcentaje no aparecía en el texto de sus páginas públicas de comisiones.
4. Los parámetros de red en los cálculos anteriores son una instantánea del 08.09.2026 (hashrate 930.73 EH/s, dificultad 127,450,789,715,843, mempool.space). El 24.09.2026 la misma API mostraba 917.89 EH/s y una dificultad de 132,757,073,449,487, así que una máquina de 100 TH/s gana ahora alrededor de un 4% menos de subsidio al día que en los ejemplos anteriores. El próximo reajuste en el bloque 969,696 se estimaba en aproximadamente menos 5.5%.
5. Los valores de dificultad de share en las tablas anteriores son potencias de dos redondas, elegidas para que la aritmética sea legible. F2Pool, AntPool y Braiins no publican una dificultad de share predeterminada ni mínima. ViaBTC publica el mecanismo en lugar de una cifra: un parámetro d= en la contraseña del worker fija la dificultad inicial y md= fija el piso.

En resumen

Un share es un bloque con el listón bajado, y nada más. El pool elige la altura de ese listón para adaptarlo a tu máquina, de modo que pueda ver tu trabajo en tiempo real, y ese ajuste no toca tus ingresos.

El pool construye el bloque, no tú. Bajo Stratum V1 el minero recibe ramas de Merkle y un fragmento de coinbase, nunca una lista de transacciones. Eso solo cambia bajo Job Declaration, y solo un puñado de pools lo ejecuta en producción.

Un esquema de pago responde a una pregunta: de quién es el riesgo. PPS y FPPS te venden previsibilidad a través del porcentaje, PPLNS deja la dispersión con los mineros, SOLO no promedia nada. La suerte es una métrica del pool, y en FPPS nunca llega a tu pago.

La tasa de rechazo cuesta exactamente lo mismo que la comisión, porque ambas se descuentan del crédito bruto. Dos puntos porcentuales perdidos por conectividad se comen lo mismo que dos puntos porcentuales de tarifa, y por eso un pool bien conectado con una tarifa más alta a menudo gana a uno barato pero lejano.

Este artículo contiene enlaces de referido a pools de minería (marcados como patrocinados). Es posible que recibamos una recompensa si se registra a través de ellos. Esto no cambia las cifras ni el orden de las filas en las tablas: las condiciones se toman de las páginas oficiales de los pools.