The point here is that there are NO ADDRESSES in the blockchain or in transactions. Addresses are an abstraction that wallets use to make it easier for us humans to talk about exchanging control over value. The wallets convert those addresses into scripts. If we want another script type, we can just create a new "address" representation of that script. As far as I'm aware, we currently have 3 "standard" script types: - Pay2PubKeyHash
- Pay2PubKey
- Pay2ScriptHash
If we look at the first transaction of the bitcoin history (it should be a Pay2PubKey transaction) this is the script: 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee OP_CHECKSIG
and this is the abstraction-address: 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX How can I distinguish between this address and an address that is related to a Pay2PubKeyHash? The wallets convert those addresses into scripts.
How do the wallets know if the address 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX should be converted in a Pay2PubKey script or in a Pay2PubKeyHash script? |
|
|
|
What version of Bitcoin Core are you running?
0.13.2 |
|
|
|
0.95.99.2-testing_win64.exe: Log file opened at 1492164611: C:\Users\Antonio\AppData\Roaming/Armory/dbLog.txt
-INFO - 1492164611: (..\main.cpp:23) Running on 2 threads
-INFO - 1492164611: (..\main.cpp:24) Ram usage level: 1
-INFO - 1492164611: (..\BlockUtils.cpp:907) blkfile dir: G:\blockchain/blocks
-INFO - 1492164611: (..\BlockUtils.cpp:908) lmdb dir: C:\Users\Antonio\AppData\Roaming/Armory/databases
-INFO - 1492164611: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1492164612: (..\BitcoinP2P.cpp:947) Connected to Bitcoin node
-ERROR - 1492164612: (..\nodeRPC.cpp:150) unexpected cookie file content
-ERROR - 1492164613: (..\nodeRPC.cpp:150) unexpected cookie file content
-INFO - 1492164613: (..\BlockUtils.cpp:1091) Executing: doInitialSyncOnLoad
-INFO - 1492164613: (..\DatabaseBuilder.cpp:169) Reading headers from db
-WARN - 1492164613: (..\lmdb_wrapper.cpp:1175) No headers in DB yet!
-INFO - 1492164613: (..\DatabaseBuilder.cpp:208) Found 1 headers in db
-INFO - 1492164613: (..\DatabaseBuilder.cpp:51) updating HEADERS db
-INFO - 1492164620: (..\DatabaseBuilder.cpp:268) parsed block file #1
-INFO - 1492164631: (..\DatabaseBuilder.cpp:268) parsed block file #3
-INFO - 1492164643: (..\DatabaseBuilder.cpp:268) parsed block file #5
-INFO - 1492164660: (..\DatabaseBuilder.cpp:268) parsed block file #7
-INFO - 1492164673: (..\DatabaseBuilder.cpp:268) parsed block file #9
-INFO - 1492164682: (..\DatabaseBuilder.cpp:268) parsed block file #11
-INFO - 1492164692: (..\DatabaseBuilder.cpp:268) parsed block file #13
-INFO - 1492164701: (..\DatabaseBuilder.cpp:268) parsed block file #15
-INFO - 1492164709: (..\DatabaseBuilder.cpp:268) parsed block file #17
-INFO - 1492164718: (..\DatabaseBuilder.cpp:268) parsed block file #19
-INFO - 1492164726: (..\DatabaseBuilder.cpp:268) parsed block file #21
-INFO - 1492164735: (..\DatabaseBuilder.cpp:268) parsed block file #23
-INFO - 1492164743: (..\DatabaseBuilder.cpp:268) parsed block file #25
-ERROR - 1492164747: (..\BlockDataMap.cpp:79) merkle root mismatch!
-ERROR - 1492164747: (..\BlockDataMap.cpp:80) header has: 9a6d8750cc8847f72c0c0fe01e079868791308df02a98fe4dc6e0e838f38b87d
-ERROR - 1492164747: (..\BlockDataMap.cpp:81) block yields: 3f13e511dbc811b68e17b15a4c4064252bb63108d427dc6381d3b898a7433c0a
-ERROR - 1492164747: (..\DatabaseBuilder.cpp:353) block deser except: invalid merkle root
-INFO - 1492164747: (..\DatabaseBuilder.cpp:477) Found next block after skipping 269696bytes
-ERROR - 1492164747: (..\DatabaseBuilder.cpp:353) block deser except:
-INFO - 1492164752: (..\DatabaseBuilder.cpp:268) parsed block file #27
-INFO - 1492164761: (..\DatabaseBuilder.cpp:268) parsed block file #29
-INFO - 1492164769: (..\DatabaseBuilder.cpp:268) parsed block file #31
-INFO - 1492164778: (..\DatabaseBuilder.cpp:268) parsed block file #33
-INFO - 1492164786: (..\DatabaseBuilder.cpp:268) parsed block file #35
-INFO - 1492164795: (..\DatabaseBuilder.cpp:268) parsed block file #37
-INFO - 1492164802: (..\DatabaseBuilder.cpp:268) parsed block file #39
-INFO - 1492164811: (..\DatabaseBuilder.cpp:268) parsed block file #41
-INFO - 1492164827: (..\DatabaseBuilder.cpp:268) parsed block file #43
-INFO - 1492164843: (..\DatabaseBuilder.cpp:268) parsed block file #45
-INFO - 1492164869: (..\DatabaseBuilder.cpp:268) parsed block file #47
-INFO - 1492164879: (..\DatabaseBuilder.cpp:268) parsed block file #49
-INFO - 1492164896: (..\DatabaseBuilder.cpp:268) parsed block file #51
-INFO - 1492165012: (..\DatabaseBuilder.cpp:268) parsed block file #53
-INFO - 1492165019: (..\DatabaseBuilder.cpp:268) parsed block file #55
-INFO - 1492165046: (..\DatabaseBuilder.cpp:268) parsed block file #57
-INFO - 1492165074: (..\DatabaseBuilder.cpp:268) parsed block file #59
-INFO - 1492165189: (..\DatabaseBuilder.cpp:268) parsed block file #61
-INFO - 1492165196: (..\DatabaseBuilder.cpp:268) parsed block file #63
-INFO - 1492165217: (..\DatabaseBuilder.cpp:268) parsed block file #65
-INFO - 1492165246: (..\DatabaseBuilder.cpp:268) parsed block file #67
-INFO - 1492165273: (..\DatabaseBuilder.cpp:268) parsed block file #69
-INFO - 1492165376: (..\DatabaseBuilder.cpp:268) parsed block file #71
-INFO - 1492165482: (..\DatabaseBuilder.cpp:268) parsed block file #73
-INFO - 1492165489: (..\DatabaseBuilder.cpp:268) parsed block file #75
-INFO - 1492165553: (..\DatabaseBuilder.cpp:268) parsed block file #77
-INFO - 1492165658: (..\DatabaseBuilder.cpp:268) parsed block file #79
-INFO - 1492165665: (..\DatabaseBuilder.cpp:268) parsed block file #81
-INFO - 1492165695: (..\DatabaseBuilder.cpp:268) parsed block file #83
-INFO - 1492165731: (..\DatabaseBuilder.cpp:268) parsed block file #85
-INFO - 1492165827: (..\DatabaseBuilder.cpp:268) parsed block file #87
-INFO - 1492165834: (..\DatabaseBuilder.cpp:268) parsed block file #89
-INFO - 1492165867: (..\DatabaseBuilder.cpp:268) parsed block file #91
-INFO - 1492165905: (..\DatabaseBuilder.cpp:268) parsed block file #93
-INFO - 1492166009: (..\DatabaseBuilder.cpp:268) parsed block file #95
-INFO - 1492166015: (..\DatabaseBuilder.cpp:268) parsed block file #97
-INFO - 1492166034: (..\DatabaseBuilder.cpp:268) parsed block file #99
-INFO - 1492166065: (..\DatabaseBuilder.cpp:268) parsed block file #101
-INFO - 1492166156: (..\DatabaseBuilder.cpp:268) parsed block file #103
-INFO - 1492166163: (..\DatabaseBuilder.cpp:268) parsed block file #105
-INFO - 1492166193: (..\DatabaseBuilder.cpp:268) parsed block file #107
-INFO - 1492166216: (..\DatabaseBuilder.cpp:268) parsed block file #109
-INFO - 1492166284: (..\DatabaseBuilder.cpp:268) parsed block file #111
-INFO - 1492166355: (..\DatabaseBuilder.cpp:268) parsed block file #113
-INFO - 1492166374: (..\DatabaseBuilder.cpp:268) parsed block file #115
-INFO - 1492166403: (..\DatabaseBuilder.cpp:268) parsed block file #117
-INFO - 1492166427: (..\DatabaseBuilder.cpp:268) parsed block file #119
-INFO - 1492166537: (..\DatabaseBuilder.cpp:268) parsed block file #121
-INFO - 1492166623: (..\DatabaseBuilder.cpp:268) parsed block file #122
-INFO - 1492166634: (..\DatabaseBuilder.cpp:268) parsed block file #123
-INFO - 1492166641: (..\DatabaseBuilder.cpp:268) parsed block file #125
-INFO - 1492166669: (..\DatabaseBuilder.cpp:268) parsed block file #127
-INFO - 1492166698: (..\DatabaseBuilder.cpp:268) parsed block file #128
-INFO - 1492166713: (..\DatabaseBuilder.cpp:268) parsed block file #130
-INFO - 1492166731: (..\DatabaseBuilder.cpp:268) parsed block file #132
-INFO - 1492166779: (..\DatabaseBuilder.cpp:268) parsed block file #134
-INFO - 1492166820: (..\DatabaseBuilder.cpp:268) parsed block file #135
-INFO - 1492166844: (..\DatabaseBuilder.cpp:268) parsed block file #136
-INFO - 1492166851: (..\DatabaseBuilder.cpp:268) parsed block file #138
-INFO - 1492166858: (..\DatabaseBuilder.cpp:268) parsed block file #140
-INFO - 1492166864: (..\DatabaseBuilder.cpp:268) parsed block file #142
-INFO - 1492166871: (..\DatabaseBuilder.cpp:268) parsed block file #144
-INFO - 1492166939: (..\DatabaseBuilder.cpp:268) parsed block file #145
-INFO - 1492166955: (..\DatabaseBuilder.cpp:268) parsed block file #146
-INFO - 1492166961: (..\DatabaseBuilder.cpp:268) parsed block file #148
-INFO - 1492166996: (..\DatabaseBuilder.cpp:268) parsed block file #150
-INFO - 1492167022: (..\DatabaseBuilder.cpp:268) parsed block file #152
-INFO - 1492167097: (..\DatabaseBuilder.cpp:268) parsed block file #153
-INFO - 1492167122: (..\DatabaseBuilder.cpp:268) parsed block file #154
-INFO - 1492167146: (..\DatabaseBuilder.cpp:268) parsed block file #156
-INFO - 1492167176: (..\DatabaseBuilder.cpp:268) parsed block file #158
-INFO - 1492167224: (..\DatabaseBuilder.cpp:268) parsed block file #159
-INFO - 1492167253: (..\DatabaseBuilder.cpp:268) parsed block file #161
-INFO - 1492167279: (..\DatabaseBuilder.cpp:268) parsed block file #163
-INFO - 1492167320: (..\DatabaseBuilder.cpp:268) parsed block file #164
-INFO - 1492167346: (..\DatabaseBuilder.cpp:268) parsed block file #166
-INFO - 1492167370: (..\DatabaseBuilder.cpp:268) parsed block file #168
-ERROR - 1492167412: (..\DatabaseBuilder.cpp:353) block deser except:
-INFO - 1492167412: (..\DatabaseBuilder.cpp:477) Found next block after skipping 323840bytes
-INFO - 1492167412: (..\DatabaseBuilder.cpp:268) parsed block file #169
-INFO - 1492167438: (..\DatabaseBuilder.cpp:268) parsed block file #171
-INFO - 1492167468: (..\DatabaseBuilder.cpp:268) parsed block file #173
-INFO - 1492167512: (..\DatabaseBuilder.cpp:268) parsed block file #174
-INFO - 1492167539: (..\DatabaseBuilder.cpp:268) parsed block file #176
-INFO - 1492167565: (..\DatabaseBuilder.cpp:268) parsed block file #178
-INFO - 1492167605: (..\DatabaseBuilder.cpp:268) parsed block file #179
-INFO - 1492167632: (..\DatabaseBuilder.cpp:268) parsed block file #181
-INFO - 1492167663: (..\DatabaseBuilder.cpp:268) parsed block file #183
-INFO - 1492167708: (..\DatabaseBuilder.cpp:268) parsed block file #184
-INFO - 1492167735: (..\DatabaseBuilder.cpp:268) parsed block file #186
-INFO - 1492167761: (..\DatabaseBuilder.cpp:268) parsed block file #188
-INFO - 1492167814: (..\DatabaseBuilder.cpp:268) parsed block file #189
-INFO - 1492167834: (..\DatabaseBuilder.cpp:268) parsed block file #191
-INFO - 1492167862: (..\DatabaseBuilder.cpp:268) parsed block file #193
-INFO - 1492167896: (..\DatabaseBuilder.cpp:268) parsed block file #194
-INFO - 1492167921: (..\DatabaseBuilder.cpp:268) parsed block file #196
-INFO - 1492167945: (..\DatabaseBuilder.cpp:268) parsed block file #198
-INFO - 1492168007: (..\DatabaseBuilder.cpp:268) parsed block file #199
-INFO - 1492168034: (..\DatabaseBuilder.cpp:268) parsed block file #201
-INFO - 1492168052: (..\DatabaseBuilder.cpp:268) parsed block file #202
-ERROR - 1492168089: (..\BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread
-INFO - 1492168089: (..\BitcoinP2P.cpp:969) Disconnected from Bitcoin node
|
|
|
|
In other words: from a single private key k, how many different addresses can we get? You can get virtually unlimited number of P2SH addresses for a single private key. You just need to hash a script with some kind of nonce. For instance, it could be 1 of 2 mulitisig, where the second key is a random number. Then in this script:
{1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG}
instead of pubkey2 I can put any string with any lenght? |
|
|
|
I have a doubt about the use of: Pay to Pubkey Hash address (P2PKH): 17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem
Pay to script hash address (P2SH) : 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX
I know that the starting "1" and "3" are added after sha256 + ripemd160, to get "1" I have to add a "00" prefix and to get "3" a "05" prefix before the Base58 encoding. So, let's imagine I have a private key k, then I compute the public key kG : (x,y), then I perform sha256(ripemd160(x,y)). Now I have a 160bit string s. My question is: if i made a Base58 encoding of "05+s" instead of "00+s" and I got the address 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX, I could spend the bitcoin of that address? In other words: from a single private key k, how many different addresses can we get? Surely there are at least 2 pubkey hash addresses (compressed and uncompressed public key), but in theory is it possible to get a pay to script address too from a single private key? |
|
|
|
So: 1 - (1 - p)k for the number we want to show. Yes?
k is the number of trials left to do (that's our 2space - 2done)
and probability is simply 1/2space. Yes?
You have a different idea (different from mine) of the situation: you think that there are 2^135 addresses (space search) and that there is surely the address you are looking for. If this is the model, you cannot use the geometric distribution, because it admit you could never find that address. Probability 1/2^135 doesn't mean that you will get surely your address after 2^135 tries. But if you want to think in this way, I wrote this formula : https://www.dropbox.com/s/bulinnhroay5cg2/Probability%20of%201%20collision%20for%20k.pdf?dl=0EDIT: I made a mistake, I computed another probability  Use your formula. Shame we have lost 10-15 "0" in 1 day!!!  |
|
|
|
We have 2135.2 Bernoulli trials, where we - for simplicity now - claim, that the probability to observe the event "collision" is 1 after all these trials were done. Ok?
Yes, it is right. So: 1 - (1 - p)k for the number we want to show. Yes?
k is the number of trials left to do (that's our 2space - 2done)
and probability is simply 1/2space. Yes?
Can someone check/confirm so I can hack that in?
You have to use Bayes' theorem and/or conditional probability. Give me some time, I think about it. |
|
|
|
Your last one is correct: 1 / (2 ** $space - 2 ** $bits)
As might be the one you had before.
But see, at some point it will be 1 / 1 = 1 ==> 100% probabilty.
That point is when you have searched all but the very last key.
Then you check the very last key (being certain it will hit) and after that your calculation expires that's true but not relevant then :-)
So the last day your probability will be: 1/1 * 2,2G = 2,2G  EDIT: every time you generate a key , you have always the same probability. You can talk only about the probability in n tries... |
|
|
|
Well - I have now 1 / (2 ** $space - 2 ** $bits)
but are we sure this is correct?, because if (in some distant time) $bits should approach $space, we'd get 0 in the denominator, meaning infinite probability. And should we somehow jump over this 0, we'd get negative probability when - in fact - we should have a constant expectation. However - if I have "1 / (2 ** ($space - $bits));" we'd get probability 1 for the case we search through $space. So certainly that simple subtraction above cannot be it. Rico if you want to use a correct formula, you have to use a geometric distribution --> https://en.wikipedia.org/wiki/Geometric_distributionAssumptions: When is the geometric distribution an appropriate model?
The geometric distribution is an appropriate model if the following assumptions are true.
The phenomenon being modelled is a sequence of independent trials.
There are only two possible outcomes for each trial, often designated success or failure.
The probability of success, p, is the same for every trial.
If these conditions are true, then the geometric random variable is the count of the number of failures before the first success. The possible number of failures before the first success is 0, 1, 2, 3, and so on. The geometric random variable Y is the number of failures before the first success. |
|
|
|
So to sum up - how is this number going to be bigger? - With more addresses with funds on them
- In time, as more space is searched
- With higher search speed
From what I can see, the number of addresses with funds has the most effect at the moment. In my opinion, the number of addresses is essentially, much more than your formula shows. I'm almost sure that, with 2^159 keys, we could generate only 2/3 of all 2^160 addresses. Now 14,9M (2^24) are very very few respect to 2^160, so it is not unlikely that the "real" probability is very far from our estimate, in other words the variability of the % of the 14,9M addresses that fall in our range is very highIf in our range 1-2^159 there are 2/3 of 2^24 too, we will have the same probability you computed : 2/3 * 2^24 / 2/3 * 2^160 = 2^24 / 2^160 = 1/2^136. But there could be only 1/5 or worse 1/20 * 2^24 (it is not very unlikely IMHO), so more addresses is better without doubt. |
|
|
|
Oh... bug introduced by intertness (from the above division... 159 - log_bin($num_adr_funds)  I guess we'll add some more 0 now. I'm afraid there are 26 0... 2^159 private keys 14,9M --> 23,8 bits --> 2^135,2 24 hour --> 16,4 bits 2,2Gkeys/s --> 31 bits (31 + 16,4) - 135,2 --> -87,8 --> 0,0000000000000000000000000037116 I didn't count the 51 bits of the so far searched space, but i think it is more or less the same ... |
|
|
|
my $prob24 = 1 / (2 ** ($space - $bits)); # 24h prob: 1/(effective search space - space searched)
effective search space - space searched = 2 ** ($space - $bits) ?? 2^135 - 2^51 = 2^84 ?? |
|
|
|
After a discussion with Rico about probability in this project, I made some computations to try to understand better the problem. So: now we are generating many private keys ( from #1 to #2^160 ) to get some collisions in space of addresses. Collision: 2 different keys that "generate" the same address. We want to get a collision to unlock one of the 14M that we are monitoring. We don't want "bad" collisions, i.e. collision between 2 keys that we generate, because we can't catch them and then we want to avoid them because they are a waste of time (we don't want to compute many times the same addresses ). Rico tried to avoid useless collisions working on 2^160 keys instead of 2^256. In my opinion there are still bad collisions and overall we can't get all addresses starting from only 2^160 keys. Theory: From a private key to the relative address there are 3 steps: private key (a simple number) --> public key (a point of a curve, (x,y)) --> sha256 --> ripemd160 --> address ************************************************************************************************** Let's imagine for a moment that we could generate all the points of the elliptic curve secp256k: there are about 2^256 points. Each point can be represented in 2 ways: "04xy" (to get the uncompressed public key) or "02-3x" (to get the compressed public key), so there are 2^257 distinct representations (different inputs) for sha256. Question 1: how many distinct 256 bit strings we could get via sha256 from these 2^257 representations?If we look at theory** of hash function Theorem : In hashing n items into a hash table with k locations, the expected number of empty locations is k*(1−1/k)^n.
the number of strings that we cannot get is then: k (1-1/k) ^n where n=2^257 (input) and k = 2^256 (output). The result is: 2^256 * (1 - 1/2^256) ^ (2^257) = 2^256 * ((1 - 1 / 2^256)^(2^256))^(2) = 2^256 * ((1/e)^2) = 0,135 * 2^256 so we can get at this stage the 86,5% of all the 256 bit strings. Now we pass from 256bit strings to 160 bit strings with ripemd160. Question 2: how many distinct 160 bit strings we could get via ripemd160 from these 0,865 * 2^256 strings?Input: 0,865 * 2^256 strings of 256 bit --> Output: ?? strings of 160 bit If we apply again the formula k (1-1/k) ^n, with n = 0,865 * 2^256 , k = 2^160, we get 0,865*2^160*((1-1/0,865*2^160)^2^256 ) = 0,865*2^160 * (1/e)^(2^95) = 0 strings that we cannot obtain. Substantially we can say that we can get 2^160 strings, i.e. there are 2^160 distinct addresses . ************************************************************************************************* But what are the numbers in our case? We don't generate 2^257 representations, but only 2^161 (2^160 private keys <--> 2^160 points <--> 2^161 point representations) Question 1: how many distinct 256 bit strings we could get via sha256 from these 2^161 representations?If we apply again the formula k (1-1/k) ^n, with n = 2^161 , k = 0,865*2^256, we obtain substantially 2^161 different strings. Question 2: how many distinct 160 bit strings we could get via ripemd160 from these 2^161 strings?the formula k (1-1/k) ^n, with n = 2^161 , k = 2^160, we obtain that there are: 2^160 * ((1-1/2^160)^(2^161)) = 2^160*(1/e)^2 = 0,135 * 2^160 strings (addresses) that we cannot get in our project. At the end, we will have a 13,5% of collisions (the first after 2^80 keys), 1 collisions each 7 strings. So, even if we generated 2^160 private keys, we will never find out the private keys of the 13,5% (1.9M) of our 14M of addresses with bitcoin. And if we generated only 2^159 private keys (2^160 point representations), then there will be 2^160*(1/e) = 0,37 * 2^160 addresses that we cannot get, i.e. in that case we will never find out the private keys of 5.2 M of our 14M of addresses with bitcoin. ** https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0ahUKEwivm9eGq5LTAhXDu48KHcIMCHcQFghMMAY&url=https%3A%2F%2Fmath.dartmouth.edu%2Farchive%2Fm19w03%2Fpublic_html%2FSection6-5.pdf&usg=AFQjCNEmK51LFxc1lsDXxHoiTbYKpOHZCg&sig2=rKC2czitmxgO8GRPSNbPTg |
|
|
|
New question: If I generate 2^ 160 distinct points (in secp256k1), then I perform sha256 + ripemd160, I could get 2^160 different values (and then all the possible addresses)? A point (x,y) is a 512 bit string -> "04xy" -> sha256 + ripemd160 My guess is: if I generate 2^160 points is like if I generated 2^160 pseudo-random 512 bit strings, so there should be many repetitions. According to "law of third" -> http://www.roulette30.com/2010/04/law-of-third.html I should get only 2/3 * 2^160 distinct values, not the entire space. Am I right or not? And if I generated 2^161, or 2^162 ? What % of distinct addresses (on the total of 2^160 addresses) I will get? |
|
|
|
I would like to look at other keys (unknownhostname has too much cpu power) time ./gen-hrdcore-avx2-linux64 -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -L 8
what stand for options "-c" and "-L" ? |
|
|
|
If I was to have per-user keyrate charts (hourly), would you agree them to be public or not?
Rico
For me it's ok. |
|
|
|
1/2^(161-51) = 1/2^(110) = 1/(2^10)^11 = (0.001)^11 = 0.00000...0001 with 33 zeros
Why 2^161? Boh, +1 escaped me  . ok 1/2^(160-51) but more or less.... 2^160 if you want search for the entire space, 2^136 for the first "real" collision (but unknownhostname wants not a simple collision, but a rich collision) ... |
|
|
|
#52 I'm coming for you ...
How many days do we need for #52 ?
Btw can someone tell me what space did we searched from a 160 bit ? ... how many % ?
P.S. Need to setup a few more Gkeys/s
1/2^(161-51) = 1/2^(110) = 1/(2^10)^11 = (0.001)^11 = 0.00000...0001 with 33 zeros --> 0.00000...001 % with 31 zeros after the point . |
|
|
|
|
Show Posts
