Estoy tratando de entender la idea detrás del protocolo getwork, olfateando mi comunicación con un grupo de mineros bitminter.
Previamente, he leído la discusión aquí , pero mirando mis paquetes, creo que hay algunas cosas que se implementan de manera diferente. Puedo entender que mi pregunta puede ser demasiado vaga, porque principalmente estoy expresando mis ideas sobre cómo funciona el protocolo, lo que puede ser totalmente erróneo. Pero, por favor, no seas demasiado duro.
Quiero seguir el protocolo y explicar mis pensamientos, si me equivoco en algún momento, explíqueme dónde me equivoqué:
1) mi cliente está autorizando en el servidor enviando una solicitud posterior
POST/HTTP/1.1
Content-Type:application/json
Accept:application/json
X-Mining-Extensions:longpollbcidmidstaterollntime
X-BCID:somenumber
X-Mining-Hashrate:my
Authorization:mySignature
Content-Length:39
Host:mint.bitminter.com:8332
Connection:Keep-Alive
User-Agent:BitMinter/1.3.0[BitMinter]
Hasta donde entendí, el cliente solo dice qué extensiones puede admitir, su tasa de hash (basado en esto, un servidor le dará un trabajo que hacer), sus credenciales de autorización.
Algunas cosas que no puedo entender aquí. ¿Qué es X-BCID y qué evita que el cliente envíe un hashrate incorrecto? Por lo que entendí, el servidor no puede verificar el trabajo de todos los clientes, por lo que no podrá detectar el hashrate incorrecto. Entiendo que lo más probable es que me equivoque aquí, pero simplemente no puedo entender cómo se hace.
2) después de aceptar la aprobación de las credenciales de los clientes, solicita trabajo. A veces tiene una cadena enorme dentro del campo de parámetros. No puedo entender qué representa esa cadena y por qué aparece.
{
"method":"getwork",
"params":[],
"id":1
}
3) el servidor está respondiendo con la información que admite, tiempo después del cual las respuestas al servidor estarían desactualizadas. Aquí también aparece este X-BCID que no puedo entender.
HTTP/1.1 200 OK
X-Stratum:stratum+tcp://eu1.bitminter.com:3333
X-Long-Polling:/lp
X-BCID:someNumber
X-Roll-NTime:expire=7Date:Mon,07Jan201319:52:20GMT
Server:Outpost/1.1.0 beta1
Content-Length:374
Content-Type:application/json;charset=UTF-8
Connection:Keep-Alive
Keep-Alive:timeout=895,max=5
4) junto con el trabajo que el cliente tiene que hacer:
{
"result":{
"data":"huge string",
"target":"smaller string"
},
"error":null,
"id":1
}
de la fuente mencionada anteriormente, entendí que la picadura enorme contiene la información sobre el trabajo para el cliente (de qué cadena a qué cadena tiene que iterar y calcular hashes) y compararla con una cadena más pequeña . Entonces, si durante los cálculos encuentro valor, cuyos hashes me darán una cadena más pequeña , terminaré un bloque. No entendí por qué tengo un campo de error aquí. ¿Qué está probando?
Entonces, mis preguntas son :
X-BCID es una extensión personalizada utilizada solo por la implementación getwork de BitMinter. Es un ID de cambio de bloque. En caso de que la encuesta larga no funcione de manera óptima o los cambios de bloque se produzcan demasiado rápido para que la encuesta larga los atrape a todos, al ver una nueva ID de cambio de bloque, el cliente se da cuenta de que se perdió un cambio de bloque.
El servidor no valida el hashrate enviado por el cliente. En el grupo de BitMinter, la implementación de dificultad variable (vardiff) lo utiliza actualmente para determinar la dificultad inicial del trabajador, hasta que el grupo tenga suficientes datos para estimar una tasa de hash.
Los parámetros para getwork están vacíos cuando el cliente solicita un nuevo trabajo y tienen datos cuando el cliente envía una prueba de trabajo. Esto es una tontería con el protocolo getwork, la función rpc es "getwork" tanto si está obteniendo trabajo como si está enviando resultados de trabajo.
El campo de error en la respuesta siempre está presente, ya que es requerido por el estándar JSON-RPC. Puede leer más sobre JSON-RPC en http://json-rpc.org/
david schwartz