Cálculos
Ejemplo 1
Desea comprar 100 Mhs Scrypt y está dispuesto a pagar un total de 0.05 BTC a 5 BTC / GH / día. ¿Cuánto tiempo durará su pedido?
(0.05 BTC / 0.1 GH) / 5 BTC / GH / día = 0.5 BTC / Gh / 5 BTC / GH / día = (0.5 / 5) día = 0.1 día = 2.4 horas
Obtendrá 2.4 horas de velocidad de 0.1 GH por 0.05 BTC a 5 BTC / GH / día.
Ejemplo 2
Desea comprar 100 Mhs Scrypt por 1 día a 5 BTC / GH / día. ¿Cunato te costará?
1 día * 0.1 GH * 5 BTC / GH / día = 0.5 BTC
Le costará 0.5 BTC por 0.1 GH velocidad a 5 BTC / GH / día por un día.
Nota: Estos son solo ejemplos, pero puede usar la fórmula para sus propios cálculos o simplemente puede iniciar sesión y verificar los cálculos automáticos antes de realizar un nuevo pedido.
Los mineros cambian a una orden que paga mejor gradualmente, no al instante. Esto es para evitar un "salto de orden" excesivo porque, debido a algunas limitaciones de protocolo de stratum, un minero tiene que desconectarse antes de que pueda servir otra orden nuevamente. Demasiadas desconexiones afectarían el rendimiento del minero (se realizaría más trabajo en el pool de respaldo, además, cuando se corta la conexión, existe la posibilidad de que se pierdan aportes). Por lo tanto, se establecieron dos limitaciones:
El término pagas por los aportes "aceptados" se refiere a los aportes que el sistema de NiceHash determina como válidas (consulte también ¿Cómo funciona exactamente el pago por acción válida y cobra por aporte válido?). La validación de los aportes en NiceHash es obligatoria para evitar posibles trampas, como pools falsas / modificadas y similares.
Estados del pool
Hay 3 posibles estados de estabilidad de su pool:
Hashrate disponible
Tenga en cuenta que el hashrate actual, como se muestra en la página principal de NiceHash.com, no es el hashrate total disponible. Tenga en cuenta que algunos proveedores de hashrate (vendedores) están estableciendo su umbral de precio un poco más alto, generalmente un poco más de lo que pagan los multi-pools populares. Este hashrate está "oculto", pero podría estar disponible. Por lo tanto, para poder aprovechar toda la potencia, disponible en NiceHash, probablemente debería ofertar un poco más de lo que pagan los multi-pools. Por supuesto, tome esto simplemente como una sugerencia de nosotros y ajuste sus precios para satisfacer sus necesidades individuales.
Enfoque de pago por aporte
El motor de stratum de NiceHash implementa un algoritmo innovador que detecta la validez de los aporte y la estabilidad del pool. Nuestro objetivo es que los proveedores reciban el 100% del pago por todo el trabajo válido que producen sus equipos (al igual que con cualquier pool común o multipool) y los compradores pagan el 100% solo por el trabajo válido que se haya enviado a los pool de los compradores (tal como usaría sus propios equipos).
Cuando un proveedor envía su trabajo (un aporte) a NiceHash, es validado por nuestro motor de stratum y validador.
A) Si nuestro motor valida un aporte pero es rechazado por el pool del comprador (por definición de protocolo del stratum), esto significa que hay algo mal con el pool (ya sea que esté mal configurado, que use el algoritmo incorrecto o que tenga micro problemas temporales) y el trabajo del proveedor fue válido. En este caso, al proveedor se le paga por el trabajo que proporcionó. Entonces, en este caso, es responsabilidad del comprador cambiar a otro pool. Sin embargo, si el equipo del proveedor está mal configurado y está produciendo algunos (no necesariamente todas) los aportes inválidos, nuestro motor detecta estos aportes y, por esos aportes, el proveedor no recibe el pago (y el comprador no paga por ellos) porque es responsabilidad del proveedor proporcionar equipos mineros estables y configurados adecuadamente. Este tipo de aportes inválidos generalmente se produce por equipos mal overclockedos/sobre calentados/mal configurados (generalmente hay 0% de este tipo de aportes inválidos para equipos configurados correctamente/normalmente y aproximadamente 1-5% de este tipo de aportes inválidos en equipos mal configurados).
B) Nuestro motor verifica adicionalmente la capacidad de respuesta del pool del comprador. Cuando el pool del comprador deja de responder (el pool está sufriendo DDoSed, el pool tiene problemas de rendimiento, etc.), el motor desconecta inmediatamente este pool, desactiva el pedido del comprador y redirige el trabajo a otros pool/pedidos. En este caso, el comprador ya no esta pagando (su pedido está en "pausa") y los proveedores están vendiendo su trabajo a otros pedidos (no se pierde hashrate, pero los proveedores pueden notar una desconexión / reconexión rápida de sus mineros). Esta detección es mucho más rápida que la detección de software de minería ordinaria (cgminer, etc.) y, por lo tanto, los compradores pagan menos de lo que pagarían alquilando equipos físicos (que generalmente se basan en el tiempo), incluso si configuraran pools de respaldo. El comprador puede establecer múltiples pedidos con múltiples pools y, por lo tanto, asegurarse de que la mayoría de sus pedidos serán procesados incluso si algunos de los pools son inestables.
C) Algunos pools de los compradores están generando muchos reinicios de trabajo. Esto suele ser un síntoma de monedas con muy baja dificultad o multipools que cambian monedas muy rápido y no tienen una implementación eficiente de cambio de monedas. En algunos casos, esto también es el resultado de algunos pools privados personalizados. Los reinicios de trabajo excesivos reducen la eficiencia de los mineros, especialmente en rápidos mineros ASIC con controladores débiles. Hemos abordado este problema recompensando a los proveedores (vendedores) con aportes adicionales pagados por los compradores cuando se produce un reinicio rápido del trabajo. Si usted es un vendedor, es muy importante que controle el promedio del hashrate a mediano plazo que se informa en nuestro sitio web (se calcula a partir de los aportes, recompensados a su minero) y las ganancias reales, no solo del hashrate o la relación aceptado/rechazado que muestra el hardware/software de su minero, ya que en algunos casos se le recompensará por más de lo que le muestra su minero en términos de hashrate.
En esencia, esto significa que al proveedor se le paga el 100% por todo el trabajo válido que producen sus equipos (al igual que con cualquier pool ordinario o multipool) y los compradores pagan el 100% por del trabajo válido que se ha enviado a los pools del comprador ( tal como si usara sus propios equipos).
Es un juego 100% justo para vendedores y compradores.