Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 329.

racminer

member

Activity: 245

Merit: 17

Quote from: holy_ship on February 28, 2019, 01:59:24 AM

Quote from: racminer on February 27, 2019, 07:46:19 AM

1 target compressed 107 Mkey/s
2.7M targets both 46 Mkey/s

OK, not stubborn, but alternatively gifted.
Do you really think that 46 vs 107 is "won't change much"?

I think we agree, we just need to ask the same question

I said "won't change much" when:
1) you compare "1 compressed target" with "2.7M compressed targets" 107 and 83 23% decrease
2) you compare "1 uncompressed target" with "2.7M many uncompressed targets" 85 and 64 25% decrease
3) you compare "1 both c & u target" with "2.7M c & u targets" 65 and 46 30% decrease

more numbers

you compare "1 compressed target" with "1M compressed targets" 107 and 90 16% decrease
you compare "1 compressed target" with "100000 compressed targets" 107 and 100 7% decrease

Thanks Wink

holy_ship

jr. member

Activity: 115

Merit: 1

Quote from: racminer on February 27, 2019, 07:46:19 AM

1 target compressed 107 Mkey/s
2.7M targets both 46 Mkey/s

OK, not stubborn, but alternatively gifted.
Do you really think that 46 vs 107 is "won't change much"?

zielar

full member

Activity: 282

Merit: 114

Quote from: racminer on February 27, 2019, 07:46:19 AM

Quote from: holy_ship on February 26, 2019, 09:30:23 PM

You, stubborn boyz, don't get simple thing: bounty is 100% compressed, so you need only -c switch.
For abandoned wallets you 100% need both -u and -c switches.
That's 2x drop.

bloom filter with thousands of addressed also cannot be free. Here you get another ~50% drop.

So, 1 address vs thousands is really around "3X difference".

Ok

We "stubborn boyz" have shown you numbers not expectations.

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:58] [Info] Compression: compressed
Ellesmere 2304/6473MB | 1 target 107.29 MKey/s (1,321,205,760 total) [00:00:10]

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:00] [Info] Compression: uncompressed
Ellesmere 2304/6473MB | 1 target 85.06 MKey/s (1,283,457,024 total) [00:00:12]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:20:27] [Info] Compression: both
Ellesmere 2304/6485MB | 1 target 64.78 MKey/s (868,220,928 total) [00:00:11]

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.03:06:54] [Info] Compression: compressed
[2019-02-26.03:08:58] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6450MB | 2749473 targets 83.47 MKey/s (4,420,641,226,752 total) [14:41:53]^C

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-27.13:34:01] [Info] Compression: uncompressed
[2019-02-27.13:34:40] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6473MB | 2749473 targets 64.28 MKey/s (2,793,406,464 total) [00:00:39]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.23:52:15] [Info] Compression: both
[2019-02-26.23:54:19] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6481MB | 2749473 targets 46.05 MKey/s (2,213,925,617,664 total) [13:21:11]

In Short: Ubuntu 16.04, Rx480 8Gb
1 target compressed 107 Mkey/s
1 target uncompressed 85 Mkey/s
1 target both 65 Mkey/s

2.7M targets compressed 83 Mkey/s
2.7M targets uncompressed 64 MKey/s
2.7M targets both 46 Mkey/s

Show us your setting (OS, gpu type) and your numbers (Mkeys/s with 1 or many targets, with -c or -c -u)
otherwise, no need to comment.

Thanks.

One more thing, about -b -t -p (to Zielar)

Default setting:
~/BitCrack/bin$ ./clBitCrack -d 1 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 16/6471MB | 1 target 48.35 MKey/s (1,997,537,280 total) [00:00:39]

My setting:
:~/BitCrack/bin$ ./clBitCrack -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 2304/6491MB | 1 target 107.70 MKey/s (868,220,928 total) [00:00:06]

racminer - I know that multiplying the value of -b x2 does not affect the result, however I found (in my case) on other cards - a setting that is definitely better. And without hiding the fact that the -p indicator I have exactly the same as you (2560), check what result will be at the setting: -b 36 -t 512 -p 2560 ... if it does not move, reduce the -p value... and share the result... :-)

netlakes

newbie

Activity: 37

Merit: 0

Quote from: racminer on February 27, 2019, 07:46:19 AM

Quote from: holy_ship on February 26, 2019, 09:30:23 PM

You, stubborn boyz, don't get simple thing: bounty is 100% compressed, so you need only -c switch.
For abandoned wallets you 100% need both -u and -c switches.
That's 2x drop.

bloom filter with thousands of addressed also cannot be free. Here you get another ~50% drop.

So, 1 address vs thousands is really around "3X difference".

Ok

We "stubborn boyz" have shown you numbers not expectations.

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:58] [Info] Compression: compressed
Ellesmere 2304/6473MB | 1 target 107.29 MKey/s (1,321,205,760 total) [00:00:10]

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:00] [Info] Compression: uncompressed
Ellesmere 2304/6473MB | 1 target 85.06 MKey/s (1,283,457,024 total) [00:00:12]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:20:27] [Info] Compression: both
Ellesmere 2304/6485MB | 1 target 64.78 MKey/s (868,220,928 total) [00:00:11]

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.03:06:54] [Info] Compression: compressed
[2019-02-26.03:08:58] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6450MB | 2749473 targets 83.47 MKey/s (4,420,641,226,752 total) [14:41:53]^C

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-27.13:34:01] [Info] Compression: uncompressed
[2019-02-27.13:34:40] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6473MB | 2749473 targets 64.28 MKey/s (2,793,406,464 total) [00:00:39]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.23:52:15] [Info] Compression: both
[2019-02-26.23:54:19] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6481MB | 2749473 targets 46.05 MKey/s (2,213,925,617,664 total) [13:21:11]

In Short: Ubuntu 16.04, Rx480 8Gb
1 target compressed 107 Mkey/s
1 target uncompressed 85 Mkey/s
1 target both 65 Mkey/s

2.7M targets compressed 83 Mkey/s
2.7M targets uncompressed 64 MKey/s
2.7M targets both 46 Mkey/s

Show us your setting (OS, gpu type) and your numbers (Mkeys/s with 1 or many targets, with -c or -c -u)
otherwise, no need to comment.

Thanks.

One more thing, about -b -t -p (to Zielar)

Default setting:
~/BitCrack/bin$ ./clBitCrack -d 1 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 16/6471MB | 1 target 48.35 MKey/s (1,997,537,280 total) [00:00:39]

My setting:
:~/BitCrack/bin$ ./clBitCrack -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 2304/6491MB | 1 target 107.70 MKey/s (868,220,928 total) [00:00:06]

Nice!!!

racminer

member

Activity: 245

Merit: 17

Quote from: holy_ship on February 26, 2019, 09:30:23 PM

You, stubborn boyz, don't get simple thing: bounty is 100% compressed, so you need only -c switch.
For abandoned wallets you 100% need both -u and -c switches.
That's 2x drop.

bloom filter with thousands of addressed also cannot be free. Here you get another ~50% drop.

So, 1 address vs thousands is really around "3X difference".

Ok

We "stubborn boyz" have shown you numbers not expectations.

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:58] [Info] Compression: compressed
Ellesmere 2304/6473MB | 1 target 107.29 MKey/s (1,321,205,760 total) [00:00:10]

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:22:00] [Info] Compression: uncompressed
Ellesmere 2304/6473MB | 1 target 85.06 MKey/s (1,283,457,024 total) [00:00:12]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
[2019-02-27.13:20:27] [Info] Compression: both
Ellesmere 2304/6485MB | 1 target 64.78 MKey/s (868,220,928 total) [00:00:11]

./clBitCrack -c -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.03:06:54] [Info] Compression: compressed
[2019-02-26.03:08:58] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6450MB | 2749473 targets 83.47 MKey/s (4,420,641,226,752 total) [14:41:53]^C

./clBitCrack -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-27.13:34:01] [Info] Compression: uncompressed
[2019-02-27.13:34:40] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6473MB | 2749473 targets 64.28 MKey/s (2,793,406,464 total) [00:00:39]

./clBitCrack -c -u -d 1 -b 72 -t 256 -p 2048 -o res.txt -i btc.txt
[2019-02-26.23:52:15] [Info] Compression: both
[2019-02-26.23:54:19] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere 2368/6481MB | 2749473 targets 46.05 MKey/s (2,213,925,617,664 total) [13:21:11]

In Short: Ubuntu 16.04, Rx480 8Gb
1 target compressed 107 Mkey/s
1 target uncompressed 85 Mkey/s
1 target both 65 Mkey/s

2.7M targets compressed 83 Mkey/s
2.7M targets uncompressed 64 MKey/s
2.7M targets both 46 Mkey/s

Show us your setting (OS, gpu type) and your numbers (Mkeys/s with 1 or many targets, with -c or -c -u)
otherwise, no need to comment.

Thanks.

One more thing, about -b -t -p (to Zielar)

Default setting:
~/BitCrack/bin$ ./clBitCrack -d 1 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 16/6471MB | 1 target 48.35 MKey/s (1,997,537,280 total) [00:00:39]

My setting:
:~/BitCrack/bin$ ./clBitCrack -d 1 -b 72 -t 256 -p 2048 15VF3MsCzjHmFQ3wK3SMrTEBTmFY8zhJnU
Ellesmere 2304/6491MB | 1 target 107.70 MKey/s (868,220,928 total) [00:00:06]

holy_ship

jr. member

Activity: 115

Merit: 1

You, stubborn boyz, don't get simple thing: bounty is 100% compressed, so you need only -c switch.
For abandoned wallets you 100% need both -u and -c switches.
That's 2x drop.

bloom filter with thousands of addressed also cannot be free. Here you get another ~50% drop.

So, 1 address vs thousands is really around "3X difference".

zielar

full member

Activity: 282

Merit: 114

Quote from: holy_ship on February 25, 2019, 09:53:15 PM

Quote from: racminer on February 25, 2019, 04:45:56 AM

Thank you for you very competent comments.

Welcome.

Quote from: racminer on February 25, 2019, 04:45:56 AM

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

I am not fully accept that... B is block's number. in many apps you can read CU value (compute units) which is -b the best value.

racminer

member

Activity: 245

Merit: 17

Quote from: netlakes on February 26, 2019, 11:18:27 AM

Quote from: racminer on February 26, 2019, 11:05:00 AM

Quote from: holy_ship on February 25, 2019, 09:53:15 PM

Quote from: racminer on February 25, 2019, 04:45:56 AM

Thank you for you very competent comments.

Welcome.

Quote from: racminer on February 25, 2019, 04:45:56 AM

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

my rx480 4gb config:

-c -b 72 -t 256 -p 2048

5,000,000 addresses = 85Mkey/s

-c -u -b 72 -t 256 -p 2048

5,000,000 addresses = 42Mkey/s

Indeed, that's what I have.
holy_ship does not seem to agree.

netlakes

newbie

Activity: 37

Merit: 0

Quote from: racminer on February 26, 2019, 11:05:00 AM

Quote from: holy_ship on February 25, 2019, 09:53:15 PM

Quote from: racminer on February 25, 2019, 04:45:56 AM

Thank you for you very competent comments.

Welcome.

Quote from: racminer on February 25, 2019, 04:45:56 AM

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

my rx480 4gb config:

-c -b 72 -t 256 -p 2048

5,000,000 addresses = 85Mkey/s

-c -u -b 72 -t 256 -p 2048

5,000,000 addresses = 42Mkey/s

racminer

member

Activity: 245

Merit: 17

Quote from: holy_ship on February 25, 2019, 09:53:15 PM

Quote from: racminer on February 25, 2019, 04:45:56 AM

Thank you for you very competent comments.

Welcome.

Quote from: racminer on February 25, 2019, 04:45:56 AM

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

holy_ship

jr. member

Activity: 115

Merit: 1

Quote from: racminer on February 25, 2019, 04:45:56 AM

Thank you for you very competent comments.

Welcome.

Quote from: racminer on February 25, 2019, 04:45:56 AM

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

pikachunakapika

jr. member

Activity: 34

Merit: 5

Quote from: brainless on February 25, 2019, 12:02:25 PM

i have tested it with higher values too, need to of optimization
i created issues inside your pull of bitcrack and modified for random, check that too

Thank your for testing!

brainless

member

Activity: 348

Merit: 34

Quote from: pikachunakapika on February 25, 2019, 11:35:08 AM

Quote from: brainless on February 25, 2019, 08:57:49 AM

Quote from: zielar on February 25, 2019, 05:34:32 AM

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

You are getting false positives which is normal with this version of the code and your big hashtable.
Read recent posts of arulbero in this thread to understand why.
Simplified said there are collisions in the hashtable.

Code:

typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;

Here uint32_t x; is to small too prevent collisions.
If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive.

i have tested it with higher values too, need to of optimization
i created issues inside your pull of bitcrack and modified for random, check that too

pikachunakapika

jr. member

Activity: 34

Merit: 5

Quote from: brainless on February 25, 2019, 08:57:49 AM

Quote from: zielar on February 25, 2019, 05:34:32 AM

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

You are getting false positives which is normal with this version of the code and your big hashtable.
Read recent posts of arulbero in this thread to understand why.
Simplified said there are collisions in the hashtable.

Code:

typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;

Here uint32_t x; is to small too prevent collisions.
If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive.

racminer

member

Activity: 245

Merit: 17

Quote from: netlakes on February 25, 2019, 10:30:30 AM

hello guys, today this wallet appeared 1JMT8uyrnVAvkhiexbTL9dyyMwTqjKygU9
in my search

take a look at the transactions, can anyone explain what this is?

https://bitcoin.stackexchange.com/questions/64504/what-does-unable-to-decode-output-address-mean

netlakes

newbie

Activity: 37

Merit: 0

hello guys, today this wallet appeared 1JMT8uyrnVAvkhiexbTL9dyyMwTqjKygU9
in my search

take a look at the transactions, can anyone explain what this is?

yoloyet

newbie

Activity: 63

Merit: 0

is this still on going? this might offer some hours of having fun

brainless

member

Activity: 348

Merit: 34

Quote from: zielar on February 25, 2019, 05:34:32 AM

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

stalker00075

newbie

Activity: 54

Merit: 0

FUCK you make me nervously smoking aside with my 350Mkey/s

racminer

member

Activity: 245

Merit: 17

Quote from: zielar on February 25, 2019, 05:34:32 AM

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

Good points.

Waw!!! 288 000 000 000 Mkey/s ...

Maybe you mean 288 000 000 000 key/s

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 329. (Read 253594 times)