Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xor ID into key_root instead of dereferencing #29

Open
webmaster128 opened this issue Dec 2, 2018 · 2 comments
Open

xor ID into key_root instead of dereferencing #29

webmaster128 opened this issue Dec 2, 2018 · 2 comments

Comments

@webmaster128
Copy link
Contributor

In a fork of this project (other coin), the following change made the difference between working an non-working (no GPU results after thousands of %) on a NVIDIA Corporation GeForce GTX 1080, OpenCL 1.2.

diff --git a/src/opencl/entry.cl b/src/opencl/entry.cl
index fbd7a4f..47fb738 100644
--- a/src/opencl/entry.cl
+++ b/src/opencl/entry.cl
@@ -23,12 +23,20 @@ __kernel void generate_pubkey(
        ulong max_address_value,
        uchar generate_key_type
 ) {
-       int const thread = get_global_id (0);
        uchar key_material[32];
        for (size_t i = 0; i < 32; i++) {
                key_material[i] = key_root[i];
        }
-       *((size_t *) key_material) += thread;
+
+       const uint64_t thread_id = get_global_id(0);
+       key_material[24] ^= (thread_id >> (7*8)) & 0xFF;
+       key_material[25] ^= (thread_id >> (6*8)) & 0xFF;
+       key_material[26] ^= (thread_id >> (5*8)) & 0xFF;
+       key_material[27] ^= (thread_id >> (4*8)) & 0xFF;
+       key_material[28] ^= (thread_id >> (3*8)) & 0xFF;
+       key_material[29] ^= (thread_id >> (2*8)) & 0xFF;
+       key_material[30] ^= (thread_id >> (1*8)) & 0xFF;
+       key_material[31] ^= (thread_id >> (0*8)) & 0xFF;

My suggestion is that when dereferencing and assigning to key_material, the compiler does not understand that key_material depends on get_global_id.

Do you want to have this patch on master to avoid future surprises? Unfortunatly I cannot reproduce master by the patch because of #28.

@PlasmaPower
Copy link
Owner

This problem is separate from #28?

@webmaster128
Copy link
Contributor Author

Yes, it is independent. I do not encounter the problem in #28 in my fork because of some other code changes. I removed key gen type 2 and implemented bip39 passphrases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants