Topic: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== - page 20. (Read 54326 times)

New information, investigate it to find #125, God willing.

Subtract this from #125 (you should convert it to whatever your calculator accepts, note, if #125 public key is e.g. 125 and the below key is 5, I don't mean to subtract 5 from 125, that could result invalid public key, so do subtract the public key of the key I gave you from #125 public key)
000000000000000000000000000000000cfbcda3ac10c9714fbcda3ac10c9700

Then tell me what you see.

Is this what you see?
0229ec62f37968906686bfad34ad5fdd9008fe187d868c0c4f9de1055b3062f00e

Now

Subtract this from 2^125
000000000000000000000000000000000cfbcda3ac10c9714fbcda3ac10c9700

Is this what you see?
000000000000000000000000000000001304325c53ef368eb04325c53ef36900

The relation of above keys with #125 is the same relation of #125 and 2^125.

If you managed to solve #125, I'd like half of it, thanks.😉

You really need to understand EC keys converted to private keys. How it is not reversible without a massive amount of computing power. Power that we don't have today, with even just the public key. The public key is hashed from the EC key and is not very simply hashed back to EC. From that hash the address is created. The hash will be completely different if 1 digit is changed. Sure if you have the EC key its easy. This is why Bitcoin is secure. 1 way conversion to a public key that cannot be converted back to a private key, the private key is derived from the base EC key.

We are trying the find the EC key that has been put into reach because of the ton of zero's in front of the EC key, making the operation simpler but still difficuilt.

If you want to play around with EC keys and double hashing for keys read up and run libbitcoin tools. BX will be eye opening.
https://github.com/libbitcoin/libbitcoin-explorer/wiki/Download-BX
https://github.com/libbitcoin/libbitcoin-system/wiki/Altcoin-Version-Mappings#bip44-altcoin-version-mapping-table

bx ec-to-wif 0000000000000000000000000000000000000000000000000000000000000001
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn

bx ec-to-wif -u 0000000000000000000000000000000000000000000000000000000000000001
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf

bx ec-to-public 0000000000000000000000000000000000000000000000000000000000000001
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

bx ec-to-public -u 0000000000000000000000000000000000000000000000000000000000000001
0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

bx ec-to-address 0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm

bx ec-to-address 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH

bx ec-to-address 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81791 ----- I have only changed the 8 of the compressed key to a 1 and look at the address change.
17BJTzgM7rGctc3Hdi8L87fvqtkD7VpdzP

That was just one example showing compressed and uncompressed public keys being converted to addresses.

Good luck to you too, man.

Sorry man, but you are getting confuse:

Private key #65 = 00000000000000000000000000000000000000000000001a838b13505b26867
Public key #65 = 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

On the second point you are talking about, what you are doing is subtracting PK #65 to N, and the result is:

Private key for second point = fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8da
Public key for second point = 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

PK #65 =/= PK second point

Your confusion strive on the fact that both points share the same x-coordinate, because one is the "reflection" of the other, but the PKs are not the same; and as you can see, none of them are "negatives". There are no negative numbers on ECC.

Good luck to you too, man.

This key you call the closest one could have a size half the 2^124.
I might be wrong but somehow I can say with 50% certainty that #125 starts with 0x1c. If I'm right it could help a lot in further lowering the bit range, this has taken me more than 45 days and I am still not sure.

[/quote]


Hello digaran.
Why do you think #125 starts with 0x1c?

For example, puzzle #65:
Private key: 00000000000000000000000000000000000000000000001a838b13505b26867 =
             000000000000000000000000000000000000000000000000000000000000000 + 1a838b13505b26867
Public key: 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b


Private key: fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8da =
             fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 - 1a838b13505b26867
Public key: 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

As you can see, the key is the same, only in one case it is added, in the other it is subtracted.

Now do you understand?

You have "decent calculator" that is very smart and all calculations/convertions occur according to the rules that you were told about alberto and WP and other.
Between keys need to do scalar arithmetic. Between points - points arithmetic. And you can`t mix each other.
You say:
Step by step what your calculator do:
1) 0302157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159 convert to uncompressed format
x1: 02157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159
y1: 321770ea8770a82e7e72072b47494ce33c4954afab21aa7197da3745db653467

2) seeing this 000000000000000000000000000000001e739ce739cf7bdef7bdef7bdef7be0c the calculator understands that this is not a point and converts it to a point:
x2: ece9f19985af4319e3fee74a6a522b2610150288233f14533fd28159d4891d89
y2: c94acb0ddfcf37af4dd687ad43ed9457338df8d5f7ef2b51dc148d9ac6bd516b

3) after that calculator do substruct (x3,y3)=(x2,y2)-(x1,y1), substruct mean addition but with negative y coordinate (x3,y3)=(x2,y2)+(x1,p-y1)
and the result
x3: 02210ba69dd8525b3fa3941a448efaaeef905753b40f66cd95669a166f0bb1d5
y3: 0838d4b0841472ee5d82ae62913557500987cbcb8024b10c4f6c4e40871aa837
it is correct result? No!
Because you say do substract but need doing addition:
(x3,y3)=(x2,y2)+(x1,y1)
and here is result:
x3: 33709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e
y3: 2a1c304a39a77775d3579d077b6ee5e4d26fd3ec36f52ad674a9b47fdd999c48
that is equl to 0233709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e
if this all operation doing in background of "decent calculator" it is not meaning that it shouldn't be done.

Well, a few hours ago you didn't know -n and +n keys are one and the same, now you are saying I can't for example add "F" to "1" to reach "10"? (Hex)
But instead I need to add
02d7924d4f7d43ea965a465ae3095ff41131e5946f3c85f79e44adbcf8e27e080e

To
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

In order to reach
03e60fce93b59e9ec53011aabc21c23e97b2a31369b87a5ae9c44ee89e2a6dec0a

If you are not using a decent calculator, you should find one. Because it makes your job a lot easier.

@digaran:

Man, this is the last I'm going to say about the subject: You are doing the calculations wrong, like alberto said and WP repeated to you, you can't do operations on public keys and privet keys at once, you can't mix them, they are not in the same context. One makes reference to the other, but they are not in the same category (excuse my writings, English is not my native language).

To prove my point, you should use any script that manages public keys/privet keys and you will realize that you are doing it wrong.

It's not criticizing, I just want you to advise that you are wasting your time doing that kind of operations.

Good luck, man.

There is a chain of lols in this page and previous one.
Don't let the looks of private keys deceive you.

This is N

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

Now in order to find the inverse of your private key, just subtract it from N and you will have negative x coordinate of your private key. You should know whenever you generate an address, you are actually generating 4 addresses which you could use, but only can control 2 addresses with your key unless you subtract the key from N to obtain -n of your private key.

In ECC, those large private keys are just negative numbers, till you reach the middle range, meaning half of all private keys are negatives, the other half are positives.

So, as I said earlier, in order to subtract a private key from your public key, it's best to switch x coordinate and also switching the x coordinate of the result because it would be -n and as you did yesterday, subtracting something from a -n key will actually add the 2 keys together, also adding to a -n key as I said will subtract from the +n version of your key.

You should use another calculator which shows, accepts public keys with 02 and 03, this way you won't get confused as to whether you are adding or subtracting.

---

You can just multiply G by any number in one go, adding or subtracting and I'm not talking about under the hood as you like to say, but manually you can just add 2 private keys directly to have a resulting public key, though you don't have to manually convert a private key into a public key and then try math operations on them.

Also, do kangaroo and BSGS do any division? If they are not, then they are useless, if they do then again they are useless because by dividing properly, you should find a key in a much much shorter period of time.

However I'm guessing kangaroo might do division but ECC doesn't bend so easily.

---

This key you call the closest one could have a size half the 2^124.
I might be wrong but somehow I can say with 50% certainty that #125 starts with 0x1c. If I'm right it could help a lot in further lowering the bit range, this has taken me more than 45 days and I am still not sure.

---

Maybe, maybe one way to figure out if we are subtracting too much from #125, would be to start subtracting a bigger key and keep reducing it's size very carefully till we see a -n key as a result,  though because of this mod thingy it is extremely difficult to determine if the result is -n or not.

Chop chop guys, the rich and wealthy are about to use their silicon wares and grab our loot, we need to step up our game.😉

You can't convert public keys to privet keys (at least not yet). What you can do is what BSGS do: try a privet key, convert that one to public key, and see if it match the public key you are looking for; if it don't match, try the next one, and so on.
 

Well, it's amazing that even you wrote it yourself, you don't realize what your saying. As you can clearly see on your own example "0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b" and "0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b" have different privet keys, which is what I wrote, Now do you understand?

BTW, there are no privet keys 'with a minus sign "-"!'

but I'm asking for the closest private key to work with on the BSGS. I'm still learning how to convert these public keys to private keys

The closest one is 03ed01ff219ed5c1afc12d991a82e3063ddcee1fd53b46f7cad52a0d87a7112aed, it should be searched for in the 124 range.

So If I have to start from a range on BSGS according to your mathematical calculations, which key is the closest that you almost thought could have hit puzzle 125... lets search within that range on BSGS. then we can all share some funds together too.

Hello.
You apparently did not carefully read what @digaran wrote to you.
If you change #125 02 to 03, you will get the same private key as #125 but with a minus sign "-"!
The public key 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is also on the EC, but on the other hand.

For example, puzzle #65:
Private key: 00000000000000000000000000000000000000000000001a838b13505b26867
Public key: 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b


Private key: fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8da
Public key: 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b

Now do you understand?

Just stop lol. Read what he said. You can’t subtract a private key, a private key, from a public key. Yes, you have to convert the private key to a public key before subtracting it from another public key.

All those programs you are calling sissy, do math like you are doing.

Kangaroo, for the wilds, takes given pub key, subtracts or adds the distance it landed on/calculates what the input pubkey plus or minus the distance (private key) and checks if resulting pubkey starts or ends with whatever DP the user supplies. If it is a matching DP, the program keeps it in memory/stores it to a file. Now if the resulting pubkey is found by a tame, you have a match and have solved the pubkey’s private key you are looking for.

You can supply/run as many ranges as you want to. It’s not limited to one range.

The thing is that the "x" coordinate of #125 is: 33709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e; so I don't see how do you add "F" to 03 x coordinate of #125. Not only that, but if you switch "02" to "03" on a public key, you are talking about a very different privet key, so 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is no longer #125.

And BSGS don't use dp, it actually works in a sequential manner, deterministic, and not probabilistic like Kangaroo.

Thanks anyway man, but I think you should re-learn ECC, I can see you are confused on how it works.
Cheers.

I didn't expect from you, of course you can add or subtract private keys, don't you know public keys are just smoke and mirror, they simply represent private keys.  Maybe you don't have a calculator that could do that, tell me, is key subtracter doing the conversion first before operation? A week ago I encountered an anomaly, where I had to add or subtract a different key from my target to find a key, I still have the keys on my laptop, I might find them and show what I mean.

---

 
Switch x coordinate of that key and try again, remember whenever you have a private key, try to directly add or subtract with it for less confusion.

This way you should always change x coordinate of the result, because for example if you change the x of #125 from 02 to 03 in order to subtract something from it, the result could be -n key if the key you are trying to subtract from it is smaller than #125.

E.g. I subtracted "F" (15 decimal) from #125 by adding F to 03 x coordinate of #125, therefore the result is

03bb7d0fd320386226ff713108a743b3d2885e9f77f17da6654f40ae2a712af5d7

Now if you try to add anything to it, you'd be further subtracting from the puzzle key, turn 03 into 02 and add F to it to reach #125.

Now this key

0302157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159

Is actually -n so you need to add the key above to it in order to subtract from it, now in ECC, subtracting a small key from a greater key or vice versa has the same result, just different x coordinate.

You could try to understand this by using a normal calculator, subtract 30 from 10, you will get -20.

No doubt, but they are not dynamic, they search user input range and can't change the range of search. Is BSGS doing any + & - ? Or it just randomly jumps up and down to find a dp?