 Show Posts
|
|
Pages: [1]
|
what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero?
that is not mathematically possible. the point you posted in OP (04065f5...) is on secp256k1 curve and when it is multiplied by a number smaller than the curve order the resulting point is also already on curve. the correct result is what you posted in this comment (049663999....). the only reason why you get zero is possibly a bug in the tool you are using. I agree, a bug on gobittest seems more likely as an explanation since if I do the same operation on python I get a different key but the same public address. |
|
|
|
Try putting in your two private keys as two very small numbers - say "2" and "5". The resulting private key are either "7" (2+5) or "A" (2*5 - in hex of course). Sure, it then uses elliptic curve multiplication to turn those private keys in to public keys, but the process it uses of multiplying the two private keys is just straight forward arithmetic multiplication. Try using the numbers FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 and as your two private keys. You will see that One + Two gives you the curve order ( n) which is invalid and therefore gives no public key, whereas One x Two gives the FFFF...4140 number above ( n-1) which is the highest valid private key and does generate a public key. You also mentioned that its entirely possible to generate a non-valid private key, can you provide an example on how you would do so since the hex for this key is zero and no library will allow you to do so unless it was not coded correctly? Any number higher than n-1 is a non-valid private key. It is possible to generate such a key, but I never said it would be possible to use such a key. Some pieces of software will calculate the private key modulo n though, and so turn a non-valid private key in to a valid one. You can try this on the gobittest page by using the private keys FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 and The private key generated from One + Two wraps back around and gives the private key "1". Thank you for the detailed explication, what you said makes sense but what I don't understand is why would multiplying the key I mentioned by 12345 (or 3039 in hex) gives zero? I tried it with a python lib and it gave a different result actually but very similar public address. The public address produced by gobittest for the zero key is 049663999D864D6D1A79FFB0C547D19CB5A51123888AD4BDAE5CCEDB61CC3239BA4182C2088B09D 67ADEDF1BDC543B5F336D017017FF8D83E44D75A00A3D6BEE and the public key produced by the python lib is 049663999d864d6d1a79ffb0c547d19cb5a51123888ad4bdae5ccedb61cc3239ba004182c2088b0 9d67adedf1bdc543b5f336d017017ff8d83e44d75a00a3d6bee
If you mean this page on gobittest https://gobittest.appspot.com/PrivateKey, I entered the uncompressed WIF inside it and it gave me a private key of 9F23FFFFFFFFFFFFFFFFFFFFFFFFFFFFEF4D21CEC75756599124A862727EE62F6E5C. That private key isn't on the curve, so it's technically point at infinity ( I'm not sure if this is correct though). So if you multiply it by any number you will also get point at infinity (stack exchange), which gobittest just writes as 0. I dont know that the private key is for 04065f53171dcd7d03a71e93d74394694e6af13aef4030ce9faa3db65d627ecbcfcd75a3048ff8a 0d87bff6ec60d900e86523e3165e5bebc3bbdfc199d3a998063 but its definitely not what you mentioned. So what I'm wondering is why multiplying this by dec 12345 yeild point at infinity on gobittest [moderator's note: consecutive posts merged] |
|
|
|
First off, multiplying two private keys together is not elliptic curve multiplication. The gobittest vanity page literally just does arithmetic multiplication of two hexadecimal numbers. Second, it is entirely possible to generate a non-valid private key. The uncompressed private key you have generated is: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 This number is called n, and is known as the order of the base point G. This is the number of times you can add the base point G to itself. Therefore, the total number of valid private keys in bitcoin is n-1. Any number of n or greater is an invalid private key. First of all thanks for your reply. The gobittest vanity page doesn't just multiply two hex numbers as far as I know, it does so based on the bitcoin curve. You can try and produce a result from any multiplication that is outside the curve and you will not be successful, thats why it was surprising to me. If you can however please share an example other than the one posted. You also mentioned that its entirely possible to generate a non-valid private key, can you provide an example on how you would do so since the hex for this key is zero and no library will allow you to do so unless it was not coded correctly? |
|
|
|
|
I was playing around with the gobittest.appspot website and I came across this:
If you multiply 12345 (3039 in hex) by this key: (04065f53171dcd7d03a71e93d74394694e6af13aef4030ce9faa3db65d627ecbcfcd75a3048ff8a 0d87bff6ec60d900e86523e3165e5bebc3bbdfc199d3a998063) you will get a key that's not on the curve.
I was able to find some info about the Zero key but it doesn't explain the multiplication results. The key i'm multiplying with is a random key so I don't know the private key for but either way the multiplication should never give a key outside the curve.
Can anyone explain how was this possible?
Here's the info on key zero
0x00: Uncompressed private key: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
Uncompressed WIF: 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetwr388P
Uncompressed public key: EMPTY
Uncompressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
Compressed private key: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD036414101
Compressed WIF: L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFqRzExJJ
Compressed public key: EMPTY
Compressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
~0xSkrypt
|
|
|
|
|
If someone eventually managed to brute force Puzzle 64 (and beyond) can't someone who's monitoring the keys just use Pollard Kangaroo once the public key is broadcasted and also sweep it with a higher transaction fee since double spending is still an issue with Bitcoin?
If thats the case how can you prevent someone from sweeping the same key if you both became aware of the private key?
|
|
|
|
Anyone know how to modify this code so that it converts the input public key into a compressed P2PKH address instead of uncompressed ? def public_key_to_address(public_key):
#print('Wanting to [%s] this to address'%public_key)
output = []; alphabet = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
var = hashlib.new('ripemd160')
try:
var.update(hashlib.sha256(binascii.unhexlify(public_key.encode())).digest())
var = '00' + var.hexdigest() + hashlib.sha256(hashlib.sha256(binascii.unhexlify(('00' + var.hexdigest()).encode())).digest()).hexdigest()[0:8]
count = [char != '0' for char in var].index(True) // 2
n = int(var, 16)
while n > 0:
n, remainder = divmod(n, 58)
output.append(alphabet[remainder])
for i in range(count): output.append(alphabet[0])
return ''.join(output[::-1])
except:
# Nothing
return -1 |
|
|
|
when you say #addition factor, in this case its G or +1 decimal
K ='0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'
you mean add +1 decimal to previous pubkey? The "G" is throwing me off Yes I mean G as in the generator point which is equal to 1 in decimal but the code should allow for any address to be added I just used 1 for simplicity [/quote] Sorry, I had more questions but posted too soon. Kangaroos...sounds like what you want they aren't necessarily kangaroos, just a 'brute force" type of jump. Start at pubk a, add increment to pubka to create pubk b, rinse and repeat. Each time a new pubk is created and 'visited' you want to convert that pubk to a BTC address and write both to a file. rinse and repeat all until a predesignated address is reached (end of range) or end after so many jumps. Anything I missed? [/quote] Thats exactly correct yes, consistently adding a specific key, converting output to address, then writing it to a CSV file. How would that look like in a Python code? |
|
|
|
[/quote] when you say #addition factor, in this case its G or +1 decimal
K ='0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'
you mean add +1 decimal to previous pubkey? The "G" is throwing me off [/quote] Yes I mean G as in the generator point which is equal to 1 in decimal but the code should allow for any address to be added I just used 1 for simplicity |
|
|
|
|
Can someone please help me execute a simple concept in python?
I want to create a herd of wild kangaroos with steady jumps (+G for example or +1 in decimal) then convert it to address, and write the results into a CSV file, with a condition to break if the key at the end of the range is reached.
I just started learning coding so excuse my ignorance. I'm aware it would take millions of years to solve anything with this and that other programing languages are more effective, I just want to experiment with the idea.
What I was able to come up with for puzzle 120 for example is as follows
==========================
from cryptos import *
import csv
#The public key we want to solve for
PK ='04ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a26302b195386bea3f 5f002dc033b92cfc2c9e71b586302b09cfe535e1ff290b1b5ac'
#addition factor, in this case its G or +1 decimal
K ='0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'
#addition process creating a wild kangaroo (this process needs to be looped to add K to the result over and over again)
X = add_pubkeys(PK, K)
#converting public key to address
addr = pubtoaddr (X)
#writing address to a CSV file
with open('WK.csv', 'w', newline='') as csvfile:
thewriter = csv.writer(csvfile)
thewriter.writerow(['address'])
thewriter.writerow([addr])
#The break condition should be if address result = 1Cyj6SThgWdZWU6w75Rjf8V2bDiZds7AGo (end of puzzle range "ffffffffffffffffffffffffffffff")
=============================================
Any help is much appreciated
|
|
|
|
Hi, I have finished the 64 bit range, but I have not found any key with 8 rx 570 8gb.
You can't scan the 64 bit range with Pollard's kangaroo since the public key is unknown, we know only the address 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN. Only keys in the 5 multiples (65, 70, 75, 80, 85,... 160) have spent values and therefore have their public keys published. The only way to scan for address 64 is Brute force/Vanity search and plenty of luck. |
|
|
|
|
Hey guys please forgive my ignorance, I’m new to this and I was wondering if someone can clarify something that is related to the security of elliptic curves in general.
When we do an addition the secp256k1 curve’s equation (y² = x³ + 7 mod p) creates a loop that overflow and wraps max+1 to 0
My question is what is the possibility for the following:
1- A script that determines if an addition has reached the end of the curve and looped
2- An extended curve (over a larger field, or a larger mod p?) that would yield the same results for addition as secp256k1 but would loop further down the curve, so that by verifying the result, if the point is not on the secp256k1, we’d know it has looped.
My guess is that both are impossible as it would completely compromise the security of the elliptic curve, I just wanted to hear an educated answer on the matter.
Thank you
|
|
|
|
|
Hey guys please forgive my ignorance, I’m new to this and I was wondering if someone can clarify something that is related to solving the puzzle and the security of elliptic curves in general.
When we do an addition the secp256k1 curve’s equation (y² = x³ + 7 mod p) creates a loop that overflow and wraps max+1 to 0
My question is what is the possibility for the following:
1- A script that determines if an addition has reached the end of the curve and looped
2- An extended curve (over a larger field, or a larger mod p?) that would yield the same results for addition as secp256k1 but would loop further down the curve, so that by verifying the result, if the point is not on the secp256k1, we’d know it has looped.
My guess is that both are impossible as it would completely compromise the security of the elliptic curve, I just wanted to hear an educated answer on the matter.
Thank you
|
|
|
|
|
