Quote
i have 800Mkey/s GPU 
What is your strength?
Topic: [ARCHIVE] Bitcoin challenge discusion - page 28. (Read 29562 times)
What is your strength?
Each interval is a different time zone. 1-3-4-5-6.. hours.
I have also scanned for 1 day.
2fast...maybe you be faster me...anyway i know range where is it but my speed is sad))
We can work together, if you want.
have you got terlegram? pm me
Each interval is a different time zone. 1-3-4-5-6.. hours.
I have also scanned for 1 day.
2fast...maybe you be faster me...anyway i know range where is it but my speed is sad))
We can work together, if you want.
i have 800Mkey/s GPU
Each interval is a different time zone. 1-3-4-5-6.. hours.
I have also scanned for 1 day.
2fast...maybe you be faster me...anyway i know range where is it but my speed is sad))
Yes I'm using bitcrack. RX 580 89MKey / Sec
In fact, if everyone shares the areas, it will resolve faster.
In fact, if everyone shares the areas, it will resolve faster.
try the following options and tell me if you are still getting 89Mkey/s
-b 72 -t 256 -p 1024
(auto-translate)
What u know about this?
(given the probabilistic nature of the kangaroo, this can help)
Now some super secret asic boost algorithm is being heard. Who knows what about him?
Consider several ways to find a hash with a given complexity
1. Sequential nonce from zero
2. Sequential search not from zero, but from a random point
3. Random search nonce.
Now each of the methods is separate. For clarity, let nonce vary from 0 to 1,000,000 and let us look for a hash with three zeros
Sequential nonce from zero .
In this case, the miner will find the hash on average for 3845 iterations, but with a probability of 61% iterations will be less. That is, Of the 100 hashes found, 61 hashes will be found faster than in 3845 iterations.
Sequential enumeration not from zero, but from a random point
In this case, the miner will find the hash on average for 3845/2 = 1923 iterations, while with a probability of 39.4% iterations will be less (I calculated this additionally). That is, out of 100 hashes, 40 will be found faster than in 1923 iterations.
Twice as fast as in the first case! This is because the random beginning, with a normal distribution, will fall on average to the center of the segment for enumeration.
Also in this method with a probability of 259/1000000 the hash will be found immediately.
Random brute force nonce.
In this case, you can never find the desired hash at all, but with a probability of 259/1000000, the hash will be found on the first try. If the random distribution is distributed normally, then the probabilities should add up, which means after 1923 iterations the probability of finding a hash will be already 50%. That is, out of 100 hashes, 50 will be found faster than in 1923 iterations.
As a result, it turns out that the first algorithm is the slowest. The third algorithm is the fastest. If I haven’t messed up anything of course ...
and googling "Probabilistic Bitcoin Mining Method"1. Sequential nonce from zero
2. Sequential search not from zero, but from a random point
3. Random search nonce.
Now each of the methods is separate. For clarity, let nonce vary from 0 to 1,000,000 and let us look for a hash with three zeros
Sequential nonce from zero .
In this case, the miner will find the hash on average for 3845 iterations, but with a probability of 61% iterations will be less. That is, Of the 100 hashes found, 61 hashes will be found faster than in 3845 iterations.
Sequential enumeration not from zero, but from a random point
In this case, the miner will find the hash on average for 3845/2 = 1923 iterations, while with a probability of 39.4% iterations will be less (I calculated this additionally). That is, out of 100 hashes, 40 will be found faster than in 1923 iterations.
Twice as fast as in the first case! This is because the random beginning, with a normal distribution, will fall on average to the center of the segment for enumeration.
Also in this method with a probability of 259/1000000 the hash will be found immediately.
Random brute force nonce.
In this case, you can never find the desired hash at all, but with a probability of 259/1000000, the hash will be found on the first try. If the random distribution is distributed normally, then the probabilities should add up, which means after 1923 iterations the probability of finding a hash will be already 50%. That is, out of 100 hashes, 50 will be found faster than in 1923 iterations.
As a result, it turns out that the first algorithm is the slowest. The third algorithm is the fastest. If I haven’t messed up anything of course ...
What u know about this?
(given the probabilistic nature of the kangaroo, this can help)
This is all about hashing, kangaroo does not use hashing anywhere in the algorithm. Kangaroo only works when the public key is known.
Start Hex Finish Hex
--keyspace 28326b5ee5b13781:28326b6bb3f29d81
--keyspace 34ccccbde61a2d01:34cccd086798cd01
--keyspace 34cccccdc0f0cd01:34cccd086798cd01
--keyspace 3ddc8bab2da2c001:3ddc9bab2da2cf01
--keyspace 3ddc8bb176f60f01:3ddc9bab2da2cf01
--keyspace 28326b5ee5b13781:28326b6bb3f29d81
--keyspace 34ccccbde61a2d01:34cccd086798cd01
--keyspace 34cccccdc0f0cd01:34cccd086798cd01
--keyspace 3ddc8bab2da2c001:3ddc9bab2da2cf01
--keyspace 3ddc8bb176f60f01:3ddc9bab2da2cf01
For my real job I am writing all the TCG and secure boot ROM firmware for a next gen SSD controller ASIC. This SSD controller ASIC happens to have a built in hardware crypto engine for AES, SHA, HMAC, RSA, ECC, etc. I was thinking I could download a special test firmware into the SSD that would use the built in hardware crypto engine to do this calculation. It would be incredibly fast. I could justify downloading it to an entire rack of SSDs during manufacturing in order to do a "burn in test" of the crypto hardware on the drive. Should be fun.
!!!!!than
(auto-translate)
Now some super secret asic boost algorithm is being heard. Who knows what about him?
Consider several ways to find a hash with a given complexity
1. Sequential nonce from zero
2. Sequential search not from zero, but from a random point
3. Random search nonce.
Now each of the methods is separate. For clarity, let nonce vary from 0 to 1,000,000 and let us look for a hash with three zeros
Sequential nonce from zero .
In this case, the miner will find the hash on average for 3845 iterations, but with a probability of 61% iterations will be less. That is, Of the 100 hashes found, 61 hashes will be found faster than in 3845 iterations.
Sequential enumeration not from zero, but from a random point
In this case, the miner will find the hash on average for 3845/2 = 1923 iterations, while with a probability of 39.4% iterations will be less (I calculated this additionally). That is, out of 100 hashes, 40 will be found faster than in 1923 iterations.
Twice as fast as in the first case! This is because the random beginning, with a normal distribution, will fall on average to the center of the segment for enumeration.
Also in this method with a probability of 259/1000000 the hash will be found immediately.
Random brute force nonce.
In this case, you can never find the desired hash at all, but with a probability of 259/1000000, the hash will be found on the first try. If the random distribution is distributed normally, then the probabilities should add up, which means after 1923 iterations the probability of finding a hash will be already 50%. That is, out of 100 hashes, 50 will be found faster than in 1923 iterations.
As a result, it turns out that the first algorithm is the slowest. The third algorithm is the fastest. If I haven’t messed up anything of course ...
and googling "Probabilistic Bitcoin Mining Method"1. Sequential nonce from zero
2. Sequential search not from zero, but from a random point
3. Random search nonce.
Now each of the methods is separate. For clarity, let nonce vary from 0 to 1,000,000 and let us look for a hash with three zeros
Sequential nonce from zero .
In this case, the miner will find the hash on average for 3845 iterations, but with a probability of 61% iterations will be less. That is, Of the 100 hashes found, 61 hashes will be found faster than in 3845 iterations.
Sequential enumeration not from zero, but from a random point
In this case, the miner will find the hash on average for 3845/2 = 1923 iterations, while with a probability of 39.4% iterations will be less (I calculated this additionally). That is, out of 100 hashes, 40 will be found faster than in 1923 iterations.
Twice as fast as in the first case! This is because the random beginning, with a normal distribution, will fall on average to the center of the segment for enumeration.
Also in this method with a probability of 259/1000000 the hash will be found immediately.
Random brute force nonce.
In this case, you can never find the desired hash at all, but with a probability of 259/1000000, the hash will be found on the first try. If the random distribution is distributed normally, then the probabilities should add up, which means after 1923 iterations the probability of finding a hash will be already 50%. That is, out of 100 hashes, 50 will be found faster than in 1923 iterations.
As a result, it turns out that the first algorithm is the slowest. The third algorithm is the fastest. If I haven’t messed up anything of course ...
What u know about this?
(given the probabilistic nature of the kangaroo, this can help)
Yes I'm using bitcrack. RX 580 89MKey / Sec
Code:
>cuBitCrack-0.30 -d 0 -t 512 -p 1024 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
[2019-08-20.06:44:00] [Info] Compression: compressed
[2019-08-20.06:44:00] [Info] Generating 16,777,216 starting points (640.0MB)
GeForce GTX 980 2059 / 8192MB | 1 target 153.59 MKey/s (1,694,498,816 total) [00:00:09]
>clBitCrack-0.30 -d 0 -t 512 -p 1024 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
[2019-08-20.05:50:09] [Info] Compression: compressed
[2019-08-20.05:50:11] [Info] Generating 16,777,216 starting points (640.0MB)
GeForce GTX 980 1024 / 8192MB | 1 target 67.72 MKey/s (671,088,640 total) [00:00:07]
>oclvanitygen64.exe -v -D 0:0 -F compressed 12345678
Device: GeForce GTX 980
Grid size: 4096x4096
[59.23 Mkey/s][total 402653184][Prob 0.0%][50% in 2.9h]
y, it sad [2019-08-20.06:44:00] [Info] Compression: compressed
[2019-08-20.06:44:00] [Info] Generating 16,777,216 starting points (640.0MB)
GeForce GTX 980 2059 / 8192MB | 1 target 153.59 MKey/s (1,694,498,816 total) [00:00:09]
>clBitCrack-0.30 -d 0 -t 512 -p 1024 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
[2019-08-20.05:50:09] [Info] Compression: compressed
[2019-08-20.05:50:11] [Info] Generating 16,777,216 starting points (640.0MB)
GeForce GTX 980 1024 / 8192MB | 1 target 67.72 MKey/s (671,088,640 total) [00:00:07]
>oclvanitygen64.exe -v -D 0:0 -F compressed 12345678
Device: GeForce GTX 980
Grid size: 4096x4096
[59.23 Mkey/s][total 402653184][Prob 0.0%][50% in 2.9h]
Just optimizing the compiler Cuda has gone a lot ahead.
Look for example: https://arxiv.org/ftp/arxiv/papers/1005/1005.2581.pdf
on the other hand... new release JohnTheRipper 1.9
https://www.openwall.com/lists/announce/2019/05/14/1
Quote
The release of the new version 1.9.0-jumbo-1 took place more than four years after the release of the previous 1.8.0-jumbo-1.
In the new version of John the Ripper, developers abandoned the CUDA architecture due to a decrease in interest in it and focused on the more portable OpenCL framework that works great on NVIDIA graphics cards.
In the new version of John the Ripper, developers abandoned the CUDA architecture due to a decrease in interest in it and focused on the more portable OpenCL framework that works great on NVIDIA graphics cards.
opencl trash? or Brichard19 need to train more? unclear
used algo?
zielar
if my memory serves me The same as the previous keys that I found (# 59, # 60, # 61) - the key was found in the BitCrack application to the developer there was no donation
if my memory serves me The same as the previous keys that I found (# 59, # 60, # 61) - the key was found in the BitCrack application to the developer there was no donation
Hi, zielar!
[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]
I will immediately provide you with a compiled build and source code edits. Also, if possible, I can make changes as you wish.
I guarantee a probable acceleration from x1.3 to x1.7.
Just publicly promise that if success, you will send 0.1btc to 1LqJ9cHPKxPXDRia4tteTJdLXnisnfHsof to brichard19 as author of bitcrack.
I think his work is not sufficiently funded, meanwhile, for a whole year this and previous topics have been alive exclusively thanks to his program.
I want to fix it. Your word will be enough, I believe you.
Until brichard19 releases an update, you will have the advantage of speed.
And your donation will thank him.
VanityGen oт BitCrack? Yes, i have too
But I don’t think you really need this dinosaur, unless you are a collector-connoisseur) a funny mistake
[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]
I will immediately provide you with a compiled build and source code edits. Also, if possible, I can make changes as you wish.
I guarantee a probable acceleration from x1.3 to x1.7.
Just publicly promise that if success, you will send 0.1btc to 1LqJ9cHPKxPXDRia4tteTJdLXnisnfHsof to brichard19 as author of bitcrack.
I think his work is not sufficiently funded, meanwhile, for a whole year this and previous topics have been alive exclusively thanks to his program.
I want to fix it. Your word will be enough, I believe you.
Until brichard19 releases an update, you will have the advantage of speed.
And your donation will thank him.
VanityGen oт BitCrack? Yes, i have too
But I don’t think you really need this dinosaur, unless you are a collector-connoisseur) a funny mistake
I meant VanitySearch in the previous post, of course.
So as not only because your version makes it much easier for me to manage my search - I also 100% completely agree with the content of your post. If not for brichard19 - it would be thin !. 100% to 100%, so it also includes the commitment to reward this person in the form of 0.1BTC regardless of value [also when the price reaches USD 50,000 / BTC].
P.S. I am glad that there are people who still trust in strangers ... and on the Internet.
I will officially confirm the value of this trust with a link to a transaction that I will perform under this commitment.
Hi, zielar!
[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]
I will immediately provide you with a compiled build and source code edits. Also, if possible, I can make changes as you wish.
I guarantee a probable acceleration from x1.3 to x1.7.
Just publicly promise that if success, you will send 0.1btc to 1LqJ9cHPKxPXDRia4tteTJdLXnisnfHsof to brichard19 as author of bitcrack.
I think his work is not sufficiently funded, meanwhile, for a whole year this and previous topics have been alive exclusively thanks to his program.
I want to fix it. Your word will be enough, I believe you.
Until brichard19 releases an update, you will have the advantage of speed.
And your donation will thank him.
VanityGen from BitCrack? Yes, i have too
But I don’t think you really need this dinosaur, unless you are a collector-connoisseur) a funny mistake
[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]
I will immediately provide you with a compiled build and source code edits. Also, if possible, I can make changes as you wish.
I guarantee a probable acceleration from x1.3 to x1.7.
Just publicly promise that if success, you will send 0.1btc to 1LqJ9cHPKxPXDRia4tteTJdLXnisnfHsof to brichard19 as author of bitcrack.
I think his work is not sufficiently funded, meanwhile, for a whole year this and previous topics have been alive exclusively thanks to his program.
I want to fix it. Your word will be enough, I believe you.
Until brichard19 releases an update, you will have the advantage of speed.
And your donation will thank him.
VanityGen from BitCrack? Yes, i have too
But I don’t think you really need this dinosaur, unless you are a collector-connoisseur) a funny mistake
will you talk to yourself in this thread?
original
The thread is for posting our results and answering questions.original
All of your posts are still in the thread. They are quoted in my answers to all of your questions.
Please go back to the thread and notice all of your posts (and all the other deleted posts) are all still there in the quotes for the answers I gave.
For you I will make an exception, since it seems to bother you so much, and will not delete your posts in the future.
Does my cleaning up my thread bother any one else? If so I will just stop doing it.
Do you now understand why I deleted your posts and if so will you delete all of your posts above where you said that you do not trust me?
BurtW-do not trust. removes all messages from your topic.
I delete posts in our thread just to keep it clean.In other words, once I quote a post and answer it then I delete the original post. Your post and the answer I gave are still in the thread.
I just think the thread stays shorter and cleaner this way.
Please remove your post here where you say you do not trust me.
I did not think this would be an issue. It is just to keep the thread clean.
Sorry about the misunderstanding.
BurtW-do not trust. removes all messages from your topic.
to prevent further fraud
I decided to publish it on github available to everyone in less than a few days
Work 6 hours a day for a few years,
maybe it will work
I do not understand your comment. The program is written and it works. I just coded it from the the description here.maybe it will work
I admit it is very slow compared to a how fast a GPU version will be. That is part of the project: getting the program to run on a GPU.
to prevent further fraud
I decided to publish it on github available to everyone in less than a few days
What do you mean by "it"? Are you planning to publish a GPU version of the algorithm? I decided to publish it on github available to everyone in less than a few days
Jump to: