The Second compressed Key Is wrong. It has to be
03469619dc9c10ce858a5359e9e948cb50d415f93f2b63490fefcc1c4013bcd284

The corresponding uncompressed key ends on the hex number f, which is decimal 15 meaning it is odd. So odd y => 03 prefix

Well, lets say I write a malicious BIP with Copyright to myself, were I propose to store the privatekeys on my private email address. Some on Bitcoin Team think it is very neat solution, and implement it. Now the Network adapts it and now I get the privatekeys. I steal now the privatekeys and make the great fire-sale. Are now the devs my accomplices? Or is my action of stealing the BitCoins the criminal act and the bitcoin devs just negligent?

Or in German law, you can not exclude any liability. So for example, you make an online lottery... you can exclude any liability by declaring that you can not sue if you not win. But you can not exclude e.g. the liability for bodily harm, even if it is not in the possibilities to get bodily harmed by a online lottery.

Is Bitcoin money? Or is it something else? Can it be actually stolen?

And last but not least:
Who do you sue, if they(the node owners) disable the whole bitcoin network? Participation in the bitcoin network is not obligatory. So you can not sue anybody if there suddenly a 51% attack is possible and somebody is running the whole bitcoin network on his raspi with McDonalds Wifi.

@WP

What tool do you use for bruteforcing x point only search?

@apvl
You are kind of in the wrong thread if you ask about VanityBitCrack in the Kangaroo-Thread

No, as they are different principles.

BitCrack gets a list of addresses and brute forces the privatekey. This means that if we have public keys, we can convert them to addresses and then bruteforce them in BitCrack, but we have the overhead of privatekey to public key to sha256 to ripemd160.
VanitySearch can as far as I know use directly the public keys so there is not that overhead, what we have in bitcrack to do the extra work of transforming the public key to the ripemd160
Kangaroo is not really bruteforcing the publickey but using a mathematical process to crack it.

So no, you can not mix them.

Please elaborate.

After you did the division twice?

Or because you only search for the xPub and thats why there are two?

Soooo

3  x 45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a = beginning of the range
then ffffffff divided by 33 + begin of the range marks the end of the range?

@ssxb
The problem is, that you say "Well I know a secret, but I wont tell you the whole secret. I just say, that when you know something everybody knows, you will understand it". And than ... nothing. Just write what your "secret" is or just let it be...

@WP
I apologize, I misread that you set the range to that small one, but you wrote clearly that you chose another range, where you clearly knew it was twice there. Still... I dont know how you determine the other range?!
Does your Pollard Rho implementation can process multiple targets at once?

@Counselor
Well, you have to know the range, were you assume the privatekey. So how do you determine that range?

How do you know to search in  D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA73xxxxxxxxxxxxxxxx?

You set the range 1:ffffffff and you get a private key D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7335FF288C

D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7335FF288C is bigger than ffffffff.

Atleast in my math world

But isnt this contradicting?
D1745D1745D1745D1745D1745D1745D06A31FA8E3252B1A53FDAAA7335FF288C is outside the range.

Would you please stop spamming ssxb?
Super annoying.

Do you have some example data? Can you provide them to me please?

Privatekey, derived pubkeys and some of their privatekeys counterparts?

I am really interested to analyze your findings.

Is according to your empirical test this range reduction valid for small ranges like 2^120 also?

And what is the actual algorithm? It is so annoying.

brainless: Check my magic numbers
me: What are those.
brainless: See this post, were is just post them without any explaination
me: lets see, what is it? check it out and search what those are... they are the divisors of N-1 Ok. Check in Wolfram Alfa, seems legit
me: What now?
brainless: You do something with them and get less keys
ssxb: You add, subtract multiply divide in some arbitrary order and get less keys.


Wow
What is the fucking algorithm? Is there some pseudocode?

But hey, he wants 0,75 BTC for a Rig. Sure...

brainless.... are you kidding me? Come with some reasonable arguments and not with conjectures.


2520 will get you stuck, but 30240 will work. Old Babylonian Astronomers knew this.

Source(s): Dude trust me

So no new knowledge 

@WP
I take a 255 bit pubkey, divide it by 33. Now I only have to search the 2^255/33 ~ 2^252  range to find the key. What a reduction.

@ssxb

Well but what is the new knowledge?

I saw that you posted before I could post. I had already invested about 20 minutes for the post and was like: "Well, it is already said, but not from everyone" and so I posted it anyway.

Also the 33 division makes sense as the distance between each point will be the mod inverse of 33 or so. Its like cutting the whole N into ranges, as mentioned before. Only problem is, that you are only getting one in the lower bruteforcable range and then can jump from that one and can determine the other 32 private keys.

And yes, you just have to multiply the privatekey times your divisor and then mod N to get the right result.

What about 2520?

2520 = 2³ * 3² * 5 * 7

2520 / 10 = 252
2520 / 9 = 280
2520 / 8 = 315
2520 / 7 = 360
2520 / 6 = 420
2520 / 5 = 504
2520 / 4 = 630
2520 / 3 = 830
2520  / 2 = 1260
2520 / 1 = 2520

Only difference is, that dividing by 8 will get you a odd number. If you want that it is even when dividing by 8, then just double 2520. So 5040 is much smaller than 30240. So why is according to you only 30240 dividable from 1 to 10? If it is even relevant as 30240 is not a divisor of N-1.

References:
https://en.wikipedia.org/wiki/Highly_composite_number
https://mrob.com/pub/math/numbers-14.html#lc5040

 

Yeah it is unprofessional to not even check Google to exclude the most obvious errors. Also the chuzpe to pressure people to calculate their pointless ideas, is unbelievable impertinent

If you search for 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E you will realize that this address is a burner address, as the publickey is not on secp256k1.