Bitcoin Forum
August 16, 2018, 02:21:28 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 »  All
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 28862 times)
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 02, 2016, 07:11:19 PM
 #121

We should form a cooperative and search the private key...
Most dump idea ever. Grin
You made my day.
You obviously do not know me very well.

This idea is not even a mole on the ass of a gnat on the ass of the dumpest idea I have ever had.

Thinking about is a bit further the cooperative method of finding the next prize can be simplified to just giving the entire prize, all 0.051 x $433.42 = $22.10 to whoever is lucky enough to be assigned the lucky section of private keys by the server.

That way we would not have to figure out which charity, or how to prove work, etc.

It would just be a lottery with a $22.10 prize for using up an immense amount of electricity.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
1534429288
Hero Member
*
Offline Offline

Posts: 1534429288

View Profile Personal Message (Offline)

Ignore
1534429288
Reply with quote  #2

1534429288
Report to moderator
1534429288
Hero Member
*
Offline Offline

Posts: 1534429288

View Profile Personal Message (Offline)

Ignore
1534429288
Reply with quote  #2

1534429288
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
BG4
Legendary
*
Offline Offline

Activity: 951
Merit: 1010


PaperSafe


View Profile WWW
January 02, 2016, 09:53:54 PM
 #122

After  reading into this puzzle post ..I have a question maybe someone can answer

1   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
2   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAvUcVfH
3   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB1FQ8BZ
4   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB4AD8Yi
5   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBF8or94
6   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBKdE2NK
7   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
8   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBbMaQX1
9   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBd7uGcN   
A   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBoNWTw6
B   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBquB4Rj
C   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreC4p2u5o
D   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCAVyVnh
E   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCHK2Zzv
F   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCMUnXUo

These are all valid private keys....  Just how many "NON valid" keys are in between each of the first 16 valid keys
and is there a pattern..Huh

I am a little rusty with my Base58 math skills and maybe I should have done it in WIF Compressed....
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 02, 2016, 09:58:29 PM
 #123

After  reading into this puzzle post ..I have a question maybe someone can answer

1   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
2   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAvUcVfH
3   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB1FQ8BZ
4   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB4AD8Yi
5   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBF8or94
6   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBKdE2NK
7   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
8   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBbMaQX1
9   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBd7uGcN   
A   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBoNWTw6
B   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBquB4Rj
C   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreC4p2u5o
D   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCAVyVnh
E   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCHK2Zzv
F   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCMUnXUo

These are all valid private keys....  Just how many "NON valid" keys are in between each of the first 16 valid keys
and is there a pattern..Huh

I am a little rusty with my Base58 math skills and maybe I should have done it in WIF Compressed....

Read this post, just a few posts back:

https://bitcointalk.org/index.php?topic=1306983.msg13424809#msg13424809

If you want to know more please read the entire thread.  It is only 7 pages long.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
HugoTheSpider
Jr. Member
*
Offline Offline

Activity: 38
Merit: 0


View Profile
January 02, 2016, 11:05:50 PM
 #124

After  reading into this puzzle post ..I have a question maybe someone can answer

1   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
2   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAvUcVfH
...
F   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCMUnXUo

These are all valid private keys....  Just how many "NON valid" keys are in between each of the first 16 valid keys
and is there a pattern..Huh
What you posted weren't the actual raw private keys but the base58 encoded and WIF formatted version of the private keys with the information stating it's uncompressed.

The hex representation of a base58 encoded and WIF formatted uncompressed key is:
80 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX YYYYYYYY
The hex representation of a base58 encoded and WIF formatted compressed key is:
80 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 01 YYYYYYYY
where XX is the raw private key and YY the checksum.

Your question regarding "how many invalid keys are in between" is ambiguous. You might also consider to open a new thread to reach appropriate audience.

111111i4VTdHkzFqV2a4jntfZkdVk6B <-- only 31 chars
Gleb Gamow
Legendary
*
Offline Offline

Activity: 1428
Merit: 1118



View Profile
January 02, 2016, 11:10:32 PM
 #125

Quote
1   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf
2   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAvUcVfH
3   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB1FQ8BZ
4   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreB4AD8Yi
5   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBF8or94
6   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBKdE2NK
7   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBR6zCMU
8   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBbMaQX1
9   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBd7uGcN  
A   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBoNWTw6
B   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreBquB4Rj
C   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreC4p2u5o
D   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCAVyVnh
E   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCHK2Zzv
F   5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreCMUnXUo

NOW, that's interesting! I see a pattern that may now be solvable.

I see somebody has a jumpstart: https://bitcointalk.org/index.php?topic=1306983.msg13424809#msg13424809 But why Log(2)?
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1470
Merit: 1237


No I dont escrow anymore.


View Profile WWW
January 02, 2016, 11:25:38 PM
 #126

-snip-
I see somebody has a jumpstart: https://bitcointalk.org/index.php?topic=1306983.msg13424809#msg13424809 But why Log(2)?

Its an easy way to check whether the first bit is always 1 for a given step, which it is. Thus you can limit the search space. For step n you do not need to search for any possible solutions from step n-1.
CatsLikeToStretch
Jr. Member
*
Offline Offline

Activity: 31
Merit: 0


View Profile
January 02, 2016, 11:51:33 PM
 #127

Here are all keys from #1 to #40:
BitsHexDecimalBinaryAs raw textLog(2)
10000000001
1
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█     0
20000000003
3
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░██     1.5849625007212
30000000007
7
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░███     2.8073549220576
40000000008
8
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░░░     3
50000000015
21
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░█░█     4.3923174227788
60000000031
49
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░██░░░█    15.6147098441152
7000000004C
76
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░░██░░    L6.2479275134436
800000000E0
224
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░███░░░░░    à7.8073549220576
900000001D3
467
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░███░█░░██    Ó8.8672787397097
100000000202
514
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░░░░░░░█░     9.0056245491939
110000000483
1155
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░░█░░░░░██    ƒ10.173677136303
120000000A7B
2683
░░░░░░░░░░░░░░░░░░░░░░░░░░░░█░█░░████░██    {11.389631339261
130000001460
5216
░░░░░░░░░░░░░░░░░░░░░░░░░░░█░█░░░██░░░░░    `12.348728154231
140000002930
10544
░░░░░░░░░░░░░░░░░░░░░░░░░░█░█░░█░░██░░░░   )013.364134655008
1500000068F3
26867
░░░░░░░░░░░░░░░░░░░░░░░░░██░█░░░████░░██   hó14.713547616913
16000000C936
51510
░░░░░░░░░░░░░░░░░░░░░░░░██░░█░░█░░██░██░   É615.652564919611
17000001764F
95823
░░░░░░░░░░░░░░░░░░░░░░░█░███░██░░█░░████   vO16.548084361224
18000003080D
198669
░░░░░░░░░░░░░░░░░░░░░░██░░░░█░░░░░░░██░█     17.600007248708
19000005749F
357535
░░░░░░░░░░░░░░░░░░░░░█░█░███░█░░█░░█████   tŸ18.447724952285
2000000D2C55
863317
░░░░░░░░░░░░░░░░░░░░██░█░░█░██░░░█░█░█░█   ,U19.719530872026
2100001BA534
1811764
░░░░░░░░░░░░░░░░░░░██░███░█░░█░█░░██░█░░   ¥420.788963611792
2200002DE40F
3007503
░░░░░░░░░░░░░░░░░░█░██░████░░█░░░░░░████  -ä 21.520134745822
230000556E52
5598802
░░░░░░░░░░░░░░░░░█░█░█░█░██░███░░█░█░░█░  UnR22.416686729788
240000DC2A04
14428676
░░░░░░░░░░░░░░░░██░███░░░░█░█░█░░░░░░█░░  Ü* 23.782435585948
250001FA5EE5
33185509
░░░░░░░░░░░░░░░██████░█░░█░████░███░░█░█  ú^å24.984050066697
26000340326E
54538862
░░░░░░░░░░░░░░██░█░░░░░░░░██░░█░░██░███░  @2n25.700781261713
270006AC3875
111949941
░░░░░░░░░░░░░██░█░█░██░░░░███░░░░███░█░█  ¬8u26.738278526959
28000D916CE8
227634408
░░░░░░░░░░░░██░██░░█░░░█░██░██░░███░█░░░  ‘lè27.762143403295
290017E2551E
400708894
░░░░░░░░░░░█░██████░░░█░░█░█░█░█░░░████░  âU 28.577979290797
30003D94CD64
1033162084
░░░░░░░░░░████░██░░█░█░░██░░██░█░██░░█░░ =”Íd29.944419458082
31007D4FE747
2102388551
░░░░░░░░░█████░█░█░░███████░░███░█░░░███ }OçG30.969382178281
3200B862A62E
3093472814
░░░░░░░░█░███░░░░██░░░█░█░█░░██░░░█░███░ ¸b¦.31.526580209328
3301A96CA8D8
7137437912
░░░░░░░██░█░█░░█░██░██░░█░█░█░░░██░██░░░ ©l¨Ø32.732759144628
34034A65911D
14133072157
░░░░░░██░█░░█░█░░██░░█░██░░█░░░█░░░███░█ Je‘ 33.718356052473
3504AED21170
20112871792
░░░░░█░░█░█░███░██░█░░█░░░░█░░░█░███░░░░ ®Ò p34.227400038686
3609DE820A7C
42387769980
░░░░█░░███░████░█░░░░░█░░░░░█░█░░█████░░ Þ‚ |35.302929017097
371757756A93
100251560595
░░░█░███░█░█░███░███░█░█░██░█░█░█░░█░░██ Wuj“36.544833738747
3822382FACD0
146971536592
░░█░░░█░░░███░░░░░█░█████░█░██░░██░█░░░░"8/¬Ð37.096745824716
394B5F8303E9
323724968937
░█░░█░██░█░██████░░░░░██░░░░░░█████░█░░█K_ƒ é38.235977688802
40E9AE4933D6
1003651412950
███░█░░██░█░███░░█░░█░░█░░██░░████░█░██░é®I3Ö39.868395419757

Looks a lot like many of the Wolfram Automaton patterns, like this one:
werty98
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 04, 2016, 05:22:12 AM
 #128

Your results are from CPU or GPU?

What's your performance?
I was involved in the challenge and earned some BTC. I speedhacked the code in the mealtime at work straight after I saw the puzzle back in January 2015 and started it on some server remotely. The first version could do about 100,000 keys/s using a CPU. After some improvements I boosted the rate to 700,000 keys/s on a single computer. Later I ran it on many computers and checked million of keys/s. Luckly I could recycle the code later in the August 2015 puzzle at https://bitcointalk.org/index.php?topic=1144807.0
I had no time to learn how to code on a GPU.

I've tried my first version using openssl and got about 25,000 keys/s (single-thread). You seem to use something other than openssl.

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count. Thus, speed-up on SIMD processors (e.g. GPUs) won't be great.

BTW, whoever created this challenge will be able to manipulate BTC price, won't she/he?

1PoorLkEZeAeww7RZ6FR3wyh9utuBrUYFL
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 09:03:28 AM
 #129

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P3 = P1 + P2) to have a very predictable machine cycle count.  It should be something like:

x3 = λ2+a1λ−a2−x1−x2

y3 = −a1x3−a3−λx3+λx1−y1

λ = (y2−y1) / (x2−x1)

From:  https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
werty98
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 04, 2016, 09:24:18 AM
 #130

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P3 = P1 + P2) to have a very predictable machine cycle count.  It should be something like:

x3 = λ2+a1λ−a2−x1−x2

y3 = −a1x3−a3−λx3+λx1−y1

λ = (y2−y1) / (x2−x1)

From:  https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html

I did use that EC point increment method, otherwise the program would be 20x slower. Those multiplications/divisions are modulus but not conventional integer operators; they don't have predictable machine cycle count.

1PoorLkEZeAeww7RZ6FR3wyh9utuBrUYFL
dalek
Sr. Member
****
Offline Offline

Activity: 387
Merit: 250



View Profile
January 04, 2016, 10:23:45 AM
 #131

I've tried my first version using openssl and got about 25,000 keys/s (single-thread). You seem to use something other than openssl.

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count. Thus, speed-up on SIMD processors (e.g. GPUs) won't be great.
I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.

           ▄▄█████████▄▄
       ▄████▀▀       ▀▀████▄
     ▄██▀▀               ▀▀██▄
    ██▀                    ████
   ██                     ███▀██
  ██                    ▄██▀   ██
 ██                    ▄██      ██
██▀                  ▄██▀      ▄███
██                  ▄██      ▄██▀██
██                 ██▀    ▄███▀  ██
██               ▄██▀   ▄██▀     ██
██▄             ▄██  ▄███▀      ▄██
 ██           ▄██▀ ▄██▀         ██
  ██         ▄██▄███▀          ██
   ██       █████▀            ██
    ██▄   ▄████▀            ▄██
     ▀██▄███▀            ▄▄██▀
       ▀████▄▄       ▄▄████▀
           ▀▀█████████▀▀
L I V E T R E E   A D E P T TM
Own the future of entertainment
The World's 1st Community-Powered,
Film, TV and Content Network  ★
Bulista
Member
**
Offline Offline

Activity: 126
Merit: 10


View Profile
January 04, 2016, 11:09:31 AM
 #132

Guys with brute force we won't go anywhere.

Let us assume we would be able somehow to generate a brute force of 5 TH/s (The max ASIC Miner speed today that I found out there).

That's like 5000000000000 Hashes per second. Of course with CPU/GPU we won't get anywhere near.

But let us assume for a second that this performance would be possible somehow, we would need ~303150594339750000000000000000000000000000000000000000000 years to break until the address 256 already counting with starting each address generation from 2^X-1. (EDIT: Not even counting with all the addresses before Smiley)

So it's kind of useless to brute force this.

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P3 = P1 + P2) to have a very predictable machine cycle count.  It should be something like:

x3 = λ2+a1λ−a2−x1−x2

y3 = −a1x3−a3−λx3+λx1−y1

λ = (y2−y1) / (x2−x1)

From:  https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html

How precise is this formula?
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 12:06:45 PM
 #133

It is impossible to get all the rewards.

It is possible to get the next reward (0.051 BTC) in the sequence.

There are only 1,125,899,906,842,620 possible keys for the next unclaimed reward of 0.051 BTC.

At your rate of 5,000,000,000,000 trial per second it would only take a bit over 225 seconds to try all of them.

There is no hope of getting all the remaining rewards but it should be totally possible to get a few more small rewards from the sequence.


Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
werty98
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 04, 2016, 12:14:04 PM
 #134

I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.

Do you know why EC_POINT_point2oct is slow? I called EC_POINT_get_affine_coordinates_GFp instead, but they seem to do the same thing. If EC_POINT_add stores the point in Cartesian coordination (X-Y), will extracting the public key be a trivial task?

Guys with brute force we won't go anywhere.

How precise is this formula?

I think all of us know that brute force is not viable for sure, but it is fun to estimate how long it will take to break the 51st, 52nd, ... addresses.

That division isn't the conventional division. It has perfect precision (http://www.johannes-bauer.com/compsci/ecc/#anchor07).

1PoorLkEZeAeww7RZ6FR3wyh9utuBrUYFL
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 12:22:38 PM
 #135

This is a basic description of the algorithm which should yield the fastest results:


Code:
Initialization:

Set BitcoinAddresses[256] = the list of bitcoin addresses from the transaction, binary form without the checksum
Set BitcoinAddressIndex = 0;
Set PrivateKey = 1;
Set PublicKey = G;

Loop Until BitcoinAddressIndex == 256: // == "forever"

Call Convert PublicKey to BitcoinAddress [but just to the binary form, do not calculate the checksum or encode to ASCII]

If BitcoinAddress == BitcoinAddresses[BitcoinAddressIndex] Then

    Log BitcoinAddressIndex, PrivateKey, PublicKey, BitcoinAddress

    Create transaction and claim Bitcoins if any available at BitcoinAddress

Endif

++PrivateKey;

Call Increment PublicKey by G // Highly optimized, very specialized function to just compute PublicKey = PublicKey + G

EndLoop

Note on the PublicKey to BitcoinAddress conversion function:

You only need to do the first 3 of the 9 steps in this process.

1 - Take the PublicKey and format it properly (add the 1 byte of 0x04, change to compressed form if needed)
2 - Perform SHA-256 hashing on the result
3 - Perform RIPEMD-160 hashing on the result of SHA-256

This result can be compared directly to the BitcoinAddresses[] array assuming you have stored the 256 Bitcoin addresses in the proper binary form.

To get the proper values for this array simply undo the last 6 steps of the PublicKey to BitcoinAddress function for each of the 256 Bitcoin addresses in the transaction:

1 - Decode the base58 string to a binary byte array
2 - Strip off the 4 checksum bytes from the tail
3 - Strip off the version byte (0x00) from the front
4 - Store the result in the array

Which step above is using the slow EC_POINT_point2oct function?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 12:32:35 PM
 #136

Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P3 = P1 + P2) to have a very predictable machine cycle count.  It should be something like:

x3 = λ2+a1λ−a2−x1−x2

y3 = −a1x3−a3−λx3+λx1−y1

λ = (y2−y1) / (x2−x1)

From:  https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html

How precise is this formula?

That is the mathematics behind the point addition.  The actual implementation of point addition would be optimized and very different.  

I was just trying to make the point that a single point addition operation should take the same amount of time (same number of machine instructions) no matter what the actual point values are.

This is in contrast to the scalar multiplication function P = p*G which will take different amounts of time (different numbers of machine instructions) depending on the value of p.

But I see now that the division operation (or equivalently calculating the inverse of the denominator) could take varying amounts of time.

So, basically I was wrong because we have to calculate λ to add the two points.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 12:55:27 PM
 #137

BTW, whoever created this challenge will be able to manipulate BTC price, won't she/he?
I am not sure exactly what you mean.  I do see a scenario where the creator of the challenge could possibly cause a panic sell off.  Is that what you are talking about?

The creator still has the private keys so they can spend the rewards at any time.  So, they could claim a bunch of the rewards thus simulating a weakness in the Bitcoin crypto?  This could possibly cause a panic sell off if the market believed it?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Bulista
Member
**
Offline Offline

Activity: 126
Merit: 10


View Profile
January 04, 2016, 01:00:40 PM
 #138

I get the same performance as you, but EC_POINT_add isn't the slowest step, it's the call to EC_POINT_point2oct.

Do you know why EC_POINT_point2oct is slow? I called EC_POINT_get_affine_coordinates_GFp instead, but they seem to do the same thing. If EC_POINT_add stores the point in Cartesian coordination (X-Y), will extracting the public key be a trivial task?

Guys with brute force we won't go anywhere.

How precise is this formula?

I think all of us know that brute force is not viable for sure, but it is fun to estimate how long it will take to break the 51st, 52nd, ... addresses.

That division isn't the conventional division. It has perfect precision (http://www.johannes-bauer.com/compsci/ecc/#anchor07).

Well we wont get 5 TH/s or anything close for sure, but if we were able to generate 100 million keys per second we would break the #51 in about 3.5 months... And I believe it will be very hard to get to 100 million / s even with GPU.

Yes of course we can try it for the fun, but it wont be much fun when you get home and your GPU is burning plus your electricity bill Cheesy

But of course if your formula brings down the range of keys to generate then we can have some chance.

So, basically I was wrong because we have to calculate λ to add the two points.

If you find the right formula can you post the results for each address so we know exactly what ranges we can count with?
BurtW
Legendary
*
Offline Offline

Activity: 2282
Merit: 1006

All paid signature campaigns should be banned.


View Profile WWW
January 04, 2016, 01:10:45 PM
 #139

If you find the right formula can you post the results for each address so we know exactly what ranges we can count with?
So far there is nothing to indicate that there is a "right formula" to predict the next private key given all the found private keys.

I believe the underlying sequence of private keys before masking to produce the shortened values was probably a secure RNG.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
werty98
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 04, 2016, 01:25:03 PM
 #140

BTW, whoever created this challenge will be able to manipulate BTC price, won't she/he?
I am not sure exactly what you mean.  I do see a scenario where the creator of the challenge could possibly cause a panic sell off.  Is that what you are talking about?

The creator still has the private keys so they can spend the rewards at any time.  So, they could claim a bunch of the rewards thus simulating a weakness in the Bitcoin crypto?  This could possibly cause a panic sell off if the market believed it?

Yeah, that's what I meant  Grin

Anyway, as Einstein said, investors' behavior is the only thing in this universe that does not follow any physics law.

1PoorLkEZeAeww7RZ6FR3wyh9utuBrUYFL
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!