Large Bitcoin Collider (Collision Finders Pool) - page 17.

arulbero

legendary

Activity: 1914

Merit: 2071

Quote from: Its_a_Meeeee on April 12, 2017, 09:53:53 AM

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

Its_a_Meeeee

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

arulbero

legendary

Activity: 1914

Merit: 2071

Quote from: rico666 on April 12, 2017, 09:40:59 AM

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.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: arulbero on April 12, 2017, 08:38:29 AM

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

maybe check the math again?

Rico

arulbero

legendary

Activity: 1914

Merit: 2071

Quote from: rico666 on April 12, 2017, 09:05:50 AM

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.

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: arulbero on April 12, 2017, 09:00:47 AM

(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

arulbero

legendary

Activity: 1914

Merit: 2071

Quote from: rico666 on April 12, 2017, 08:52:13 AM

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: arulbero on April 12, 2017, 08:38:29 AM

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

arulbero

legendary

Activity: 1914

Merit: 2071

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: Its_a_Meeeee on April 12, 2017, 07:35:12 AM

"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 * 10⁶ * 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

Its_a_Meeeee

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: unknownhostname on April 12, 2017, 02:50:26 AM

2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd

Hey whale! Leave some krill for the smaller fish.

(ok - a whale is not exactly a fish ... but hey)

Rico

unknownhostname

member

Activity: 62

Merit: 10

2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd

ddosamerica7

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!

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞

Quote from: unknownhostname on April 11, 2017, 03:09:41 PM

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

today it didnt get anything

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

unknownhostname

member

Activity: 62

Merit: 10

Quote from: rico666 on April 11, 2017, 02:28:33 PM

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

rico666

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

rico666

legendary

Activity: 1120

Merit: 1037

฿ → ∞