Grupo getwork "objetivo"?

En una solicitud getwork, bitcoind envía un destino correspondiente al valor de bits del bloque actual. ¿Los grupos principales envían el mismo objetivo que uno esperaría de bitcoind, la dificultad del objetivo "1" o tal vez algo más?

Respuestas (2)

Acabo de poner en marcha un minero que se conecta a la piscina de aguanieve . getworkMi minero envió fue respondido con esto :

{"id": "1",
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "data": "00000001c5993e03c08cea1b78a2190865f68698c069a8033d60e5e70000082a00000000e0884a966424aac62b4997dc0bae1c60fab2ba12887fa842f07c9cacaf24b4534f3b53931a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "390b85042008bac15b6ce310d791c8612610a0c5ee441b252ee6abee70bf742a",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000"
           },
 "error": null
}

El objetivo que me dio tiene 64 dígitos hexadecimales. Eso es alrededor de 2^256 y, como tal, es más grande que el objetivo máximo de 2^(256-32)-1. Luego me di cuenta de que el objetivo es 'little-endian', lo que significa que está byte por byte al revés. Al invertirlo da:

00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

que es exactamente 2^(256-32)-1, el objetivo máximo.

Así que la piscina de Slush al menos me pide que resuelva bloques de dificultad 1.

Sé que P2Pool establece la dificultad para que sea más alta, por lo que se encontrarán acciones en la cadena de acciones de P2Pool cada 10 segundos. Actualmente, para lograrlo, está dando trabajo con dificultad 609.82, pero cambia cada pocos segundos según la tasa reciente de búsqueda de acciones de P2Pool.

Editar: acabo de comprobar, y resulta que estoy equivocado. Aquí hay una getworkde la instancia de P2Pool que estoy ejecutando:

{"error": null,
 "jsonrpc": "2.0",
 "id": 0,
 "result": {"hash1": "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
            "target": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000",
            "submitold": true,
            "identifier": "15578",
            "data": "000000011e90271e3071e27e4b16142162e54a68776176deeef5fe6e000001a800000000534e460eb3798f9d4149c56dddf486610512007201745fefd7661cedbde821fa4f3b5c461a0c290b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
            "midstate": "acb6f89399060ab343bbd17e3a6cccb89c2211af189bec8da15284a1d5e87b29"
           }
}

Observe que el objetivo es el mismo que en la piscina de aguanieve. Representa una dificultad de 1. Entonces, el minero cree que está buscando acciones de dificultad 1, pero P2Pool rechaza cualquier acción que envíe el minero que tenga una dificultad inferior a 609.82, o cualquiera que sea la dificultad del grupo en ese momento.

(nitpick) El objetivo mínimo es en realidad 0xFFFF00000.... El valor que se muestra arriba en realidad corresponde a la dificultad 0.999985. Como este objetivo permite las mismas optimizaciones para los mineros que la dificultad real 1, se utiliza este objetivo ligeramente superior.
Hmmm, lo sabía. ¡Me pregunto por qué me equivoqué, dos veces, en mi respuesta anterior! ¿Y por qué los pools de minería no usan la dificultad 1 en lugar de la dificultad 0.999985?
¿Por qué usarían cualquier cosa menos la dificultad más baja computable de manera eficiente?
La dificultad es una constante en cualquier caso, ¿no? ¿Cómo entra en esto la eficiencia computacional? ¿Está diciendo que es más fácil usar bnProofOfWorkLimit porque ya está definido que usar 0xFFFF<<n y tener que dedicar tiempo a averiguar cuál debería ser n?
La mayoría del software de minería simplemente verifica dentro de su ciclo cerrado si los primeros 32 bits del resultado del hash son cero, lo que implícitamente corresponde a una dificultad de 0.999985. Posteriormente, fuera del bucle principal, los resultados se verifican para que coincidan con el objetivo real. Si un grupo de minería requiriera dificultad total 1, vería un 0,0015% menos de acciones, que se calculan de todos modos.

La mayoría de los fondos definen su valor objetivo (valor mínimo requerido para ganar una "participación"), como:

T = 2 ** (256 - 32) - 1
= 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

El protocolo Bitcoin define una dificultad de 1 como objetivo de:

D = 0xffff * 2**208
= 0x00000000ffff0000000000000000000000000000000000000000000000000000

Son casi iguales:

T/D = 1.0000152590218967

El objetivo preciso utilizado para obtener acciones podría establecerse en un número mayor, pero eso aumentaría la cantidad de solicitudes de trabajo enviadas al servidor, ya que las acciones serían más fáciles de encontrar. Tenga en cuenta que si reduce el tamaño del objetivo, reducirá la probabilidad de encontrar CUALQUIER recurso compartido válido para un encabezado de bloque determinado (a menos que permita cambiar la marca de tiempo y el nonce). En su forma actual, la cantidad esperada de recursos compartidos encontrados por solicitud getwork es aproximadamente 1 (cuando el objetivo tiene 32 bits cero iniciales).