¿Cuál es la relación entre la tasa de hash y las acciones aceptadas?

Específicamente, esta pregunta es sobre Litecoin, pero sospecho que la respuesta se aplicaría a ambos.

Digamos que tiene una plataforma minera a 700Kh/s (LTC). Parece que obtienes, más o menos, una o unas pocas acciones aceptadas por segundo.

Según tengo entendido, al minar, está iterando de 0 a ~ 4 mil millones para su nonce. Uno de esos nonce es el número que está buscando y dará como resultado una participación aceptada.

En promedio, esperaría resolver el nonce correcto en aproximadamente 2 mil millones de intentos. Pero, si solo está minando a 700Kh/s, las matemáticas no cuadran. Si solo está probando 700 000 nonces por segundo, tardará unos 45 minutos en encontrar el nonce correcto.

¿Que me estoy perdiendo aqui?

Respuestas (2)

Realmente no hay uno cuando estás minando en grupo. La mayoría de los grupos en estos días usan VarDiff para lograr la misma cantidad de acciones por minuto cambiando la dificultad de los trabajadores. Ahora, en una plataforma minera de gama baja (digamos 20 kh/s), la cantidad de acciones aceptadas puede variar mucho, ya que puede tener mucha suerte con su parte o puede ser mala suerte. Por lo tanto, siempre que tenga un nivel "cuerdo" de poder de hash, no debería ver (m) ninguna tendencia / cambio (siempre que el grupo + VarDiff esté configurado correctamente).

Dicho esto, cuando se conecta por primera vez a grupos habilitados para VarDiff, comenzará con una diferencia de 1, luego se ajustará durante un período de tiempo para lograr una tasa de participación por minuto definida por la operación del grupo.

Fuente: Yo, soy un pool-op

EDITAR En un momento, la cantidad de acciones que envió directamente relacionadas con su tasa de hash, cuantas más acciones aceptadas, más rápido estaba procesando. Los productos de AsicMiner todavía usan el protocolo originalmente usado por los pools (y bitcoind) llamado "getwork". El más notable de los servidores de grupo utilizados en ese momento es pushpool.

Con VarDiff no tiene la capacidad de calcular por el número de acciones enviadas. Entonces, ahora calcula el hashrate en función de la dificultad del recurso compartido enviado. Personalmente, descubrí que cuando el cálculo de hashrate basado únicamente en la cantidad de acciones enviadas se sopesa ligeramente con su cálculo de hashrate basado en la dificultad de la acción enviada, el hashrate del usuario que calcula es más preciso que lo que tendría si calculara el hashrate puramente en la dificultad de la parte enviada.

Entonces, la dificultad es la cantidad de bytes cero iniciales requeridos en el hash, ¿verdad? Entonces, una dificultad de 1 requeriría que solo el primer byte fuera cero, ¿y esto sería más fácil de encontrar? Pero, ¿el grupo lo recompensará con más LTC por acciones de mayor dificultad ("calidad")?
Ahh parece que ese es el problema. Estoy pensando en términos del protocolo GetWork. VarDiff cambia todo eso. Entiendo.

"Uno de esos nonce es el número que está buscando y resultará en una participación aceptada".

Esta suposición es incorrecta. Todo lo que necesita para asegurarse es que su hash esté por debajo del objetivo (y el objetivo se basa en la dificultad). Por lo tanto, puede golpear un bloque que no tiene un nonce que le daría un hash por debajo del objetivo, y podría golpear un bloque para el cual cada nonce le daría una participación válida.

Entonces, si, por ejemplo, su objetivo es 0x0FFFFFFFF..., entonces, en promedio, 1 de cada 16 hashes dará como resultado un recurso compartido válido. Y si su objetivo es 0x00000000000000000FFFF..., por ejemplo, entonces probablemente necesitará ejecutar el bucle varias veces para alcanzar un bloque.

Bueno, entonces, si su objetivo fuera 0x0000FFFFFFFF.... en promedio, uno en ~65,000 sería válido, ¿verdad? Entonces, ¿mi comentario sobre 0X00000000FFFFFFFFFFFF... resultando en uno en cuatro mil millones es correcto en promedio?
Sí, si cuento los ceros correctamente. Pero el punto es que la cantidad de iteraciones por nonce es bastante irrelevante: es el objetivo el que define la relación entre hashrate y sharerate, y la dificultad está relacionada con el objetivo. Además, los grupos generalmente tienen una dificultad establecida para todos (eso significa que obtendría más acciones en menor dificultad, pero todos obtendrían más acciones, por lo que cuando el grupo llega a un bloque, una sola acción vale menos), o varía dificultad, y luego calcula las acciones enviadas con mayor dificultad como más valiosas cuando se trata de distribuir el bloque.
Hice una lectura rápida y parece que litecoin usa dificultades fraccionarias... Lo cual no tiene sentido para mí. Siempre pensé en la dificultad como el número de bytes cero en el hash. Ahora parece que es si el hash es menor que el objetivo. ¿Cómo se vería un objetivo de dificultad normal que resultaría en una acción aceptada por segundo en algún lugar alrededor de 700-1500Kh/s?
Actualmente estoy minando en dificultad 32 y mi objetivo es 0x000007fff800... ; Para ser completamente honesto, no tengo idea de cuál es la relación exacta entre dificultad y objetivo. Diría que esto daría como resultado aproximadamente 1 recurso compartido por 1-2 segundos en una plataforma de minería de ~1MH/s, pero generalmente no desea enviar recursos compartidos demasiado rápido, o corre el riesgo de quedar limitado por el rendimiento de su red.
¿Cuál es la relación entre la tasa de hash y las acciones aceptadas?
RespuestasAquíPolítica de privacidad1y, 0v