Topic: the dilemma of division in ECC-secp256k1 (Read 782 times)

pk_decimal= 109976111913671942994782547932288341104394192011282789345793555308339223784117
pub=03eeb9365c34d51c83060dd2fe898b8726143d86670c1f30e9cfc3d58f82973af9



pk is not for pub !

pub for pk is:

0495d913294063c97c009936a50efddbdabea78a91043c46fef15b5a93f2f9aa8b2e7234e4e7f81 467c5a06c85f2879c3e73f63f012185d313fb00a4d4041353f1

and

./km 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 / 10000000000000000000000000000000000000000000000000000000000000000
Result: 03eeb9365c34d51c83060dd2fe898b8726143d86670c1f30e9cfc3d58f82973af9



0279b....  is a  pubkey of priv 1

this is precision, and mistake in this

1754225779965324 / 7476542256 =


234630.624679147670425471611218029341396662869339101612642580910198763945834375 0180765379733580415679255675432646147007879627504642568557964691318665637459349 09620070767643903


I not undertand what is your task. But if you get G as a 1/ 7476542256 you have no problem with find point

of
234630.624679147670425471611218029341396662869339101612642580910198763945834375 0180765379733580415679255675432646147007879627504642568557964691318665637459349 09620070767643903


Then you div point of  234630.624679147670425471611218029341396662869339101612642580910198763945834375 0180765379733580415679255675432646147007879627504642568557964691318665637459349 09620070767643903 to 1/ 7476542256 , you aways take int without float part.


ecctools of iceland is good for this calcs

It depends if something is long or short. For example, when I digged deeper into elliptic curves, I decided to not post all curves from the smallest to the 256-bit one, in some topic on bitcointalk. I decided to do that on GitHub, because it is too much content, and it is better to give someone a link, than to post all details on forum.

So, if you want to post something, that is too long to be posted here, then use other tools. Use pastebin, GitHub, or whatever, and just share a link. And if things are even more focused on your tools, then you can have some discussion in other places, for example on GitHub, inside some Pull Requests.

You know, bitcointalk is not your personal blog, and after reaching the point, where things are more related to your work, than to public discussions, it is usually a good idea to bring the whole discussion to your social media, and keep it there, leaving only links for someone, who may be interested, than posting everything here.

It is not a crime. If it would be, then all topics related to puzzles would be taken down, because they contain a lot of details about elliptic curves, and they are sometimes too long, but they stay on forum, and those topics are not taken down for some reason.

For example: this forum is not GitHub. If you have a long piece of code, then make your own repo, and give a link to that, instead of posting every file on bitcointalk. It is also more convenient to do "git clone" than to copy-paste each file manually.

Well, sometimes things are too stupid to continue the discussion. In that case, usually I leave it as it is, and switch to other things. And then, I come back, when I can analyze them peacefully, and reply to something that is worth it, and ignore the rest.

But yes, forum is for discussion, not for posting every code change you can think about. So yes, for example Core developers moved from forum to other places, not because they don't like the forum, but because other tools like GitHub are more convenient for their purposes.

Disclaimer, that noob Legends_Never_Die is my alt I wanted to use to ask things I didn't know, or forgot.

---

@mc, are you interested for more discoveries? You remember when we could divide by 47 and multiply by 34 to get results? Now try 474747 and 343434, interestingly you will get the same results, and can be used for large numbers. So you just need to find the right combination.

---

@mods, is it Ok to post in public about curve related stuff or do we need to do it privately? I believe in the spirit of transparency that's why I do everything here, if posting here is considered a crime or trolling, let me know so I stop.

Now I know why everyone left this forum.

decimal

python mod N


python div


1/10000000000000000000000000000000000000000000000000000000000000000 =
0.0000000000000000000000000000000000000000000000000000000000000001 =


pk_decimal= 109976111913671942994782547932288341104394192011282789345793555308339223784117
pub=03eeb9365c34d51c83060dd2fe898b8726143d86670c1f30e9cfc3d58f82973af9

You would only need a known decimal.

If you did this with divisions with decimals, for example, dividing by 2, at 0.5(N/2) you would know where to stop. Therefore you just have to find a large divisor that returns a known decimal.

But how in pubkeys you can separate float? how you know where is correct operation and where not? thats why i told that is usless with pubkeys

if you have for example:
target= 14688653357788537

and you want to divide by X:
X=3576434789998

target/X= 4107.0658967045645844960056238489

To reduce to decimals, you just have to subtract X and divide sequentially.

a=target-X   =14685076922998539

a.1= a/X      = 4106.0658967045645844960056238489

b=a-X          =14681500488208541

b.1= b/X      =4105.0658967045645844960056238489

If you continue sequentially you will arrive to

235675266751 / 3576434789998 =  0,0658967045645844960056238489

All results will get the same decimals, until negative (when target is less than X).

235675266751 -3576434789998 = -3340759523247

-3340759523247 / 3576434789998 = -0,93410329543541550399437615106299



Seeing the decimals is easy, but you must do it the way I explain, to reach the objective (in ecc with pubkeys).

But all this not suitable for pubkeys

I think he just got it out of his sleeves, after all cryptography is something which you could consider as magic if you know nothing about the math equations behind it, I thought there could be some actual magics involved at first, but now I just know it's not magic.
If you are interested to learn more about such divisions, first divide your target by any number, then divide 1 by the same number, and then keep multiplying the result of 1 being divided until you see a similar fraction as the fraction resulted from your first division.

Just a simple example,
97/5 = 19.4
1/5 = 0.2
0.2 * 2 = 0.4
0.4 - 19.4 = 19.

just mul rest to a divider

.8153570612637194174713249666 * 35789976533256789

I have came back to this thread and something confused me a little:

I have asked myself, how did @mcdouglasx came to this magic number, that when divided it results to the exact decimal value that the 3765.8153570612637194174713249666 had? I am not that newbie at math, but i really couldn't find it out, lol. Maybe I'm today not thinking good, i apologize.

Those keys are in decimal, you have to convert them to hex :
I wonder if you are really a puzzle hunter, what are you even doing btw, regarding solving a puzzle? I thought last year I told you to ask anything you want, but seems you rather stay idly by and let others claim the prize!

This is very nice example ! But i think there are some errors by your calculations. The "3765" Key doesnt represents the public key above, that you have mentioned. Or am i wrong?

Now here is the important part, how many keys will result in the fraction above when divided and by what? You could divide trillion trillion different numbers by trillion trillion other different numbers and get the same result. So that's not going to work, however there is something else to think about, have you started to divide by 2, 3, 4, 5 etc by iterating through different values? You can try dividing this  134778443257800664321  by e.g, 333, then add 1 to it and divide by 333, so if the last digit of your number is 1, try all from 0 to 9, then compare the hex representations mod n, after that change the second digit from right, do the same, you could also change all the digits one by one and then divide to see what big changes you can detect in the results.

For instance, when you divide by a 1 digit number, you will only notice the resulting hex changes it's starting character, which is obvious. Maybe the best thing to do is to divide n and focus on that, then subtract 1 at a time from n then keep dividing, you can only understand things when you see the results in hex, decimal won't be too much of help, unless your brain can handle it.

You can, but your results will be with exponential increase, if there is a trick it will probably be focused on decimals.
For example:




edit

Since you don't know the key you are dividing, you will only get public keys as results, so how can you guess if the result is correct or not? When you are using -1 divide by 2, there are 50-50 chances of each division to be correct because there are 5 odd and 5 even numbers.
For example, target = 99, now you sub 1 to get 98, then divide 98/2 = 49, 49-1 = 48/2 = 24, 24-1 = 23/2 = 11.5 game over.
Unless you do this 99/2 = 49.5, 98/2 = 49, now if you subtract 1 from 49.5 you won't get 48.5 in EC, you'd get half of n+48.  But your other division result which is 49, you can divide that as well as it's -1, which would be 49/2 = 24.5, 48/2 = 24, then you can continue with 24.5/2 = game over, 24-1 = 23/2 = 11.5 game over, 24/2 = 12. 12-1 = 11/2 = 5.5 game over, 12/2 = 6, 6-1 = 5/2 = 2.5 game over, 6/2 = 3, 3/2 = 1.5 game over, 3-1 = 2/2 = 0 you just won.

But can you detect which one of the results were game over or not when you are dividing a key in 2^130 key space without knowing the key? If you can do that, you win the game.😉

yes, for divide to 2 need sybsract 1,2 ana divide 2,2 one of pub will be without float

but this is real hard, most of time is waste of time, because needs divide 2**130  to 2**70 for get 2**60 pubkeya one of them will be 2**60 etc

How about we just try dividing the public key multiple times with multiple different numbers so in the end we can at least get a divided result of a new pubkey that is non float division?

34 give nothing

.72340 is a 34 /17

226918604442 - 226918604441 = 1  =( pbkey + any nummb ) - bupkey - n +1 = 1, so imposible to identity of axact divide without float part
=