Ajuda no Mercado de Hash Rate


O que mais precisa de saber antes de efetuar uma ordem?

Cálculos


Exemplo 1

Deseja comprar 100 Mhs Scrypt e está disposto a pagar um total de 0,05 BTC a 5 BTC/GH/dia. Por quanto tempo irá a sua ordem ser executada?

(0.05 BTC/0.1GH) /5 BTC/GH/dia = 0.5 BTC/Gh / 5 BTC/GH/dia = (0.5 / 5) dia = 0.1 dia = 2.4 horas

Irá ter 2.4 horas de mineração a uma velocidade de 0.1 GH com 0.05 BTC ao preço de 5 BTC/GH/dia.


Exemplo 2

Deseja comprar 100 Mhs Scrypt por 1 dia a 5 BTC/GH/dia. Quanto vai custar?

1 dia * 0.1 GH * 5 BTC/GH/dia = 0.5 BTC

O custo será de 0.5 BTC por uma velocidade de 0.1 GH (ou 100Mhs) ao preço de 5 BTC/GH/dia por 1 dia de mineração.

Nota: Estes são apenas exemplos, mas pode usar a fórmula para seus próprios cálculos ou pode simplesmente efetuar login e verificar os cálculos automáticos antes de efetuar uma nova ordem.

Os mineiros mudam gradualmente para uma ordem com melhor pagamento - não instantaneamente. Isto evita "saltosentre ordens" excessivos porque, devido a algumas limitações do protocolo stratum, um mineiro precisa de ser desconectado antes de poder atender outra ordem. Muitas desconexões afetariam o desempenho do minerador (mais trabalho seria realizado no pool de backup, além disso, quando a conexão cair, há uma possibilidade das shares serem perdidas). Assim, duas limitações foram postas em prática:


  • Os mineiros mudam para uma ordem de pagamento melhor lentamente, com uma taxa de 20% de mineiros de ordens de pagamento mais baixas - isto é realizado a cada 4 minutos;
  • Há uma pequena taxa não reembolsável de 0.00001 BTC ao iniciar novas ordens para reduzir o envio de ordens imprudentes sem considerar se tudo está definido corretamente e para evitar ataques com spam de ordens; recomendamos que edite as ordens existentes em vez de cancelar / iniciar novas ordens (é claro que não há taxa para editar as ordens).

O termo "paga pelas shares aceites" refere-se às shares que são determinadas como válidas pelo sistema da NiceHash (ver também Como é que funcionam o pay-per-valid-share e o get-paid-per-valid-share?). A validação de shares na NiceHash é obrigatória para evitar possíveis fraudes, como pools falsos/modificados e semelhantes.



Estados do Pool


Existem 3 estados de estabilidade possíveis do seu pool:

  • O seu pool está a operar normalmente e sem estrangulamentos: quase todas as shares (99 +%) aceites na NiceHash também serão aceites no seu pool (paga exatamente o que recebe)
  • O pool é muito lento a processar as shares (quando o pool está sobrecarregado): determinadas shares serão detetadas como antigas pelo pool, enquanto a NiceHash as detetará como aceites (paga mais do que recebe)
  • O seu pool está inoperante, a NiceHash não está conectada ao seu pool: nenhum trabalho é fornecido, os mineiros não fornecem hashrate, nenhuma share está a ser enviada (não paga nada)


Hashrate Disponível


Lembre-se de que a quantia de hashrate atual, conforme exibido na página inicial da niceHash.com, não é a quantia de hashrate total disponível. Lembre-se de que alguns fornecedores hashrate (vendedores) definem o seu limite de preço um pouco mais alto - geralmente um pouco mais alto do que as multi-pools populares estão a pagar. Este hashrate está "oculto", mas pode estar disponível. Portanto, para poder aproveitar toda a hashrate disponível na NiceHash, provavelmente deve oferecer um preço um pouco mais alto do que as multi-pools estão a pagar. Obviamente, tome isso apenas como uma sugestão nossa e ajuste seus preços para atender às suas necessidades individuais.


Abordagem Pay-per-share


O mecanismo de stratum NiceHash implementa um algoritmo inovador que detecta a validade das shares e a estabilidade do pool. O nosso objetivo é que os mineiros sejam 100% pagos por todo o trabalho válido que os seus equipamentos produzem (de forma idêntica a um pool comum ou multipool) e os compradores pagam 100% apenas pelo trabalho válido que foi enviado aos pools dos compradores (como se estivessem a usar os seus próprios equipamentos para minar).

Quando um provedor envia o seu trabalho (uma share) à NiceHash, este é validado pelo nosso mecanismo de stratum e validador.

A) Se uma share for validada pelo nosso mecanismo, mas for rejeitada pelo pool do comprador (por definição de protocolo de stratum), isto significa que há algo errado com o pool (configurado incorretamente, utilização de um algoritmo errado ou problemas temporários) e o trabalho do provedor era válido. Nesse caso, o provedor é pago pelo trabalho que forneceu. Portanto, neste caso, é responsabilidade do comprador mudar para outros pools. No entanto, se os equipamentos do provedor estiverem configurados incorretamente e a produzir algumas (não necessariamente todas) shares inválidas, essas shares serão detectadas pelo nosso mecanismo e, para essas shares, o provedor não será pago (e o comprador não pagará por elas), pois é responsabilidade do fornecedor fornecer equipamentos de mineração estáveis e adequadamente configurados. Este tipo de shares incorretas geralmente é produzido por equipamentos com overclock/superaquecido/mal configurado (geralmente existem 0% desse tipo de shares inválidas para equipamentos configurados com bom/normal e aproximadamente 1-5% desse tipo de shares inválidas para equipamentos mal configurados).

B) O nosso mecanismo também verifica a capacidade de resposta do pool do comprador. Quando o pool do comprador não responde (o pool está a ser atacado, com problemas de desempenho etc.), o mecanismo desconecta-se imediatamente desse pool, desativa a ordem do comprador e redireciona o trabalho para outros pools/ordens. Nesse caso, o comprador não está a pagar (a ordem está em "pausa") e os fornecedores estão a vender o seu trabalho para outras ordens (não há perda de hashrate, mas os fornecedores podem perceber uma desconexão/reconectação rápida nos seus equipamentos) . Essa detecção é muito mais rápida que a detecção de software de mineração comum (cgminer etc.) e, portanto, os compradores pagam menos do que pagariam alugando plataformas físicas (que geralmente são baseadas no tempo) - mesmo que se configurem pools de backup. O comprador pode definir várias ordens com vários pools e, assim, garantir que a maioria das suas ordens obtêm processos, mesmo que alguns deles sejam instáveis.

C) Alguns pools dos compradores reiniciam muito os trabalhos. Geralmente, isto é um sintoma de moedas com dificuldade muito baixa ou de multipools que trocam de moedas muito rapidamente e não têm uma implementação eficiente da troca de moedas. Em alguns casos, isto também é resultado de alguns conjuntos privados personalizados. O reinício excessivo do trabalho reduz a eficiência dos mineiros, especialmente em mineradores rápidos ASIC com controladores fracos. Resolvemos esse problema recompensando os provedores (vendedores) com shares extras pagas pelos compradores quando ocorrem reinicializações rápidas do trabalho. Se é um vendedor, é muito importante monitorar a hashrate média a médio prazo relatado no nosso site (calculado a partir de shares, recompensadas ao seu mineiro) e os ganhos reais, e não apenas a hashrate ou a taxa de rejeição (aceites/rejeitadas) a de rejeição exibida pelo hardware/software do seu mineiro, pois em alguns casos será recompensado por mais do que o seu mineiro está a mostrar em termos de hashrate.

Essencialmente, isto significa que o provedor é 100% pago pelo trabalho válido que os seus equipamentos produzem (como se tivessem a usar um pool comum) e os os compradores pagam 100% do trabalho válido enviado às pools dos compradores (como se estivessem a minar com os seus equipamentos).

É um jogo 100% justo para vendedores e compradores.



Mercado de Hashrate