Una Mining Share es un resultado de cálculo que cumple el requisito del pool para una tarea concreta. El pool estima el trabajo aportado mediante estas muestras verificables. El requisito suele ser más fácil que el de un bloque Bitcoin válido, por lo que la mayoría de las shares no son bloques nuevos.
La máquina de Petr realiza muchísimos intentos. El pool no necesita un mensaje por cada uno: recibe resultados seleccionados que cumplen una condición preestablecida. Puede verificarlos y estimar estadísticamente el trabajo por su frecuencia y dificultad. Una Mining Share no es parte de un bloque sin terminar ni una participación transferible en bitcoin. Tampoco es una transacción registrada en la blockchain, el historial público de transacciones de Bitcoin organizado en bloques enlazados. Es una forma de demostrar al pool la aportación de trabajo computacional del minero. [1]
La minería busca un hash, un resultado de cálculo interpretado como número, que no supere un objetivo determinado. El pool suele fijar un objetivo numéricamente mayor que la red: pasan más resultados y, por tanto, es más fácil. Lo que basta para el pool normalmente no basta para un bloque. Por azar, algunos resultados también cumplen el objetivo más estricto de la red. Pueden dar lugar a un bloque nuevo si este respeta las demás reglas. El pool no relaja las normas de Bitcoin: establece su propio umbral para demostrar trabajo de forma continua. [1]
Petr no construye estos mensajes a mano; lo hace el software. Stratum V2 es un protocolo, un conjunto de reglas de comunicación entre equipos y pool. Su mensaje SubmitSharesStandard incluye job_id para identificar la tarea, nonce como valor modificado durante la búsqueda, ntime para la marca de tiempo de la cabecera del bloque y version para la versión de la cabecera, la parte compacta de datos del bloque. También identifica el canal de comunicación. El pool necesita este contexto para verificar el cálculo: un nonce sin la tarea correcta no demuestra trabajo por sí solo. [2]
Imagina a Petr comparando máquinas con tareas de distintas dificultades. La dificultad sirve aquí como peso: un resultado que cumple un requisito más estricto cuenta como una mayor cantidad de trabajo. Si ambos se convierten a la misma escala, dos envíos aceptados con dificultad 1024 tienen el mismo peso total que uno con dificultad 2048. El número de mensajes cambia, pero el peso contabilizado del trabajo es igual. Ni siquiera esa suma registra exactamente todos los cálculos realizados: los éxitos individuales son aleatorios. Conviene saber si el contador llamado shares muestra resultados aceptados o su peso tras convertirlos a una escala común. [3]
A veces el pool confirma varios envíos juntos. Stratum V2 utiliza la respuesta SubmitShares.Success. El campo new_submits_accepted_count cuenta los envíos recién confirmados, mientras new_shares_sum suma las dificultades de sus tareas. El primero cuenta resultados y el segundo su peso. Ambos corresponden al lote que se confirma, no necesariamente a totales de toda la vida del minero. Por tanto, al leer el protocolo no hay que esperar una confirmación independiente por cada resultado enviado. [2]
La máquina de Petr puede informar de un envío mientras el pool sigue verificándolo. Stratum V2 usa SubmitShares.Error para un envío incorrecto; sequence_number identifica el envío al que corresponde el error. Si no se puede verificar de inmediato, la respuesta de error puede llegar después. Hay que distinguir los resultados enviados de los aceptados y confirmados, además de vigilar los rechazos. El aumento del contador local de envíos no demuestra que el pool lo haya contabilizado todo. [2]
El trabajo confirmado entra en las reglas de remuneración del pool. Por ejemplo, FPPS, Full Pay Per Share, en Braiins calcula la recompensa con el trabajo enviado y datos de la red, como dificultad y recompensas por bloque; incluye una parte de las comisiones de transacción. El pool descuenta su comisión y los envíos de dinero siguen la configuración de pagos. Confirmar una share no envía por sí mismo BTC (bitcoines) a la cartera. Petr sigue por separado trabajo aceptado, recompensa calculada y pago efectivo. [4]
Un contador de shares puede parecer el progreso de una descarga, pero la minería no funciona así. Shares y bloques surgen al buscar hashes suficientemente bajos, con resultados aleatorios. Más trabajo demostrado mejora la base estadística para estimar la potencia, pero no garantiza otro éxito. Una larga serie de shares aceptadas no asegura un bloque en el siguiente intento. El contador informa a Petr del trabajo y su aceptación, no de que quede solo la última pieza del bloque. [3]
Para obtener la imagen más completa, lee esta entrada junto con Mining Pool, Share Difficulty, Proof of Work, Mining Target, Bitcoin. También enlazan con esta entrada ASIC Miner, Mining Pool, Braiins Pool, Stratum V1.