Your calculations of dx, dy and c are correct.
However while calculating the rx you made a simple arithmetical mistake - you should deduct step by step, but not make the last deduction first and later deduct the result from the first part. I marked by red the wrong part of your calculation - you changed the sign of px:

instead of rx = c^2 – px – qx you calculated rx = c^2 + px – qx (wrong!!)

Your calculation should be the following:

rx = 23578750110654438173404407907450265080473019639451825850605815020978465167024^2 -
89565891926547004231252920425935692360644145829622209833684329913297188986597-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 25759636913902563110438328477658084082469757293658084474899962813078412260632 -
89565891926547004231252920425935692360644145829622209833684329913297188986597-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 51985834224671754302756393060410299575095596129676438680673216907690057945698-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 112711660439710606056748659173929673102114977341539408544630613555209775888121

PS. You can also calculate in your way, however instead of deducting you should should apply the addition to last 2 decimals deducted from the c*c. This is the possible way as well:
rx = c^2 – px – qx = rx = c^2 – (px + qx)
Keep in mind that as you combined the last 2 decimals, you should add them first and later deduct from the 1st part}. In general, you mistake is simple math arithmetical. Just be careful with the calculation.

Your calculations of dx, dy and c are correct.
However while calculating the rx you made a simple arithmetical mistake - you should deduct step by step, but not make the last deduction first and later deduct the result from the first part. I marked by red the wrong part of your calculation - you changed the sign of px:

instead of rx = c^2 – px – qx you calculated rx = c^2 + px – qx (wrong!!)

Your calculation should be the following:

rx = 23578750110654438173404407907450265080473019639451825850605815020978465167024^2 -
89565891926547004231252920425935692360644145829622209833684329913297188986597-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 25759636913902563110438328477658084082469757293658084474899962813078412260632 -
89565891926547004231252920425935692360644145829622209833684329913297188986597-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 51985834224671754302756393060410299575095596129676438680673216907690057945698-
55066263022277343669578718895168534326250603453777594175500187360389116729240

rx = 112711660439710606056748659173929673102114977341539408544630613555209775888121

PS. You can also calculate in your way, however instead of deducting you should should apply the addition to last 2 decimals deducted from the c*c. This is the possible way as well:
rx = c^2 – px – qx = rx = c^2 – (px + qx)
Keep in mind that as you combined the last 2 decimals, you should add them first and later deduct from the 1st part}. In general, you mistake is simple math arithmetical. Just be careful with the calculation.

Why do not you examine the messages above? There are two different formulas: one for duplication and another for addition.
To be honest your messages are very hard to read. It could be more helpful for you if you can ask the specific question you do not understand or have issues with.

It's both the same in BASE16.
The first one is public key with prefix ready for processing while the second has 0x prefix to tell that it's hexadecimal but you can tell that easily by looking at the symbols.

You can easily convert them if you want.
Just use whatever works best for you 

I still don't know what you are trying to do exactly.

What do you want to do with it ?
You can turn it into uncompressed public key:

publicKey = '04' + X + Y
publicKey = 04f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9388f7b0f632de 8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672

Or turn it into a even compressed public key:
publicKey = '02' + X
publicKey = 02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9

Or turn it into a odd compressed public key:
publicKey = '03' + X
publicKey = 03f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9

One of the last two is invalid.
You have to look at the least significant bit of Y to see if its odd or even.

Y = 0x388F7B0F632DE8140FE337E62A37F3566500A99934C2231B6CB9FD7584B8E672
Y = 0b11100010001111011110110000111101100011001011011110100000010100000011111110001 1001101111110011000101010001101111111001101010110011001010000000010101001100110 0100110100110000100010001100011011011011001011100111111101011101011000010010111 0001110011001110010
The last bit is even so it's '02'

You can also convert it to WIF:

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB1FQ8BZ uncompressed

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S compressed

And you can calculate various addresses but that is far past private to pubkey  

Private key 3 is 3 * G

Add the Generator 3 times.

0x02F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9

Point 1 {x: 55066263022277343669578718895168534326250603453777594175500187360389116729240n,
            y: 32670510020758816978083085130507043184471273380659243275938904335757337482424n}

X:  0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Y:  0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

Point 2 {x: 89565891926547004231252920425935692360644145829622209833684329913297188986597n,
            y: 12158399299693830322967808612713398636155367887041628176798871954788371653930n}

X:  0xc6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
Y:  0x1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

Point 3 {x: 112711660439710606056748659173929673102114977341539408544630613555209775888121n,
            y: 25583027980570883691656905877401976406448868254816295069919888960541586679410n}

X:  0xf9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9
Y:  0x388f7b0f632de8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672

We must not forget that there are two formulas
The one you used to find the point corresponding to the private key: 2 (or rather 0000000000000000000000000000000000000000000000000000000000000002 to be more precise) it is Duplication of points.
You did it in your example with the base point--> 1 + 1 =2  (but that could be another point)
To go now with 3 we need to do --> 2 + 1 = 3 (we have now 2 différents points and we can't doubling them)

For that you need to use the second formula:

modulo = 115792089237316195423570985008687907853269984665640564039457584007908834671663
Px = 89565891926547004231252920425935692360644145829622209833684329913297188986597 (x coordinate point 2)
Py = 12158399299693830322967808612713398636155367887041628176798871954788371653930 (y coordinate point 2)
Qx = 55066263022277343669578718895168534326250603453777594175500187360389116729240 (x coordinate point 1) not because it is the base point, just because it is the point n°1
Qy = 32670510020758816978083085130507043184471273380659243275938904335757337482424 (y coordinate point 1)

dx = (Qx - Px) % modulo             --> 34499628904269660561674201530767158034393542375844615658184142552908072257357
dy = (Qy - Py) % modulo             --> 95279978516251208768455708490894263304954079172022948940317551626939868843169
c = dy * invert(dx) % modulo       --> 23578750110654438173404407907450265080473019639451825850605815020978465167024
Rx = (c*c - Px - Qx) % modulo     --> 112711660439710606056748659173929673102114977341539408544630613555209775888121 (x coordinate of point (2+1 =3)
Ry = (c*(Px - Rx) - Py) % modulo --> 25583027980570883691656905877401976406448868254816295069919888960541586679410   (y coordinate of point (2+1 =3)

Can't explain better

If the formula is always the same, All public keys will also always be the same! "Where am I wrong?

(dx, dy, c, R.x, R.y, Q.x Q.y, P.x, P.y)Can someone explain to me what are this?

I think Rx and Ry are the coordinates of the public key, right?

If the formula is always the same, All public keys will also always be the same! "Where am I wrong?

(dx, dy, c, R.x, R.y, Q.x Q.y, P.x, P.y)Can someone explain to me what are this?

I think Rx and Ry are the coordinates of the public key, right?

No that's not actually going to happen. Because this is just one integer public key, but in reality there are more integer in your private key. No scripts can deduce the private keys of someone. Even if anyone wants to do this, he/she needs a quantum computer with a minimum of 1000 qubits to expose any private key from any algorithm. In this current time, only IBM has 50 qubits of a quantum computer and Google (cooperating with NASA) has 53 qubits of quantum computer. Thought D-wave have 2000 qubits of quantum computer, but that's used only for optimization not for general purpose. So, it's will take more time to break bitcoin or other crypto-currencies private key. Also by the time passed, there will be a solution for it too. 

Wait a minute, so are you guys suggesting that you can actually calculate or deduce the private keys of someone by just looking at the public key? I'm lost maybe a bit of clarification would help. Or I am not getting that the OP is trying to say.

You can read this book, Mastering Bitcoin, of Andreas M. Antonopoulos, and the chapter 4 is what you need

Chapter 4: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc

If you want to doule point P in order to receive R = P + P, you should make the following:

c = 3*P.x*Px*invert(2*P.y) % modulo
R.x = (c*c - 2*P.x) % modulo
R.y = (c*(P.x - R.x) - P.y) % modulo

modulo = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F

For your case with P = G = Point (Gx, Gy) where:
Gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

We have the following:
invert(2*P.y) = 0xb7e31a064ed74d314de79011c5f0a46ac155602353dc3d340fbeaeec9767a6a6
c = 0xcb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1
R.x = (c*c - 2*Gx) % modulo = 0xc6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
R.y = 0x1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

So we have R.x and R.y of the public key 2G = G + G (public key for private key = 2), and it is written in compressed format like:
02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5

If you want to doule point P in order to receive R = P + P, you should make the following:

c = 3*P.x*Px*invert(2*P.y) % modulo
R.x = (c*c - 2*P.x) % modulo
R.y = (c*(P.x - R.x) - P.y) % modulo

modulo = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F

For your case with P = G = Point (Gx, Gy) where:
Gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

We have the following:
invert(2*P.y) = 0xb7e31a064ed74d314de79011c5f0a46ac155602353dc3d340fbeaeec9767a6a6
c = 0xcb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1
R.x = (c*c - 2*Gx) % modulo = 0xc6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
R.y = 0x1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

So we have R.x and R.y of the public key 2G = G + G (public key for private key = 2), and it is written in compressed format like:
02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5

It does not work in this way.

Keep in mind main thing: private key is a number (just integer), but public key is a point with x and y coordinates.
So you in your example public key was not correct for private key 1.

For private key 1 the public key is:
0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

where 04 is a prefix for uncompressed key, green part is X-coordinate and blue part is Y-coordinate.

The compressed key contains only X coordinate with the prefix 02/03 (02 for Y even, and 03 for Y odd), because Y could be received from the formula y^2 = x^3 + 7, so no need to keep Y.
The compressed key so will be:
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

In your example you wrote only X coordinate for public key, it was not correct. Prefix 02 should also be there in order to know both coordinates.

Also, you should know that there is a basis point which was determined for elliptic curve selected for bitcoin. Basis point is usually written as G, and has coordinates:
Thanks for the answer. I will correct my question!
Gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

Now the public key for every pk is pk*G, so for 1 public key 1*G - actually the G basis point itself.

For pk=2 the public key is 2*G = G + G, so you should perform scalar addition for basis point with itself (you hsould use poin doubling).
For pk=3 you just add the publik key for pk=2 with basis point G
And so on

For more details have a look at parrt 4 of this reading:
https://pdfslide.net/documents/introduction-to-bitcoin-and-ecdsa.html

Only negative jumps? I would try with positive/negative jumps and a greater average (my sensation)
To me it looks promising. 1.50sqrt(N) would be amazing!
Another thing to pay attention to is: when we translate our interval, we have only 2^(n-1) x-coordinates, and then half DP. For the tuning it's like we worked in a 2^(n-1) space.


I was thinking another thing,
if you want to overcome/avoid the brownian-motion tuning problem,

go back and put together

1) the linearity (and therefore the simplicity) of the classic approach (that you used in the release 1.3)
2) the power of the symmetry

Exploiting the symmetry means that we use equivalence classes to increase the probability of a collision (same number of tries, half 'points'); in our case, given a point P(x,y), 'x' decides the width of the jump and 'y' only the direction.
In the secp256k1 there are 2 points that share the same 'x', (x,y) and (x,-y).

In a interval of consecutive points, all x-coordinates are different, but if we move the interval like we did it becomes symmetric.

The drawback of our approach is that the kangaroo, instead of going in only one direction, keep going back and forth, creating many loops. Besides, not only we don't know where a wild kangaroo is (obviously we don't know its position-private key), but we don't control even the direction of its motion (and often it comes out from the interval)


But this curve has another symmetry that respects the linearity (unlike the negative map that overturns the interval and the kangaroo algorithm): endomorphism.

There are 3 points with the same 'y' , that means that this curve has about 2^256 points and
 
1) 2^256 / 2 different x-coordinates
2) 2^256 / 3 different y-coordinates

Why don't we use the symmetry that mantains the linearity of the interval?

We can work on the y-coordinates, and a jump should be depend on 'y' and not on 'x'.
We set equivalence classes where [P] = {P, Q, R} if and only if  yP = yQ = yR

What is the relation between the private key of these points P, Q, R?

If P=k*G, then Q=k*lambda*G and R =k*lambda^2*G (endomorphism)
and P=(x,y) -> Q=(beta*x, y) -> R=(beta^2*x,y)

observation:

if P=k*G, i.e. k is the private key of P respect of the generator G, then
lambda*P = k*lambda*G, i.e. the private key of P'=lambda*P respect of the generator G'=lambda*G is always k.

In other words, if we know that k lies in [a,b], resolving the problem P=k*G is equivalent to resolve the problem P'=k*G'
The interval is the same (from the scalar's point of view) but there are actually 3 different intervals of points. They are all consecutive from a different generator's point of view:

           point                                scalar
[a*G,   (a+1)*G, ....,  b*G]     <-> [a,b]   interval 1
[a*G',  (a+1)*G', ....,  b*G']    <-> [a,b]   interval 2  where G'=lambda*G
[a*G'', (a+1)*G'', ...., b*G'']   <-> [a,b]   interval 3  where G''=lambda*G

We could work on  3 "spaces" simultaneously :

P=k*G, with all points with generator G   -> interval 1     jumps (1*G, 2*G, ,,,2^(n-1)*G)

P'=k*G' with all points with generator G' -> interval 2     jumps(lambda*G, lambda*2*G, .... lambda*2^(n-1)*G)

P''=k*G'' with all points with generator G'' -> interval 3  jumps(lambda^2*G, lambda^2*2*G, .... lambda^2*2^(n-1)*G)

if the movements of a kangaroo depends only by the y-coordinates, that means that if a kangaroo reach a point T in the first interval and another kangaroo reachs a point W in the second interval with the same y, we will have a collision!
From that point they will walk together along the same path (across the same equivalence classes) until they reach a DP (in this case a y-coordinate with some zero bits), we detect this collision.

EDIT:
We work in this way in a space of 3*2^n points (3 intervals), but with only 2^n y-coordinates, then we should have a collision with a higher probability.  WRONG