Pay Per Share

O pool aceita trabalho demonstrado e credita o valor acordado mesmo sem ter acabado de encontrar um bloco. PPS redistribui receitas e riscos entre minerador e operador; não aumenta o desempenho do ASIC nem a probabilidade de sucesso do mesmo hash. Um crédito a receber não é um novo bitcoin criado por cada share. [Rosenfeld — Pay-per-share and pool reserves]

Uma share cumpre o alvo mais fácil do pool; só algumas cumprem também o alvo da rede. Com dificuldade variável, o trabalho deve ser ponderado pela dificuldade da share. Duas shares com alvos diferentes podem ter preços diferentes. Distingue as aceites das submetidas, rejeitadas, duplicadas ou atrasadas; valem as regras publicadas do pool. [Rosenfeld — Pay-per-share and pool reserves] [Braiins — Share difficulty]

Num modelo simples com a mesma convenção de dificuldade, o valor básico esperado de uma share é aproximadamente B × d / D: B é o subsídio do bloco, d a dificuldade da share e D a dificuldade da rede. Depois o pool aplica a sua taxa. Por exemplo, B=3,125 BTC e d/D=0,000001 dão 312,5 sat antes de taxas; não é uma oferta atual nem uma constante de toda a rede. [Rosenfeld — Pay-per-share and pool reserves]

Num período longo sem descobertas, o operador pode dever mais do que acabou de minerar. Precisa de capital e gestão de reservas; uma taxa menor não prova por si só um serviço melhor. O modelo de Rosenfeld relaciona taxas, reservas e risco de falência. Uma promessa PPS não é uma garantia do protocolo de pagamento se o operador falhar. [Rosenfeld — Pay-per-share and pool reserves]

O PPS básico avalia o subsídio. Full Pay Per Share (FPPS) acrescenta uma parcela modelada das taxas de transação; Pay Per Share Plus (PPS+) combina geralmente subsídio em PPS com distribuição PPLNS das taxas efetivamente obtidas. A parcela de taxas do PPS+ pode continuar a depender da sorte do pool. O sinal mais não determina sozinho o método de um serviço. [F2Pool — PPS, PPLNS, FPPS and PPS+]

Maior dificuldade da rede reduz a remuneração pelo mesmo trabalho; um halving altera o subsídio. Em FPPS, a estimativa de taxas muda também conforme o período e o filtro escolhidos. A Luxor descreve, por exemplo, o seu cálculo filtrado, não uma regra universal de FPPS. Um método constante não significa BTC diários constantes, câmbio fixo ou lucro garantido depois da eletricidade. [Luxor — Revenue and payments]

O saldo no pool depende das regras de levantamento: mínimo, calendário, taxa de pagamento e carteira de destino correta. Pagamentos on-chain e Lightning têm verificações de receção diferentes. Restaurar a própria carteira a partir da seed não restaura o acesso à conta do pool. Compara o estado pago com o pagamento recebido, não apenas com o painel de ganhos. [Braiins — Rewards and payout rules]

No mesmo período, compara trabalho aceite ponderado, base da taxa, taxas de transação, deduções, shares rejeitadas e montante efetivamente recebido. Separa receitas do trabalho, custos e variações cambiais. PPS limita uma fonte de oscilação, mas disponibilidade do pool, solvência, condições de levantamento e custos operacionais continuam a ser questões separadas. [Rosenfeld — Pay-per-share and pool reserves] [Luxor — Revenue and payments] [Braiins — Rewards and payout rules]