Maybe these random-like numbers came from hashing operations? For example: n-th key = truncate(SHA256(f((n-1)-th key))). It will be still hopeless if the process involves a strong passphrase though.
I think this would be a good way to do it. Then the author just needs to remember the seed and algorithm instead of remembering 256 private keys. Although keeping track of 256 private keys is not that hard in the first place. The algorithm would need to "skip over" any private keys in the generated sequence that had the undesirable result of a 0 in the most significant bit after the masking operation. |
|
|
|
EDIT: this formula doesn't make any sense I know, just playing around  Just for fun the average of this: 1.00000000
1.50000000
1.75000000
1.00000000
1.31250000
1.53125000
1.18750000
1.75000000
1.82421875
1.00390625
1.12792969
1.31005859
1.27343750
1.28710938
1.63983154
1.57196045
1.46214294
1.51572418
1.36388779
1.64664650
1.72783279
1.43408918
1.33485842
1.72003222
1.97801048
1.62538475
1.66818412
1.69600850
1.49275696
1.92441434
1.95800192
1.44051053
1.66181426
1.64530614
1.17072322
1.23364647
1.45885221
1.06935867
1.17770458
1.82563129
Is 1.482530615 So starting at 1.482530615 into the next range and doing a butterfly search might be a tiny bit faster. |
|
|
|
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
This was known from page 1 of this thread. |
|
|
|
Here are the results for the values we know given those 2 mentioned formulas: y = 2^n * x and so x = y / 2^n AND y = 2^n + x and so x = y - 2^n | n | Known Results (y) | x = y / 2^n | x = y - 2^n | | 0 | 1 | 1.00000000 | 0
| | 1 | 3 | 1.50000000 | 1
| | 2 | 7 | 1.75000000 | 3
| | 3 | 8 | 1.00000000 | 0
| | 4 | 21 | 1.31250000 | 5
| | 5 | 49 | 1.53125000 | 17
| | 6 | 76 | 1.18750000 | 12
| | 7 | 224 | 1.75000000 | 96
| | 8 | 467 | 1.82421875 | 211
| | 9 | 514 | 1.00390625 | 2
| | 10 | 1155 | 1.12792969 | 131
| | 11 | 2683 | 1.31005859 | 635
| | 12 | 5216 | 1.27343750 | 1120
| | 13 | 10544 | 1.28710938 | 2352
| | 14 | 26867 | 1.63983154 | 10483
| | 15 | 51510 | 1.57196045 | 18742
| | 16 | 95823 | 1.46214294 | 30287
| | 17 | 198669 | 1.51572418 | 67597
| | 18 | 357535 | 1.36388779 | 95391
| | 19 | 863317 | 1.64664650 | 339029
| | 20 | 1811764 | 1.72783279 | 763188
| | 21 | 3007503 | 1.43408918 | 910351
| | 22 | 5598802 | 1.33485842 | 1404498
| | 23 | 14428676 | 1.72003222 | 6040068
| | 24 | 33185509 | 1.97801048 | 16408293
| | 25 | 54538862 | 1.62538475 | 20984430
| | 26 | 111949941 | 1.66818412 | 44841077
| | 27 | 227634408 | 1.69600850 | 93416680
| | 28 | 400708894 | 1.49275696 | 132273438
| | 29 | 1033162084 | 1.92441434 | 496291172
| | 30 | 2102388551 | 1.95800192 | 1028646727
| | 31 | 3093472814 | 1.44051053 | 945989166
| | 32 | 7137437912 | 1.66181426 | 2842470616
| | 33 | 14133072157 | 1.64530614 | 5543137565
| | 34 | 20112871792 | 1.17072322 | 2933002608
| | 35 | 42387769980 | 1.23364647 | 8028031612
| | 36 | 100251560595 | 1.45885221 | 31532083859
| | 37 | 146971536592 | 1.06935867 | 9532583120
| | 38 | 323724968937 | 1.17770458 | 48847061993
| | 39 | 1003651412950 | 1.82563129 | 453895599062
|
I think that what you have done is to pretty much prove it is random and there is no predictive formula. |
|
|
|
|
Why stop at fitting 2, 3, 4, etc. Keys? Now that we know the first 40 private keys it would be very easy to enter all 40 keys and get a polynomial to perfectly fit all 40 keys. Unfortunately the function will not predict the 41st key.
|
|
|
|
|
amaclin,
Do you happen to know anything about the author of the trasaction?
Just curios.
|
|
|
|
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. |
|
|
|
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? |
|
|
|
Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P 3 = P 1 + P 2) to have a very predictable machine cycle count. It should be something like: x 3 = λ 2+a 1λ−a 2−x 1−x 2y 3 = −a 1x 3−a 3−λx 3+λx 1−y 1λ = (y 2−y 1) / (x 2−x 1) From: https://crypto.stanford.edu/pbc/notes/elliptic/explicit.htmlHow 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. |
|
|
|
This is a basic description of the algorithm which should yield the fastest results: 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? |
|
|
|
|
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.
|
|
|
|
Unlike hash operations, elliptic curve operations have unpredictable machine cycle count.
I would expect a single point addition operation (P 3 = P 1 + P 2) to have a very predictable machine cycle count. It should be something like: x 3 = λ 2+a 1λ−a 2−x 1−x 2y 3 = −a 1x 3−a 3−λx 3+λx 1−y 1λ = (y 2−y 1) / (x 2−x 1) From: https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html |
|
|
|
It can be informative to just look at a transaction. I picked this one out of the current transaction stream totally at random: https://blockchain.info/tx/026ba26cb6871596382a72a69973426e605280fa0d454aa8c39c55aee8309874Notice two outputs of previous transactions being used as inputs to this transaction: 0.08224623 BTC and 0.00010820 BTC = 0.08235443 BTC And the outputs of this transaction are: 0.03074088 BTC and 0.05150535 BTC = 0.08224623 BTC Of course the total of the outputs must be less than or equal to the total of the inputs. In this case the difference between the total outputs and total inputs is: 0.08235443 BTC - 0.08224623 BTC = 0.00010820 BTC This difference (fee) goes to the miner that successfully includes this transaction in a block. Looking further down on that page you can see the actual input scripts and output scripts as described above. |
|
|
|
I like the sound of bits much more than mBTC though, but I'm afraid the value needs to increase substantially to be able to use bits in daily life.
Just to be clear 1 bit = 1 uBTC, not 1 mBTC. |
|
|
|
|
I am glad Danny answered that question so well that I have nothing to add but I will watch this thread to see if I can answer any future questions.
|
|
|
|
Why are people so dug into the change of the common unit that we are identifying bitcoin by. There are a lot of numbers, but why would you want to divide that by 100??? That just does not make much sense to me. Someone please explain the benefit to me.
The divide by 100 you are asking about is because there are 100,000,000 Satoshis per BTC giving us 100 Satoshis per microBitcoin [=uBTC=Bits=XBT]: Bits (XBT) [Bitcents]
Bitcoins (BTC) milliBitcoins (mBTC) microBitcoins (uBTC) Satoshis
-------------- -------------------- -------------------- -----------
1.0 1,000.0 1,000,000.00 100,000,000
0.001 1.0 1,000.00 100,000
0.000 001 0.001 1.00 100
0.000 000 01 0.000 01 0.01 1
|
|
|
|
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..  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#msg13424809If you want to know more please read the entire thread. It is only 7 pages long. |
|
|
|
Please read this entire thread: https://bitcointalk.org/index.php?topic=592691.0;topicseenEverything that could possibly be said on this subject has already been said in that thread. Why not just resurrect that thread instead of starting a new one? Here is/was my opinion from that thread: 1 bit is also 1/8 of one USD.
Seeing all the hoopla over BTC versus XBT I would support the following:
1 BTC = 1 Bitcoin = same as it ever was
1 XBT = 1 Bit = 0.000001 BTC
1000000 XBT (Bit) = 1 BTC (Bitcoin)
I would be behind this 100% as it "fixes" the whole BTC/XBT issue and give those who have been worried about the size of the BTC something to use.
Bit is fine. In fact there is already a very famous song about it "shave and a haircut, two bits". That should be our goal. Bitcoin acceptance to the level that a shave and a haircut costs two bits.
Everyone who agrees just needs to start using it, explaining it, publishing it, correcting other (anoying them), etc. It will either catch on or it won't. This is what I hope catches on:
1 satoshi = smallest unit, pretty much in general use today
= "bitcents" also makes some sense and may catch on and evolve back into cents (1/100th)
1 bit = 100 satoshi, eventually every day use, coffee, sandwiches, etc.
1 XBT = 1 bit, should be the official symbol on all exchanges, forex, etc.
1 BTC = 1000000 bits = kept for dealing with larger amounts, may fade
1 Bitcoin/bitcoin as a currency unit fades away
Bitcoin = the Bitcoin protocol
If you look at my post history on this subject you would find that I mostly thought the idea of any renaming was stupid and not needed.
That is, until I started talking to people and did run into "Bitcoins are way too expensive" over and over again.
Logically it makes no sense but I could sell a boatload of bits at 2500 bits per dollar to the general public and could see the price rising pretty quickly to 1000 bits per dollar over the next few months.
It is not logical but I have come to the conclusion that the general public is not logical when it comes to money.
When introduced to the idea "1 bit = 100 satoshi", without exception, everyone I have talked to has just lit up, understood it and are now running with the idea to all their friends.
That is how you accomplish this. Just do it. Everyone will thank you later.
1 XBT = 1 bit = 100 satoshis
1 BTC = 1000000 XBT = shorthand used in larger transactions
|
|
|
|
people will mine as much as they can.
You do not know how mining works, do you? The more people mining the harder it gets so, on average, the number of Bitcoins mined is very well controlled no matter how much effort is put into mining. Currently 25 Bitcoins are mined about every 10 minutes - that cannot be changed and does not change, no matter what the people do. |
|
|
|
I worry about the US dollar and all other currencies because: Having so many scammers makes me worried.
Why would people buy bitcoin use dollars if they know so many people are willing to scam them.
Even worse if so many people use it dollars for illegal things...
|
|
|
|
|
Show Posts
