Vous voulez acheter 100 MH/s Scrypt et vous êtes prêt à payer un total de 0,05 BTC à 5 BTC/GH/jour. Combien de temps votre ordre va-t-il durer ?
(0,05 BTC / 0,1 GH) / 5 BTC/GH/jour = 0,5 BTC/GH / 5 BTC/GH/jour = (0,5 / 5) jour = 0,1 jour = 2,4 heures
Vous obtiendrez 2,4 heures de vitesse de 0,1 GH pour 0,05 BTC à 5 BTC/GH/jour.
Vous voulez acheter 100 MH/s Scrypt pour 1 jour à 5 BTC/GH/jour. Combien cela vous coûtera-t-il ?
1 jour * 0,1 GH * 5 BTC/GH/jour = 0,5 BTC
Il vous en coûtera 0,5 BTC pour une vitesse de 0,1 GH à 5 BTC/GH/jour pendant un jour.
Remarque : Ce ne sont que des exemples, vous pouvez utiliser la formule pour vos propres calculs ou simplement vous connecter et vérifier les calculs automatiques avant de passer un nouvel ordre.
Les mineurs passent progressivement à un ordre mieux payé, et non instantanément. Cela permet d’éviter les "sauts d’ordre" excessifs, car selon certaines limitations du protocole stratum, un mineur doit être déconnecté avant de pouvoir servir un autre ordre. Trop de déconnexions affecteraient les performances du mineur (plus de travail effectué sur la pool de secours, et en cas de déconnexion, des shares pourraient être perdus). Ainsi, deux limitations ont été mises en place :
Le terme "accepté" pour lequel vous payez fait référence aux shares déterminés comme valides par le système NiceHash (voir aussi : Comment fonctionne exactement le système de paiement par shares valides ?). La validation des shares sur NiceHash est obligatoire afin d’éviter toute tentative de fraude, comme des pools modifiés ou fictifs.
Il y a 3 états possibles de stabilité pour votre pool :
Gardez à l’esprit que le hashrate actuel affiché sur la page d’accueil de NiceHash.com n’est pas le hashrate total disponible. Certains fournisseurs de hashrate (vendeurs) définissent leur seuil de prix un peu plus haut — généralement un peu plus élevé que ce que les multi-pools populaires paient. Ce hashrate est "caché" mais pourrait être disponible. Par conséquent, pour exploiter pleinement la puissance disponible sur NiceHash, vous devriez probablement enchérir un peu plus haut que les multi-pools. Bien sûr, considérez cela comme une simple suggestion et ajustez vos prix selon vos besoins individuels.
Le moteur stratum de NiceHash implémente un algorithme innovant qui détecte la validité des shares et la stabilité de la pool. Notre objectif est que les fournisseurs soient payés à 100 % pour tout travail valide produit par leurs rigs (comme avec n’importe quelle pool ou multi-pool) et que les acheteurs ne paient à 100 % que pour le travail valide soumis aux pools des acheteurs (comme s’ils utilisaient leurs propres rigs).
Lorsqu’un fournisseur soumet son travail (un share) à NiceHash, il est validé par notre moteur stratum et le validateur.
A) Si un share est validé par notre moteur mais rejeté par la pool de l’acheteur (selon la définition du protocole stratum), cela signifie que la pool présente un problème (mauvaise configuration, mauvais algorithme ou micro-problèmes temporaires) et le travail du fournisseur était valide. Dans ce cas, le fournisseur est payé pour le travail fourni. Il incombe donc à l’acheteur de changer de pool. Cependant, si le rig du fournisseur est mal configuré et produit certains shares invalides (pas forcément tous), ces shares sont détectés par notre moteur et pour ces shares, le fournisseur n’est pas payé (et l’acheteur ne paie pas) car il est de la responsabilité du fournisseur de fournir des rigs correctement configurés et stables. Ces shares invalides sont généralement causés par des rigs overclockés, surchauffés ou mal configurés (0 % pour des rigs bien configurés, environ 1 à 5 % pour des rigs mal configurés).
B) Notre moteur vérifie également la réactivité de la pool de l’acheteur. Lorsque la pool devient non réactive (attaque DDoS, problème de performance, etc.), le moteur déconnecte immédiatement cette pool, désactive l’ordre de l’acheteur et redirige le travail vers d’autres pools/ordres. Dans ce cas, l’acheteur ne paie plus (son ordre est en "pause"), et les fournisseurs vendent leur travail à d’autres ordres (aucun hashrate n’est perdu, mais les fournisseurs peuvent constater une déconnexion/reconnexion rapide sur leurs mineurs). Cette détection est beaucoup plus rapide que celle des logiciels de minage classiques (cgminer, etc.), et donc les acheteurs paient moins que s’ils louaient des rigs physiques (généralement basé sur le temps) — même s’ils avaient configuré des pools de secours. L’acheteur peut définir plusieurs ordres avec plusieurs pools et ainsi s’assurer que la majorité de ses ordres sera traitée même si certaines pools sont instables.
C) Certaines pools d’acheteurs génèrent de nombreux redémarrages de travail. Cela est souvent dû à des coins à très faible difficulté ou des multi-pools changeant rapidement de coins sans une implémentation efficace du changement de coin. Dans certains cas, cela provient aussi de pools privés personnalisés. Les redémarrages excessifs réduisent l’efficacité des mineurs, surtout sur des ASIC rapides avec contrôleurs faibles. Nous avons résolu ce problème en récompensant les fournisseurs (vendeurs) avec des shares supplémentaires payés par les acheteurs lorsque des redémarrages rapides se produisent. Si vous êtes vendeur, il est très important de surveiller le hashrate moyen à moyen terme rapporté sur notre site (calculé à partir des shares attribués à vos mineurs) et vos gains réels, pas seulement le hashrate ou le ratio accept/reject affiché par votre matériel/logiciel de minage, car dans certains cas, vous serez rémunéré pour plus que ce que vos mineurs affichent en termes de hashrate.
En essence, cela signifie que le fournisseur est payé à 100 % pour tout travail valide produit par ses rigs (comme avec n’importe quelle pool ou multi-pool) et que les acheteurs paient à 100 % pour le travail valide soumis aux pools des acheteurs (comme s’ils utilisaient leurs propres rigs).
C’est un système totalement équitable pour les vendeurs et les acheteurs.