Congrats Real-Duke & Newbie^^

Ok Rico, from the way you describe the process I derive following information pieces.

EDIT: for clarity. When I say "have 4 addresses in the filter" I mean 4 **unique** addresses and 8 representations thereof (2 each)1) As I assumed the compressed address is simply a way of displaying

**one** uncompressed address in another way.

==> It means that it is a bijective mapping of the address to another encoding / format.

As in:

https://en.wikipedia.org/wiki/Bijection2)

a)It definitely makes sense to calculate both addresses for a private key and check against the filters,

just to make sure we cover 100% of all addresses that are funded (if we should ever get to the end of 160 bits

)

b)On the contrary this does

**not** mean that you check two private keys, just two representations(!) of the public key.

->Checking only the compressed

**or** uncompressed address format would allow for a collision to go by undetected,

because you basically have a 50% chance of the original private key being used / funded through either of the formats,

thus not appearing in your bloom filter.

->Now reducing the search space to 159 bits, effectively halving it, reduces the collision amount that you can expect to find accordingly and you

could expect to

**match **about half of all addresses in your filter +/- variance. (while

**producing** half of all possible addresses)

->By checking only one however, and opening up for undetected collisions as mentioned above, you should then only expect about 25% of all addresses to be

**matched**.

(while still having to

**produce** half of all addresses for this lesser gain.)

->In Order to

**produce** all addresses you still have to go through 160 bit of search space.

-->In Order to

**match** all addresses you can not reduce the search space and have to check against both formats.

->The probability of

**matching just one** produce (the next one) to an address in the filter should then (kinda simply) be:

1 / ( (2**159) / 1 ), for the case we have a single address in the filter, in both its representations.

1 / ( (2**159) / 2 ), for the case we have two address in the filter, totaling 4 representations.

1 / ( (2**159) / (2**159) ) = 1/1 = 100% (as logically expected), for the case that we would check against a filter containing all possible entries.

So the needed formula is:

1 / ( (2**159) / (Number_Of_Entries_In_Filter) )

This is then scale able with something like X Mkey/s and 24h, to approximate daily probability.

Important here is that this is plain, without the progressive nature that's built into the LBC.

Again I am not sure about the need for conditional calculations (might arrive at the same result).

Because simply put each done calculation just reduces the remaining search space.

1 / ( (2**159 - Progression_Value) / (Number_Of_Entries_In_Filter) )

Imagine the extreme scenario, we find all (lets say we had only 2

^{2} for simplcity) addresses in the very last 4 private keys that we search.

The formula must result in 1 (100%) at the point where only 4 private keys are left and 2**159 - 4 have been searched.

Let's see:

1 / ( (2**159 - (2**159 - 4)) / (4) )

1 / ( 4 / 4 )

= 1 !

Works beautifully!

What do you guys think?

SUMMARY:

I think checking both formats is mandatory since we don't want anything go by undetected, period :-)

Since uncompressed to compressed is an encoding process not evolving the private key it is unrelated to the search space coverage.

But related to collision chance. (on the homepage described as" the effective search space until something is found")

One could also formulate:

"There are 2

^{160} addresses. Each has two representations, which are interchangeable. Making it 2

^{161} representations.

One private key calculation will have a chance of matching one of the representations of 1 / 2

^{160} twice. So probability per private key is 1 / 2

^{159}. (non progressive)"

If you want to display the probability of the pool forefront on the page my suggested formula should do the trick.

If you really want to display a good estimation, or even just scaled up from current speed, for a 24h based probability you will need a math professor at your disposal

Phew, brain tingles :-)

Have fun with this mind twister