Um Mining Pool é um serviço de distribuição de trabalho e de repartição contabilística das recompensas. O pool atribui tarefas de mineração e os mineradores entregam shares que satisfazem um target do pool mais fácil, como base estatística para estimar o trabalho realizado. Apenas um resultado raro satisfaz também o target da rede e permite apresentar um bloco candidato; esse bloco tem de cumprir todas as regras de consenso. Um share comum não é um bloco Bitcoin, e o controlo do pool sobre as tarefas não lhe confere autoridade para alterar o consenso.
Solo Mining tem uma variância elevada: o minerador recebe toda a receita do bloco quando encontra um bloco aceite; caso contrário, não recebe nada. Um pool reúne muitos mineradores e distribui as receitas segundo a proporção estimada do trabalho. Não reduz a Difficulty da rede; apenas suaviza estatisticamente os pagamentos. [Bitcoin Developer Guide — Mining] [Meni Rosenfeld — Analysis of Bitcoin Pooled Mining Reward Systems]
Uma tarefa de mineração parte de um Block Template ou de uma construção equivalente de um bloco candidato. O BIP22 descreve getblocktemplate e o BIP23 as suas extensões para mineração em pool. O protocolo do pool transmite aos workers os campos necessários, os dados da transação coinbase e o espaço de pesquisa. Um ASIC Miner testa cabeçalhos candidatos; o bloco apresentado tem de possuir um hash de cabeçalho que satisfaça o target de Proof of Work da rede e cumprir simultaneamente as restantes regras de consenso. [BIP 22 — getblocktemplate] [BIP 23 — getblocktemplate pooled mining] [Bitcoin Core mining RPC — getblocktemplate]
Um Mining Share é um resultado entregue cujo hash satisfaz o target do pool, normalmente muito mais fácil do que o target da rede. A partir dos shares aceites e da sua dificuldade, o pool estima estatisticamente a proporção de trabalho de cada worker; não se trata de uma contagem exata das suas tentativas. Um share comum que satisfaz apenas o target do pool não se torna um bloco na blockchain nem cria uma confirmação. Serve para medir a contribuição para efeitos contabilísticos. [Meni Rosenfeld — Analysis of Bitcoin Pooled Mining Reward Systems] [Stratum V2 — Mining Protocol]
O pool define um share target mais fácil para receber resultados com frequência suficiente para efetuar medições. O target da rede Bitcoin é muito mais difícil de satisfazer. Um share que satisfaz apenas o target do pool dá origem a um crédito contabilístico; se o mesmo hash satisfizer também o target da rede, pode ser apresentado um bloco candidato. VarDiff altera a dificuldade dos shares e, consequentemente, a sua frequência, não a Difficulty de consenso do Bitcoin. [Stratum V2 — Mining Protocol]
PPS paga um valor esperado definido por cada share aceite, correspondente à sua dificuldade, e transfere para o pool o risco das oscilações aleatórias na descoberta de blocos. FPPS acrescenta normalmente ao subsídio esperado uma estimativa das receitas de taxas de transação. PPLNS distribui as receitas dos blocos efetivamente encontrados segundo os shares de uma janela recente de trabalho, pelo que deixa mais variância a cargo do minerador. As fórmulas específicas, taxas e tratamento dos Stale Blocks dependem das regras de cada pool. [Meni Rosenfeld — Analysis of Bitcoin Pooled Mining Reward Systems] [Braiins Academy — Rewards and Payouts]
Num pool tradicional, o operador do pool constrói normalmente o Block Template e determina também o destinatário da saída coinbase. O minerador pesquisa sobretudo o espaço que lhe foi atribuído. O pool ganha assim influência sobre a seleção de transações, mas não a capacidade de impor um bloco inválido; cada Full Node valida o bloco de forma independente. [Bitcoin Developer Guide — Mining] [Stratum V2 — Protocol Overview]
O Stratum V1 serve para atribuir trabalho de mineração, e o controlo do modelo permanece normalmente no pool. O Stratum V2 separa mais claramente as funções e suporta comunicação cifrada e autenticada. O Job Declaration Protocol opcional permite ao minerador apresentar o seu próprio modelo com a sua seleção de transações, se tanto o minerador como o pool suportarem os componentes necessários. O Mining Protocol do Stratum V2 pode funcionar sem essa possibilidade; a designação Stratum V2 não garante, por si só, uma seleção independente de transações. [Stratum V2 — Protocol Overview]
A concentração dos pools é importante porque um pequeno número de coordenadores pode influenciar a inclusão de transações, a adoção de software e a distribuição do Hashrate a curto prazo. Porém, o Hashrate de um pool não equivale à propriedade dos equipamentos de mineração: os operadores de ASIC podem redirecionar as máquinas. O risco aumenta se os custos de mudança de pool, os contratos ou o firmware limitarem essa possibilidade. [Bitcoin Developer Guide — Mining] [Stratum V2 — Protocol Overview]
Um share pode ser rejeitado por estar desatualizado (stale), duplicado, mal construído ou não corresponder à tarefa atribuída. Uma maior latência entre o minerador e o pool, atualizações lentas das tarefas e falhas de rede aumentam o trabalho perdido. A proporção de stale shares informa, por isso, sobre a eficiência operacional da ligação entre o minerador e o pool; não é o mesmo que um Stale Block na blockchain. [Stratum V2 — Mining Protocol]
O minerador deve verificar as taxas do pool, o modelo de recompensa, o pagamento mínimo e as regras de pagamento, a Share Difficulty, a proporção de shares rejeitados e stale, os servidores e as ligações de reserva, a compatibilidade do firmware e quem controla a seleção de transações. Quando as receitas são significativas, convém comparar o painel do pool com os shares aceites e os seus blocos na blockchain. [Braiins Academy — Rewards and Payouts] [Stratum V2 — Mining Protocol]
Para ter uma visão mais completa, leia este verbete junto com Mineração, Hashrate, Braiins Pool, Stratum V2, Mining Share, Pay Per Share. Também há referências a este verbete em Transação coinbase, ASIC Miner, Hashrate, Nonce.