IdentifyTransactions message not implemented

lorbax commented 4 months ago

IdentifyTransactions and .Succes are not implemented. The JDS just ignores the cases where it necessary to send this message (collisions with short hashes or impossible to reconstruct the tx_hash_list_hash). If the JDC receives such a message, [it responds with an empty vector](https://github.com/stratum-mining/stratum/blob/dev/roles/jd-client/src/lib/job_declarator/message_handler.rs#L45 t).

Good first issue

rockcoolsaint commented 2 months ago

@lorbax I don't quite understand what is to be done here. What is the expected code deliverable?

What does this statement mean? The JDS just ignores the cases where it necessary to send this message (collisions with short hashes or impossible to reconstruct the tx_hash_list_hash)

marathon-gary commented 2 months ago

https://stratumprotocol.org/specification/06-Job-Declaration-Protocol/#617-identifytransactions-server-client

Sent by the Server in response to a DeclareMiningJob message indicating it detected a collision in the tx_short_hash_list, or was unable to reconstruct the tx_hash_list_hash.

The client receives an IdentifyTransactions message from the server, indicating a collision or inability to reconstruct the hash list of tx's. Currently, there is just an empty vec returned.

According to spec it should be providing:

The full list of transaction data hashes used to build the mining job in the corresponding DeclareMiningJob message

The original DeclareMiningJob only contains tx_short_hash_list and tx_hash_list_hash. An IdentifyTransactions message indicates there was a collision in the short hash list or the hash list hash couldn't be recreated.

I assume the client just looks up the original list of tx's and then sends it back in the .Success message.

I will take a pass at a PR for this

lorbax commented 2 months ago

https://stratumprotocol.org/specification/06-Job-Declaration-Protocol/#617-identifytransactions-server-client

Sent by the Server in response to a DeclareMiningJob message indicating it detected a collision in the tx_short_hash_list, or was unable to reconstruct the tx_hash_list_hash.

The client receives an IdentifyTransactions message from the server, indicating a collision or inability to reconstruct the hash list of tx's. Currently, there is just an empty vec returned.

According to spec it should be providing:

The full list of transaction data hashes used to build the mining job in the corresponding DeclareMiningJob message

The original DeclareMiningJob only contains tx_short_hash_list and tx_hash_list_hash. An IdentifyTransactions message indicates there was a collision in the short hash list or the hash list hash couldn't be recreated.

I assume the client just looks up the original list of tx's and then sends it back in the .Success message.

I will take a pass at a PR for this

The list of Txid (32byes each) of declared job transactions should be sent in the .Success, not just the short hashes (6bytes each) that are sent in DeclareMiningJob. Or am I missing something about your comment?

Happy that someone finally decided to tackle this ^^

marathon-gary commented 2 months ago

https://stratumprotocol.org/specification/06-Job-Declaration-Protocol/#617-identifytransactions-server-client

Sent by the Server in response to a DeclareMiningJob message indicating it detected a collision in the tx_short_hash_list, or was unable to reconstruct the tx_hash_list_hash.

The client receives an IdentifyTransactions message from the server, indicating a collision or inability to reconstruct the hash list of tx's. Currently, there is just an empty vec returned. According to spec it should be providing:

The full list of transaction data hashes used to build the mining job in the corresponding DeclareMiningJob message

The original DeclareMiningJob only contains tx_short_hash_list and tx_hash_list_hash. An IdentifyTransactions message indicates there was a collision in the short hash list or the hash list hash couldn't be recreated. I assume the client just looks up the original list of tx's and then sends it back in the .Success message. I will take a pass at a PR for this

The list of Txid (32byes each) of declared job transactions should be sent in the .Success, not just the short hashes (6bytes each) that are sent in DeclareMiningJob. Or am I missing something about your comment?

Happy that someone finally decided to tackle this ^^

Yup! That's my understanding. Was mainly noting down my understanding for validation. Thnx for the Ack! :)

CietyGoblin commented 2 weeks ago

https://stratumprotocol.org/specification/06-Job-Declaration-Protocol/#617-identifytransactions-server-client

Sent by the Server in response to a DeclareMiningJob message indicating it detected a collision in the tx_short_hash_list, or was unable to reconstruct the tx_hash_list_hash.

The client receives an IdentifyTransactions message from the server, indicating a collision or inability to reconstruct the hash list of tx's. Currently, there is just an empty vec returned.

According to spec it should be providing:

The full list of transaction data hashes used to build the mining job in the corresponding DeclareMiningJob message

The original DeclareMiningJob only contains tx_short_hash_list and tx_hash_list_hash. An IdentifyTransactions message indicates there was a collision in the short hash list or the hash list hash couldn't be recreated.

I assume the client just looks up the original list of tx's and then sends it back in the .Success message.

I will take a pass at a PR for this

https://github.com/stratum-mining/stratum/issues/902#issuecomment-2214808996

stratum-mining / stratum

IdentifyTransactions message not implemented #902