Pages:
Author

Topic: [ARCHIVE] Bitcoin challenge discusion - page 31. (Read 29427 times)

legendary
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
August 01, 2019, 03:31:21 AM
#66
The x coordinate and y coordinate are both binary numbers in the range 2256.
the max is also a little bit less than 2256 but unlike private keys the max is defined by P (the prime) not N (the curve order)

For the curve used for Bitcoin public keys it turns out that for every x coordinate there are two possible y coordinates.
that doesn't depend on which curve is used, as long as it is an elliptic curve it will be symmetrical about the x-axis so for each x there are 2 y values. which is due to the formula being y2=...

A compressed public key give you the x coordinate and the sign of the y coordinate so in order to convert it to a full public key you have to calculate the correct y coordinate from the x coordinate.
that is not exactly the "sign", the first byte being 2 or 3 indicates if y is even or odd respectively.
we don't actually use any signs in elliptic curve calculations since we are using modular arithmetic. for example if prime is 7 then we have
4 ≡ 11 ≡ 18 ≡ -3 ≡ -10 (mod 7)
by a "contract" we only use the smallest positive number meaning "4"
Thanks, I was trying to be a little less technical for zeilar since he is a total noob - I did not want to overwhelm him.

You points are all well taken.  Very good information for the more technical savvy in the audience.

I'm trying to follow you guys, however, its quite difficult since I don't have any background knowledge. Its definitely quite interesting. Is there any good literature you could recommend to start with?

There are ton of books on Elliptic curves, but they are not Bitcoin related. Best tutorial is famous 4-part series: Elliptic Curve Cryptography: a gentle introduction.
full member
Activity: 624
Merit: 225
ETH/BTC
August 01, 2019, 02:22:03 AM
#65
The x coordinate and y coordinate are both binary numbers in the range 2256.
the max is also a little bit less than 2256 but unlike private keys the max is defined by P (the prime) not N (the curve order)

For the curve used for Bitcoin public keys it turns out that for every x coordinate there are two possible y coordinates.
that doesn't depend on which curve is used, as long as it is an elliptic curve it will be symmetrical about the x-axis so for each x there are 2 y values. which is due to the formula being y2=...

A compressed public key give you the x coordinate and the sign of the y coordinate so in order to convert it to a full public key you have to calculate the correct y coordinate from the x coordinate.
that is not exactly the "sign", the first byte being 2 or 3 indicates if y is even or odd respectively.
we don't actually use any signs in elliptic curve calculations since we are using modular arithmetic. for example if prime is 7 then we have
4 ≡ 11 ≡ 18 ≡ -3 ≡ -10 (mod 7)
by a "contract" we only use the smallest positive number meaning "4"
Thanks, I was trying to be a little less technical for zeilar since he is a total noob - I did not want to overwhelm him.

You points are all well taken.  Very good information for the more technical savvy in the audience.

I'm trying to follow you guys, however, its quite difficult since I don't have any background knowledge. Its definitely quite interesting. Is there any good literature you could recommend to start with?
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
August 01, 2019, 12:25:25 AM
#64
The x coordinate and y coordinate are both binary numbers in the range 2256.
the max is also a little bit less than 2256 but unlike private keys the max is defined by P (the prime) not N (the curve order)

For the curve used for Bitcoin public keys it turns out that for every x coordinate there are two possible y coordinates.
that doesn't depend on which curve is used, as long as it is an elliptic curve it will be symmetrical about the x-axis so for each x there are 2 y values. which is due to the formula being y2=...

A compressed public key give you the x coordinate and the sign of the y coordinate so in order to convert it to a full public key you have to calculate the correct y coordinate from the x coordinate.
that is not exactly the "sign", the first byte being 2 or 3 indicates if y is even or odd respectively.
we don't actually use any signs in elliptic curve calculations since we are using modular arithmetic. for example if prime is 7 then we have
4 ≡ 11 ≡ 18 ≡ -3 ≡ -10 (mod 7)
by a "contract" we only use the smallest positive number meaning "4"
Thanks, I was trying to be a little less technical for zeilar since he is a total noob - I did not want to overwhelm him.

You points are all well taken.  Very good information for the more technical savvy in the audience.

Thank you very much! I do not yet understand, however, where these values consisting of more than 150 SAME numbers come from. Converting hex to dec gives me a string of 77 characters. I could transform the logic to combine the DEC result from the first and the second and it will come out just right :-) but it probably does not work, because these strings usually also appear twice.
I have absolutely no idea how to decipher your post so I cannot help you.  Good luck!
legendary
Activity: 3472
Merit: 10611
August 01, 2019, 12:00:53 AM
#63
The x coordinate and y coordinate are both binary numbers in the range 2256.
the max is also a little bit less than 2256 but unlike private keys the max is defined by P (the prime) not N (the curve order)

For the curve used for Bitcoin public keys it turns out that for every x coordinate there are two possible y coordinates.
that doesn't depend on which curve is used, as long as it is an elliptic curve it will be symmetrical about the x-axis so for each x there are 2 y values. which is due to the formula being y2=...

A compressed public key give you the x coordinate and the sign of the y coordinate so in order to convert it to a full public key you have to calculate the correct y coordinate from the x coordinate.
that is not exactly the "sign", the first byte being 2 or 3 indicates if y is even or odd respectively.
we don't actually use any signs in elliptic curve calculations since we are using modular arithmetic. for example if prime is 7 then we have
4 ≡ 11 ≡ 18 ≡ -3 ≡ -10 (mod 7)
by a "contract" we only use the smallest positive number meaning "4"
full member
Activity: 282
Merit: 114
July 31, 2019, 05:28:11 PM
#62
Thank you very much! I do not yet understand, however, where these values consisting of more than 150 SAME numbers come from. Converting hex to dec gives me a string of 77 characters. I could transform the logic to combine the DEC result from the first and the second and it will come out just right :-) but it probably does not work, because these strings usually also appear twice.
member
Activity: 166
Merit: 16
July 31, 2019, 05:01:52 PM
#61
After a night of searching the answer to the question bothering me (and not finding the answer), I can get the answer here ... The issue concerns the address 105 which has outgoing transactions and to which I know the pub (in HEX). How should I convert it to a string consisting ONLY OF NUMBERS .... From these patterns my head is already breaking and the level of knowledge in this direction has not changed. He understands that this is the index value 'x' or 'y', that for these addresses we have only 'y' because it's compressed, etc., but where do the DEC values ​​come from in various Python scripts? Guest gives to try to find a value in the range of 2 ^ 20, giving me the index value 'y' consisting of 155 digits ...
I tried to transform it in a different way and I have no chance to approach this number ... it does not even occur to me what can be converted 33-character hex string being a compressed publickey to give it 155 digits being ... well, ... what other than the index? :-)
I apologize in advance for a vague description, but as I mentioned at the beginning ... the whole night does its job. Greetings!


https://iancoleman.io/bitcoin-key-compression/

or

Code:
import bitcoin as b
pubkey = b.decode_pubkey("03bcf7ce887ffca5e62c9cabbdb7ffa71dc183c52c04ff4ee5ee82e0c55c39d77b")
print("X:", hex(pubkey[0]), "Y:", hex(pubkey[1]))


Hehe It never even crossed my mind to import bitcoin - Smiley much better!
full member
Activity: 282
Merit: 114
July 31, 2019, 01:41:29 PM
#60
I could immediately ask and get so unpredictable answers without losing the night. Thank you for your knowledge and scripts for Python!
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
July 31, 2019, 07:46:11 AM
#59
After a night of searching the answer to the question bothering me (and not finding the answer), I can get the answer here ... The issue concerns the address 105 which has outgoing transactions and to which I know the pub (in HEX). How should I convert it to a string consisting ONLY OF NUMBERS .... From these patterns my head is already breaking and the level of knowledge in this direction has not changed. He understands that this is the index value 'x' or 'y', that for these addresses we have only 'y' because it's compressed, etc., but where do the DEC values ​​come from in various Python scripts? Guest gives to try to find a value in the range of 2 ^ 20, giving me the index value 'y' consisting of 155 digits ...
I tried to transform it in a different way and I have no chance to approach this number ... it does not even occur to me what can be converted 33-character hex string being a compressed publickey to give it 155 digits being ... well, ... what other than the index? :-)
I apologize in advance for a vague description, but as I mentioned at the beginning ... the whole night does its job. Greetings!

There appears to be a few misunderstandings in your post.  Specifically the part in bold is wrong. x and y are not "indexes" they are coordinates.

A private key is a number between 1 and a little bit less than 2256

A public key is a point on a curve in two dimensional space.  Therefore it has and x coordinate and a y coordinate.

The x coordinate and y coordinate are both binary numbers in the range 2256.

For the curve used for Bitcoin public keys it turns out that for every x coordinate there are two possible y coordinates.

A full public key give you both the x coordinate and y coordinate of the point that is the public key.

A compressed public key give you the x coordinate and the sign of the y coordinate so in order to convert it to a full public key you have to calculate the correct y coordinate from the x coordinate.

The script above does just that:  calculates the correct y coordinate from the x coordinate and the sign of the y coordinate.
member
Activity: 166
Merit: 16
July 31, 2019, 06:59:29 AM
#58
After a night of searching the answer to the question bothering me (and not finding the answer), I can get the answer here ... The issue concerns the address 105 which has outgoing transactions and to which I know the pub (in HEX). How should I convert it to a string consisting ONLY OF NUMBERS .... From these patterns my head is already breaking and the level of knowledge in this direction has not changed. He understands that this is the index value 'x' or 'y', that for these addresses we have only 'y' because it's compressed, etc., but where do the DEC values ​​come from in various Python scripts? Guest gives to try to find a value in the range of 2 ^ 20, giving me the index value 'y' consisting of 155 digits ...
I tried to transform it in a different way and I have no chance to approach this number ... it does not even occur to me what can be converted 33-character hex string being a compressed publickey to give it 155 digits being ... well, ... what other than the index? :-)
I apologize in advance for a vague description, but as I mentioned at the beginning ... the whole night does its job. Greetings!

a python script to turn compressed into umcompressed pubkey


Code:

def pow_mod(x, y, z):
    "Calculate (x ** y) % z efficiently."
    number = 1
    while y:
        if y & 1:
            number = number * x % z
        y >>= 1
        x = x * x % z
    return number

p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
compressed_key = 'INSERT COMPRESSED PUBKEY HERE'
y_parity = int(compressed_key[:2]) - 2
x = int(compressed_key[2:], 16)
a = (pow_mod(x, 3, p) + 7) % p
y = pow_mod(a, (p+1)//4, p)
if y % 2 != y_parity:
    y = -y % p
uncompressed_key = '04{:x}{:x}'.format(x, y)
print(uncompressed_key)


Then converting to dec should be no biggie in python
blah=0xwhatever (x co-ord, then y maybe?)
print (blah)

Now you have the numbers put them in whatever program in whatever language you are working with..
full member
Activity: 282
Merit: 114
July 31, 2019, 12:32:21 AM
#57
After a night of searching the answer to the question bothering me (and not finding the answer), I can get the answer here ... The issue concerns the address 105 which has outgoing transactions and to which I know the pub (in HEX). How should I convert it to a string consisting ONLY OF NUMBERS .... From these patterns my head is already breaking and the level of knowledge in this direction has not changed. He understands that this is the index value 'x' or 'y', that for these addresses we have only 'y' because it's compressed, etc., but where do the DEC values ​​come from in various Python scripts? Guest gives to try to find a value in the range of 2 ^ 20, giving me the index value 'y' consisting of 155 digits ...
I tried to transform it in a different way and I have no chance to approach this number ... it does not even occur to me what can be converted 33-character hex string being a compressed publickey to give it 155 digits being ... well, ... what other than the index? :-)
I apologize in advance for a vague description, but as I mentioned at the beginning ... the whole night does its job. Greetings!
full member
Activity: 282
Merit: 114
July 28, 2019, 01:59:19 PM
#56
Man, I really don't understand you. What is your goal in selling this script if it really works!?
WHY DONT YOU OPEN ALL KEYS from 61 -> whatever you can, if it takes you less time then others?
0.025 BTC price for script? Mate, if you open even #61 address you will cover ~24 buyers. ))
Why do you spend your time for prooving that your script does work? For the same time you could open #74 address and get the bounty!!!
Where is the logic???

If you sell your script to several people they will open all possible addresses (until the time required will be within an adequate range) in a days and then your scipt will just remain in a history of cracking.....

Because it only works on the addresses with spend transactions:  65, 70, 75, 80, 85, etc. and all of these have been opened up to #100.  #105 will take a bit of effort to open so instead of running it all that time just sell it to others.  Kind of makes sense at this point.

What is your expected time for #105?
I was using 4x Tesla V100 for it. Here is a table with expected times:

|------+-------------------+-------------------|
| bits |      4x V100      |     100x V100     |
|------+-------------------+-------------------|
|  100 |       2d 19:52:51 |          02:42:54 |
|  105 |           16 days |          15:21:34 |
|  110 |           90 days |       3d 14:53:14 |
|  115 |  1 year  147 days |           20 days |
|  120 |  7 years 341 days |          116 days |
|  125 | 44 years 323 days |  1 year  290 days |
|  130 |       253 years   | 10 years  57 days |
|  135 |     1,436 years   | 57 years 166 days |
|  140 |     8,125 years   |         325 years |
|  145 |    45,964 years   |       1,838 years |
|  150 |   260,011 years   |      10,400 years |
|  155 | 1,470,848 years   |      58,833 years |
|  160 | 8,320,376 years   |     332,815 years |
|------+-------------------+-------------------|

Looks like a "world record" would be 120 bits.

Thanks for the conversion into my resources :-)
---
[Edited after half day]- according to an earlier promise - I updated the list of addresses in the main post (along with the size of the range). In addition, I've also added links to useful tools for unit conversion and key checking. Greetings!
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
July 27, 2019, 08:08:43 AM
#55
what I did understand is that from the adress 1 to address 160 there is a difficulty of 1 bit added to the length of the private key.
A the new transaction is the difficulty 9 bit each time added to the private key, because what I see there is an incremantation of 9 at each balance

All he did was change the payout pattern.  Originally for each bit of additional difficulty the payout went up by 0.001 BTC

62 bits of difficulty was = 0.062 BTC
64 bits of difficulty was = 0.064 BTC
101 bits of difficulty was = 0.101 BTC
105 bits of difficulty was = 0.105 BTC
120 bits of difficulty was = 0.120 BTC
150 bits of difficulty was = 0.150 BTC
Etc...

Now for each bit of difficult the payout goes up by 0.01 BTC

62 bits of difficulty total now = 0.62 BTC
64 bits of difficulty total now = 0.64 BTC
101 bits of difficulty total now = 1.01 BTC
105 bits of difficulty total now = 1.05 BTC (probably the next one to be cracked)
120 bits of difficulty total now = 1.20 BTC
150 bits of difficulty total now = 1.50 BTC
Etc...

You might be overthinking this.  It is just that the total increased to 0.01 BTC per added bit of private key taking both funding transactions into account.
newbie
Activity: 6
Merit: 0
July 27, 2019, 12:10:07 AM
#54
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
I read all the topic you are talking about. I'm talking about the new list
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
here in this transaction
I think this thread for a new list ? no ?
Yes that transaction is one of the transactions listed in the OP.  This thread covers the entire history of the challenge and the OP lists all cracked addresses including those from the first funding transaction and those included in the second funding transaction.  So to answer your initial question, the private keys that have been cracked from the transaction you listed are all shown in the OP.
thank you , I get it now , I'm confused because the adresses from 160 to 256 were swiped to the new transaction
The creator/owner of the challenge moved those BTC due to a suggestion from a contributor to the original thread.
what I did understand is that from the adress 1 to address 160 there is a difficulty of 1 bit added to the length of the private key.
A the new transaction is the difficulty 9 bit each time added to the private key, because what I see there is an incremantation of 9 at each balance
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
July 26, 2019, 01:58:38 PM
#53
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
I read all the topic you are talking about. I'm talking about the new list
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
here in this transaction
I think this thread for a new list ? no ?
Yes that transaction is one of the transactions listed in the OP.  This thread covers the entire history of the challenge and the OP lists all cracked addresses including those from the first funding transaction and those included in the second funding transaction.  So to answer your initial question, the private keys that have been cracked from the transaction you listed are all shown in the OP.
thank you , I get it now , I'm confused because the adresses from 160 to 256 were swiped to the new transaction
The creator/owner of the challenge moved those BTC due to a suggestion from a contributor to the original thread.
newbie
Activity: 6
Merit: 0
July 26, 2019, 01:51:16 PM
#52
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
I read all the topic you are talking about. I'm talking about the new list
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
here in this transaction
I think this thread for a new list ? no ?
Yes that transaction is one of the transactions listed in the OP.  This thread covers the entire history of the challenge and the OP lists all cracked addresses including those from the first funding transaction and those included in the second funding transaction.  So to answer your initial question, the private keys that have been cracked from the transaction you listed are all shown in the OP.
thank you , I get it now , I'm confused because the adresses from 160 to 256 were swiped to the new transaction
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
July 26, 2019, 01:42:03 PM
#51
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
I read all the topic you are talking about. I'm talking about the new list
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
here in this transaction
I think this thread for a new list ? no ?
Yes that transaction is one of the transactions listed in the OP.  This thread covers the entire history of the challenge and the OP lists all cracked addresses including those from the first funding transaction and those included in the second funding transaction.  So to answer your initial question, the private keys that have been cracked from the transaction you listed are all shown in the OP.
newbie
Activity: 6
Merit: 0
July 26, 2019, 01:00:29 PM
#50
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
I read all the topic you are talking about. I'm talking about the new list
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
here in this transaction
I think this thread for a new list ? no ?
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
July 26, 2019, 11:55:09 AM
#49
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry
All cracked private keys are listed in a maintained list in the the OP, see the section "EXISTING KEYS FOUND SO FAR:"

https://bitcointalksearch.org/topic/m.51860206

All of the transactions related to this challenge are also listed in the OP in the section "A BRIEF LIST OF IMPORTANT DATES IN THE HISTORY OF THE CHALLENGE:"

Please read the first post in this thread and it will answer a lot of questions.
newbie
Activity: 6
Merit: 0
July 26, 2019, 11:08:21 AM
#48
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry

Almost 70 addresses were cracked. Read the first post of the topic.

Here you have the list: https://blockchair.com/bitcoin/outputs?q=transaction_id(56857085)&s=index(asc)#

No I'm talking about the new list of 100 BTC, what you see is the old transaction it cost 32 BTC.
newbie
Activity: 43
Merit: 0
July 26, 2019, 05:33:34 AM
#47
Hello,
I'm interested by this challenge.
I think the 10 first new address are cracked
https://www.blockchain.com/btc/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

please any one could update us the privte keys  Cry

Almost 70 addresses were cracked. Read the first post of the topic.

Here you have the list: https://blockchair.com/bitcoin/outputs?q=transaction_id(56857085)&s=index(asc)#
Pages:
Jump to: