I don't understand how the search is calculated in this particular range.
Explain in a nutshell.
Start range is subtracted from End range to make a new range between 0 and end-start, which is searched instead. Then we make a batch, or herd, of 1024 starting points, with tames and wild points overlapping each other like this: Tame Wild Tame Wild Tame... The tame random points between 0 and end-start=range, and the wild points will have them between -range/2 and range/2. These are the starting points We take some random numbers, the same amount as herd points, between 0 and range/2 as "jump points" and subtract them from our herd points. Resulting numbers are then placed in an Group (which in Kangaroo is just defined as a collection of numbers) and ModInv is applied to all of them. For iteration we compute: Rx = (Py - JumpPointY [mod n] * Group [mod n]) ^2 [mod n] - JumpPointX [mod n] - Py [mod n] Ry = Px - Rx [mod n] * (Py - JumpPointY [mod n] * Group [mod n]) - Py [mod n] For each g in CPU_GRP_SIZE (2014) And the search points P are replaced with the ones in R. Guys fyi 1024 is not div point in ecc, posting here, divideable magic digits for ecc, these will help you to decide bitrange to divide, use these magic ecc div numbers, for pollard kanagroo or other manual div 2 447 7572 564114 3 596 9536 752152 4 631 10096 1128228 6 894 14304 1504304 8 1192 15144 2256456 12 1262 20192 3008608 16 1788 28608 4512912 24 1893 30288 6017216 32 2384 40384 9025824 48 2524 60576 18051648 64 3576 94019 96 3786 121152 149 4768 188038 192 5048 282057 298 7152 376076 |
|
|
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example
03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854
030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854
029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577
03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577
03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300
0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300
02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range Did you cut it by 800000000000000000000000000000 to drop it down one range before cutting down to 110? Could mean the difference in 2^110 versus 2^109 No cut it by 800000000000000000000000000000 exact 110 bit range 16/260 ( 2^109 to 2^110-1 ) |
|
|
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example
03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854
030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854
029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577
03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577
03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300
0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300
02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? The quick and easy answer would be to look at how long it took to solve #110...roughly 2 days. You could take the 2 days and times that by 260 to get a quick and easy answer however, we know that the tames generated while searching for each pubkey would be used/valid for each subsequent pubkey. I think if one had 260 GPUs, each searching for 1 of the 260 pubkeys, and doing a daily merge/collision check, it would be much faster than the 2 x 260 days, but no way to be 100% certain. Are all 260 in the 110 range? 16 out of 260 will be in 110bit range |
|
|
|
For example If I am running with 1 loaded public key BSGS and for argument sake with 1 key loaded I am operating at 100 million keys per second but if I substract and load 1000 of the same key just offset by a different distance from the target key my keys per second drops 100 million/1000 (more actually) but now I have 1000 more possible chances of a collision because i have added 1000 targets.
Example
03b6c66d90910721ac8e6f8ef0ebb222fff638227122b21c5853e787ca3d119f08 # - 651321717934608777722865459537368854
030e7b9ccf0feabe79d8745a89b575b52ff21333368b4a9c95c72dbef88a6105e2 # + 651321717934608777722865459537368854
029a564b60e6bed3449052228a609334b43d59bc5f79ca5c622334658ce89b6026 # - 657967857913533357087384494838770577
03a127833050783f814ee013e796fbc937067a86741564bdb9086a6e6e6398e11d # + 657967857913533357087384494838770577
03d0203676b61edda6208b2f9b204de5e8ee2849723458dc7531b1eaba503de390 # - 664613997892457936451903530140172300
0247dd5a10ae3aab4187c7af2a5babcc8ee401ed09e67fbc6ea75e35cc8471d8c9 # + 664613997892457936451903530140172300
02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630 # target
If one of these keys hits then i just add or subtract the decimal value on the right from the hex private key found convert to decimal add or subtract than convert back to hex and now I have the key for 120 02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
I don't think keys per second drops using BSGS, not the one I put out that Jean Luc built. It's actually faster because with multiple pubkeys you do not have to rewalk the baby steps every time. If you are using another version of BSGS, then I'm not sure about it. But the one I use, it's the same speed, but overall faster because it doesn't have to perform and store the baby walks every time. With Kangaroo, it probably is faster searching 1 pubkey. Let's say you shifted down 2^10; now you'd have to search 1024 pubkeys in the 2^110 range. Avg operations of 1 pubkey at 2^120 = 2^60 (roughly) but 1024 at 2^110 = 1024 * 2^55 = 2^65 operations if 260 pubkeys in 110bit, then how much time it will take ? |
|
|
|
person a have prvkey = abc
person b have prvkey = def
both person have there prvkeys and pubkeys, then concatenate pubkeys points to get next pubkeys, .. so on word... And then what? Knowing the private keys to two public keys that you have added together, concatenated, whatever, will not let you spend any coins sent to that resulting public key's address. both dont know each other prvkeys, only pubkeys known each other ... If this is what you want to achieve, then why not just use multi-sig? Trying to roll your own system like this is going to end up with you locking coins in an address or behind a script that you cannot access. multisig requird both person sign/verify, in my new system, address and pubkey multi control, but could sign fro both and/or single, etc, anyway debate on every new system is always long, but first we need point con tests,  |
|
|
|
0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
+
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
result
valid curve x=0 and y=8f53.....
base on these strategy, going to find point concatenate, where result will be on curve or not at curve (if outside of modulo p),
That's not the way to do this point addition, if you add two points with the same X coordinate but opposite Y coordinates, you get the curve's infinity point, which is a special case and can't be represented as a public key. Also you still haven't explained what this "concatenation" is supposed to accomplish. point concatenation will help me to generate new public addresses in new security level, like multi pubkeys "3" p2wsh, p2sh, similar, finding new paring, diffrent level secure, but must know, 0 point loop holes example if x=0 and not at curve then where from y -y comes, as its not satisfy Equation, Q is where from y-y comes ? Your y values comes from the fact that the math behind the recovery of y values always gives some answer, even if the original x coordinate is invalid. Also, you as saying you want to use this to generate new public addresses, but do you have any way to find the private key for these? Because without someone knowing the private key, having a public key is pretty useless. person a have prvkey = abc person b have prvkey = def both person have there prvkeys and pubkeys, then concatenate pubkeys points to get next pubkeys, .. so on word... both dont know each other prvkeys, only pubkeys known each other ... its all next level of works, first level work is point concatenate formula, consider on it to make point concatenate with it |
|
|
|
0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
+
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
result
valid curve x=0 and y=8f53.....
base on these strategy, going to find point concatenate, where result will be on curve or not at curve (if outside of modulo p),
That's not the way to do this point addition, if you add two points with the same X coordinate but opposite Y coordinates, you get the curve's infinity point, which is a special case and can't be represented as a public key. Also you still haven't explained what this "concatenation" is supposed to accomplish. point concatenation will help me to generate new public addresses in new security level, like multi pubkeys "3" p2wsh, p2sh, similar, finding new paring, diffrent level secure, but must know, 0 point loop holes example if x=0 and not at curve then where from y -y comes, as its not satisfy Equation, Q is where from y-y comes ? |
|
|
|
|
0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
+
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
result
valid curve x=0 and y=8f53.....
base on these strategy, going to find point concatenate, where result will be on curve or not at curve (if outside of modulo p),
|
|
|
|
|
from x = 8a80022196a21dcf65edb784fabedce993aba053f77169c814b61f30be356589
y1 = 84125d3056d8364cf8962165f479d3da6f2ebc096f792df0ba484d8d703c0667
y2 = 7beda2cfa927c9b30769de9a0b862c2590d143f69086d20f45b7b2718fc3f5c8
x1 = 8a80022196a21dcf65edb784fabedce993aba053f77169c814b61f30be356589
x2 = 8a1ee2ec6c2f584b64021f88a826ce05c7981834b0d003dd91fcff590b1aaed2
x3 = eb611af1fd2e89e5361028f25d1a5510a4bc477757be925a594ce17436afe403
|
|
|
|
None of the combinations of those points are on the secp256k1 curve. Whatever you are doing, it is simply wrong.
Try it yourself, to be a valid point it has to satisfy the equation (x**3 + A*x + B) % N == (y**2) % N and for secp256k1 N = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f, A = 0, B = 7
get three x1, x2, x3 from x=0 tell me what y's and x's you get result |
|
|
|
I got curious and wondered where you got 0x70ac8110203e9f95f8d832964b58ccc2c712bb1c6cd58e861134b48f456c9b53 from, and discovered that it's what happens when you try to decompress a point with the x coordinate set to 0. Note that there are NO points on the secp256k1 curve with 0 as a valid x coordinate, this just happens because that iancoleman site doesn't check point validity at all.
If you enter 030000000000000000000000000000000000000000000000000000000000000000 into the iancoleman site, you get x=0 and y=0x70ac8110203e9f95f8d832964b58ccc2c712bb1c6cd58e861134b48f456c9b53 - which makes me yet again wonder what the hell you are trying to do.
Could you try to explain a bit more what your goal is?
btw i mention valid points, as compress address same and uncompressed address changed when you construct x1, x2, x3 from y1 or y2 your x=0 vanish y1 = 8f537eefdfc1606a0727cd69b4a7333d38ed44e3932a7179eecb4b6fba9360dc y2 = 70ac8110203e9f95f8d832964b58ccc2c712bb1c6cd58e861134b48f456c9b53 x1 = eb611af1fd2e89e5361028f25d1a5510a4bc477757be925a594ce17436afe403 x2 = 8a80022196a21dcf65edb784fabedce993aba053f77169c814b61f30be356589 x3 = 8a1ee2ec6c2f584b64021f88a826ce05c7981834b0d003dd91fcff590b1aaed2 i am simple playing with bits and curves |
|
|
|
these all are simple math ecc addition, remain Q is point concatenate base on formula, where at curve or not at curve, my logics are beyond your thinking by point concatenate, where i have reach is same address with x same 2 difrent y's see below 1FQYNQGz32BDLcSBC4Kz54mErjzB7kbL1N 1FQYNQGz32BDLcSBC4Kz54mErjzB7kbL1N 1NWYqgBKDgJ3X8JnxynVRJeHxpsabPAcK8 1MfnBBkWkcXTQSvSucgCrh3D1WpvdV7DCM see compressed address 04eb611af1fd2e89e5361028f25d1a5510a4bc477757be925a594ce17436afe40370ac8110203e9 f95f8d832964b58ccc2c712bb1c6cd58e861134b48f456c9b53 at y is 70ac8110203e9f95f8d832964b58ccc2c712bb1c6cd58e861134b48f456c9b53 03eb611af1fd2e89e5361028f25d1a5510a4bc477757be925a594ce17436afe403 see uncompressed address 04eb611af1fd2e89e5361028f25d1a5510a4bc477757be925a594ce17436afe40384125d3056d83 64cf8962165f479d3da6f2ebc096f792df0ba484d8d703c0667 at y is 84125d3056d8364cf8962165f479d3da6f2ebc096f792df0ba484d8d703c0667 where y is difrent but in both cases compressed address is same uncompressed addresses are difrent check here https://iancoleman.io/bitcoin-key-compression/ |
|
|
|
P + G = PG
hex prvkey is abc
x: 3ef30130654689a64c864d6dd38760481c55fc525e2c6c7084e2d2d3d4d51be9
y: f7d86b288c09ddb5311f292285168000e43e4b62201bd8de23a391daa8e00ce8
hex prvkey is def
x: 6a6e1dc6f203f7fdd97965892301e5fb995a37318c410543835f0edcd3456c49
y: 2a072b9898b93e9eb05f9ad86a97546d83b579bf6efd3482f93baca13784496b
result = hex prvkey is abcdef:
x: 12faae608bd6562562b8f85564664cd1fdcd667f6b24b2b221ef86b9231f4d74
y: 512ee8cd9b34331afd05ccb8d81d1393c150c73ec5695845b731f7e6e0086719
Let me see if I understand .... Instead: 2 + 1 = 3 3 + 4 = 7 You want this: 2 + 1 = 21 3 + 4 = 34 ? yes |
|
|
|
here we are taking as hex
b+d =bd
where b is one point and d is 2nd point, result should be bd point in concatenation
for your easy dec result will be 189 not 1113
I guess you do understand that this concatenation you're doing is not point addition but rather a different operation (which makes me feel better), so now you're looking for math properties of this concatenation thing? Well for starters the operation you're doing is equal to a*len(b)*4 + b [there are 4 bits in a hex char] in terms of the real addition so so you should be able to use it almost anywhere you need an Ax + B style expression. this is simple math operation to calc, a*len(b)*16 + b but based on x,y points, there will be 2 snaorio, if concatenate under mod p, will be calculated, and result will apear on curve other not at curve, that will be apear based on point formula, and if operation everything will be on curve always |
|
|
|
Impossible, not real and not logical.
movie name mission impossible, always done at possible, i believe some math expert have solution, |
|
|
|
|
hex b dec 11
x: 774ae7f858a9411e5ef4246b70c65aac5649980be5c17891bbec17895da008cb
y: d984a032eb6b5e190243dd56d7b7b365372db1e2dff9d6a8301d74c9c953c61b
hex d dec 13
x: f28773c2d975288bc7d1d205c3748651b075fbc6610e58cddeeddf8f19405aa8
y: 0ab0902e8d880a89758212eb65cdaf473a1a06da521fa91f29b5cb52db03ed81
result should be
hex bd dec 189
x: 6d7ef6b17543f8373c573f44e1f389835d89bcbc6062ced36c82df83b8fae859
y: cd450ec335438986dfefa10c57fea9bcc521a0959b2d80bbf74b190dca712d10
|
|
|
|
Here you write 1 + 1 = 11
And in what system should this be applied? Decimal, hex, or maybe binary?
For example, two numbers in hex b(11) and d(13)
In hex
b + d = bd
But in dec
11 + 13 = 1113
But
hex bd = dec 189 and not equal 1113 from previso result
So which system should you use as a basis for concatenation?
If decimal
X + Y = XY
in mathematic
X*strpad('1', len(Y)+1, '0', right) + Y
But in Hex it is completely different!
But if we transfer this to the points of coordinates, then nothing will work, because the length of Y is not known.
here we are taking as hex b+d =bd where b is one point and d is 2nd point, result should be bd point in concatenation for your easy dec result will be 189 not 1113 |
|
|
|
|
Show Posts
