48 / 736POOL

Mining Pool

Pool de minería

Un Mining Pool permite colaborar a los mineros y recibir recompensas menores y continuas sin esperar a encontrar un bloque propio. Conviene entender qué paga el pool, quién guarda los fondos pendientes y quién elige las transacciones.

Un Mining Pool coordina el trabajo de varios mineros y reparte ingresos según reglas acordadas. Un minero no necesita esperar a que su propia máquina encuentre un bloque para empezar a obtener ingresos. El pool no reduce la dificultad de Bitcoin ni garantiza beneficios: cambia principalmente cómo se mide el trabajo y se paga la recompensa.

Mining: modelo de resultado operativoCompara una participación esperada del subsidio de bloque con la electricidad según el hashrate, consumo y comisión de pool elegidos.

Anna tiene una máquina. Paga electricidad todos los días, pero minando sola podría esperar mucho tiempo para encontrar un bloque. Si encuentra uno aceptado por la red, recibe su recompensa; hasta entonces no cobra por esa minería. Haber esperado mucho no significa estar cerca de ganar. Con las mismas condiciones, cada intento nuevo tiene la misma probabilidad. En un pool, su máquina trabaja junto a otras. El pool puede remunerar a quien no encontró un bloque concreto porque mide las contribuciones y aplica un modelo de pagos acordado. Anna renuncia a quedarse con todo el ingreso de su bloque a cambio de cantidades menores y, por lo general, más regulares. Esto no reduce la dificultad de la red ni crea recompensas adicionales. El pool suele cobrar una comisión. Que los ingresos cubran electricidad y equipo es otra cuestión. [6] [7]

El pool no ve cada cálculo de la máquina de Anna. Sin embargo, necesita comprobar que trabaja y estimar su aportación. Por eso establece una condición más fácil que la red Bitcoin. El resultado que la cumple se llama Mining Share, o share. La máquina puede enviar resultados verificables con frecuencia aunque no encuentre un bloque. Con las shares aceptadas y su dificultad, el pool estima estadísticamente el trabajo; no cuenta exactamente todos los intentos. Si dos equipos tienen distintas dificultades de share, no se pueden comparar directamente sus cantidades de resultados. Una share normal no crea un bloque ni una confirmación de pago. Solo un resultado poco frecuente que cumpla además la condición de la red permite presentar un bloque, que debe superar las otras verificaciones. Una share acredita trabajo ante el pool; no es un trocito de bitcoin recién fabricado. [7] [9]

Anna puede conectar la misma máquina a distintos pools y observar recompensas diferentes. Una razón es el modelo de cálculo. PPS, Pay Per Share, abona un valor esperado predeterminado por cada share aceptada según su dificultad. Anna no tiene que esperar a que su pool tenga la suerte de encontrar un bloque: el operador asume el riesgo de variación aleatoria de los hallazgos. Eso no garantiza que siempre pueda pagar ni equivale a un salario fijo por hora. La cantidad de shares y las condiciones de minería siguen cambiando. FPPS, Full Pay Per Share, suele añadir una estimación de las comisiones de transacción a la parte esperada de los bitcoins recién emitidos. PPLNS, Pay Per Last N Shares, reparte en cambio los ingresos de bloques realmente encontrados según el trabajo de una ventana reciente definida. La recompensa depende más de la suerte del pool. Sus reglas definen la ventana: no tiene por qué ser simplemente la última hora. Las siglas no bastan para comparar. También importan las comisiones, el método de estimación, la ventana y el tratamiento de bloques que quedan fuera del historial principal, los Stale Block. El modelo determina el derecho a recompensa y su cálculo; el momento de transferirla a la cartera obedece a otra regla. [7] [8]

Anna ve crecer el saldo de su cuenta. Hasta recibirlo en su cartera, depende de que el pool lo contabilice y pague correctamente. Debe conocer la fecha de pago, el posible mínimo exigido, las comisiones y la dirección de destino. Cada servicio tiene sus reglas: abonar recompensas automáticamente no significa transferirlas de inmediato. También hay que seguir el funcionamiento: shares aceptadas y rechazadas, su dificultad llamada Share Difficulty, disponibilidad de servidores y conexiones de respaldo. El firmware es el software que controla el minero y debe ser compatible con el pool. Comparar los registros del pool de un periodo largo con los propios registros operativos y los pagos reales ayuda a detectar diferencias. Los bloques encontrados se pueden comprobar en la cadena, pero esta no muestra toda la contabilidad interna del pool. Poder cambiar de pool y saber quién elige las transacciones también importa. [8] [9]

Si la tarea cambia antes de que llegue el resultado, el pool puede dejar de contabilizarlo. Latencia significa aquí el retraso de comunicación entre equipo y pool. Una share puede rechazarse por estar desactualizada (stale), duplicada, mal formada o no corresponder a la tarea asignada. Una mayor latencia entre minero y pool, las actualizaciones lentas de tareas y las interrupciones de red aumentan el trabajo perdido. La proporción de stale shares indica la eficiencia operativa de la conexión del minero con el pool; no es lo mismo que un Stale Block en la cadena. [9]

La recompensa del bloque se registra en una primera transacción especial llamada Coinbase Transaction. Sus salidas indican los importes y las condiciones para gastarlos más adelante. Por tanto, la recompensa puede dirigirse a uno o varios destinatarios. Block Template es la propuesta de bloque con las transacciones elegidas. En un pool convencional, su operador suele construir el Block Template y determinar el destinatario de la salida coinbase. El minero prueba sobre todo distintos valores dentro de la tarea asignada, buscando un resultado que cumpla la condición de la red. Esto da al pool influencia sobre la selección de transacciones, no capacidad para imponer un bloque inválido: cada Full Node verifica el bloque de forma independiente. Full Node es un programa que comprueba los bloques y las transacciones según las reglas de Bitcoin. [6] [10]

Además del importe cobrado, importa quién decide qué pagos entran en los bloques. Excluir ciertas transacciones puede retrasar su confirmación. La concentración de pools importa porque un pequeño número de coordinadores puede influir en la inclusión de transacciones, la adopción de software y la distribución de Hashrate a corto plazo: el número de cálculos de minería por segundo. El Hashrate de un pool no equivale a la propiedad de los equipos: los operadores de máquinas especializadas de minería, llamadas ASIC, pueden conectarlas a otro pool. El riesgo aumenta cuando el coste de cambiar de pool, los contratos o el firmware limitan esa posibilidad. [6] [10]

Stratum establece cómo se comunican minero y pool. El cifrado protege los mensajes y la autenticación ayuda a verificar a la otra parte. Stratum V1 asigna trabajo de minería y el pool suele conservar el control de la plantilla. Stratum V2 separa mejor las funciones y admite comunicación cifrada y autenticada. El Job Declaration Protocol opcional permite a los mineros presentar su propia plantilla con su selección de transacciones cuando tanto el minero como el pool admiten los componentes necesarios. El Mining Protocol de Stratum V2 puede funcionar sin esta opción; la etiqueta Stratum V2 por sí sola no garantiza una selección independiente de transacciones. [10]

Para quien quiera conocer el mecanismo: Block Template es una propuesta del contenido del bloque. Worker identifica un equipo conectado o la cuenta bajo la que se registra su trabajo; la cabecera resume los datos básicos del bloque. Una tarea de minería parte de un Block Template o de una construcción equivalente de un bloque candidato. BIP22 describe getblocktemplate y BIP23 sus extensiones para minería en pool. El protocolo del pool transmite a los workers los campos necesarios, los datos de la transacción coinbase y el espacio de búsqueda. Un ASIC Miner prueba distintas cabeceras y calcula su hash, una huella numérica. Para cumplir Proof of Work, la prueba del trabajo de cálculo, ese hash debe ser menor o igual que el umbral de la red, llamado target. El bloque también debe cumplir las demás reglas de Bitcoin. [1] [2] [5]

Detalle técnico: target es un umbral numérico que el hash, el resultado del cálculo, no debe superar; la igualdad también sirve. VarDiff significa dificultad variable de las shares. El pool fija un target de shares más fácil para recibir resultados con suficiente frecuencia para medirlos. El target de la red Bitcoin es mucho más exigente. Una share aceptada que solo cumple el target del pool se contabiliza según sus reglas de recompensa; si el mismo hash también cumple el target de la red, se puede presentar un bloque candidato. VarDiff modifica la dificultad de las shares y, con ello, su frecuencia, no la Difficulty de consenso de Bitcoin. [9]

Para obtener la imagen más completa, lee esta entrada junto con Minería, Hashrate, Braiins Pool, Stratum V2, Mining Share, Pay Per Share. También enlazan con esta entrada Transacción coinbase, ASIC Miner, Hashrate, Nonce.

DOC · 001BIP 22 — getblocktemplateEspecificación DOC · 002BIP 23 — getblocktemplate pooled miningEspecificación DOC · 003Stratum V2 specificationEspecificación DOC · 004Stratum V2 website and protocol overviewDocumentación DOC · 005Bitcoin Core mining RPC — getblocktemplateDocumentación DOC · 006Bitcoin Developer Guide — MiningDocumentación DOC · 007Meni Rosenfeld — Analysis of Bitcoin Pooled Mining Reward SystemsEdición legal gratuita DOC · 008Braiins Academy — Rewards and PayoutsDocumentación DOC · 009Stratum V2 — Mining ProtocolEspecificación DOC · 010Stratum V2 — Protocol OverviewEspecificación
Revisado: Fuentes primero · No es asesoramiento financiero