Pages:
Author

Topic: Large Bitcoin Collider (Collision Finders Pool) - page 17. (Read 193420 times)

legendary
Activity: 1932
Merit: 2077
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 Huh

EDIT: every time you generate a key , you have always the same probability. You can talk only about the probability in n tries...
newbie
Activity: 6
Merit: 0
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 :-)

cheers


EDIT:
There is even another aspect to it *sigh  Roll Eyes

And that is, by just scaling the probability up with the keys per day, you neglect that the probability for the 2nd key of the day is higher than the 1st and so on ...
Its not going to be a big difference in the result, it's more like neglecting air resistance in physics, kinda doesn't matter ^.^

I enjoy pointing stuff out tho :-)

peace
legendary
Activity: 1932
Merit: 2077


Well - I have now

Code:
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_distribution

Quote
Assumptions: 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.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Code:
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 ??


Well - I have now

Code:
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.


edit: I think my original formula was correct...
By the time we reach 135.17 bit search space, we have 1/ 2^0 probability = 1

Now the logarithm of searched keys => 51.32 bits space searched is what actually allows us to perform a simple subtraction of the exponents.

Mr. Arulbero ...  Smiley maybe check the math again?



Rico
legendary
Activity: 1932
Merit: 2077

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 high

If 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.
legendary
Activity: 1120
Merit: 1037
฿ → ∞
(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 ...

2 orders of magnitude...
because %

0.000000000000000000000000003711
0.000000000000000000000000401596% <--- correct number (online)


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.


Rico
legendary
Activity: 1932
Merit: 2077
Oh...

bug introduced by intertness (from the above division... 159 - log_bin($num_adr_funds)Wink

I guess we'll add some more 0 now.  Roll Eyes


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 ...

legendary
Activity: 1120
Merit: 1037
฿ → ∞
Code:
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 ??


Oh...

bug introduced by intertness (from the above division... 159 - log_bin($num_adr_funds)Wink

I guess we'll add some more 0 now.  Roll Eyes


Rico
legendary
Activity: 1932
Merit: 2077
Code:
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 ??
legendary
Activity: 1120
Merit: 1037
฿ → ∞
"The probability to find an address with funds on it within the next 24h is therefore 0.00000000112258370293%."

Hey Rico, can you share the formula that calculates this number?

And earlier today (when above number was smaller) I bragged in the German forum about this number:


0.00000000000000000045% (2016-09-17)
0.00000000000000200548% (2016-09-23)
0.00000000002801022860% (2017-03-28)
0.00000000108372998990% (2017-04-17)

Quote
Is it only speed based, does it take the progression of the project into account? and what about reset / reissued blocks?

The formula is:

Code:
my $space           = 159 - log_bin($num_adr_funds);
my $keys_day        = $srch_speed * 86400 * 1000000;              # how many keys per day are searched
my $prob24          = 1 / (2 ** ($space - $bits));                # 24h prob: 1/(effective search space - space searched)

$prob24 *= $keys_day;                                             # multiply with PK/24h rate (seconds * pk/s)                                                        
$prob24 *= 100;                                                   # * 100 (for %)                                                                                    

$bits is currently 51.32
The 159 is 2^159 keys to search, as this resolves to 2^160 addresses
$srch_speed is the 24h Mkeys/s average you see, therefore * 106 * seconds in day
So this number gets bigger in time (because we have covered search space) and/or if the pool gets faster.
If the pool gets slower, this number may also become smaller. (search speed = 0 -> probability = 0)

Reissued blocks are not relevant, because the "space searched" takes only PoW blocks into account.
Promised and undelivered blocks do not count as searched space.



Rico
newbie
Activity: 6
Merit: 0
Wow!

"The probability to find an address with funds on it within the next 24h is therefore 0.00000000112258370293%."

Hey Rico, can you share the formula that calculates this number?
Is it only speed based, does it take the progression of the project into account? and what about reset / reissued blocks?

Sorry if I'm bringing up already discussed stuff, I'm soon read up on everything ;-)
Until then I might need the occasional question answered plox ^.^

Happy hashing all
legendary
Activity: 1120
Merit: 1037
฿ → ∞
2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd

Hey whale! Leave some krill for the smaller fish.  Smiley (ok - a whale is not exactly a fish ... but hey)

Rico
member
Activity: 62
Merit: 10
2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd
newbie
Activity: 15
Merit: 0
This is actually really cool. I'm going to start running the VMWare iso and see what I can find. Cheers man!   Smiley
legendary
Activity: 1120
Merit: 1037
฿ → ∞
My machines didnt found anything for about 1 day ... usually it was getting around 3/day ...

today it didnt get anything Smiley

You should just look which of your servers run 1.031 version. Update these. It's a pretty good indicator that these have an older BLF file.
You do not need to look at the 1.067 Servers - if they get the block, they find it.

If you want a list of the 1.031 IPs I can send it via PM.

Rico
member
Activity: 62
Merit: 10
Next would-have-been-unknownhostname-bounty-if-he-had-his-clients-up-to-date:

https://blockchain.info/address/137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH

and user "cagrund" missed it by 7 seconds (else his client would have gotten it assigned by the server).



Rico

My machines didnt found anything for about 1 day ... usually it was getting around 3/day ...


today it didnt get anything Smiley
legendary
Activity: 1120
Merit: 1037
฿ → ∞
Next would-have-been-unknownhostname-bounty-if-he-had-his-clients-up-to-date:

https://blockchain.info/address/137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH

and user "cagrund" missed it by 7 seconds (else his client would have gotten it assigned by the server).



Rico
legendary
Activity: 1120
Merit: 1037
฿ → ∞
That would be the moment I have to quit  Grin

Didn't you want to tell us something?  Cool
legendary
Activity: 3486
Merit: 2287
Top Crypto Casino
gief GPU please ... that means 4k CPU's with at least 1k GPU's Cheesy = billions of keys / sec Cheesy

That would be the moment I have to quit  Grin
member
Activity: 62
Merit: 10
If I didn't know better I'd suspect you are testing some ASIC prototype.  Cool


Rico

gief GPU please ... that means 4k CPU's with at least 1k GPU's Cheesy = billions of keys / sec Cheesy
Pages:
Jump to: