Post
Topic
Board Development & Technical Discussion
Re: Ultra-Lightweight Database with Public Keys (for puzzle btc)
by
mcdouglasx
on 01/10/2024, 17:25:36 UTC
The B-tree is not a competitor here; the additional processing has nothing to do with the search speed in the database, which is fast enough. This is a different issue. As for Kangaroo, its problem is that it is probabilistic, and as the search space expands, its success rate deteriorates. You know very well that adding DPS doesn’t work like magic.

Of course it's not magic. But what do you mean by this: "as the search space expands, its success rate deteriorates"? I'd say it's the other way around: having more pseudo-entropy increases the chances of a collision, because you have better uniformity, so the probabilities are allowed to behave closer and closer to the predicted "success rate". So this "success rate" as you call it is actually worse for smaller ranges, due to lower entropy.

If you throw a coin in the air 1.000.000 times there's a 99.99% chance the number of heads is in a very specific tight interval. If you throw it just 100 times, that confidence interval is a lot worse. Kangaroo will work in the same way, larger interval = higher confidence a solution can be found, otherwise the Universe is broken.

Perhaps your DB has only a very specific use-case: brute-force, which, while guaranteed, you might never live enough for it to finish, even if you count billions of trillions of keys per second. In contrast, do you know of an example of a private key that Kangaroo cannot find? Because I never encountered one. It's like trying to pin-point to a single atom in the Universe and stating "hey, look, this one can never be found this way" and discarding the algorithm as problematic because of this singular exception. While all the other atoms are part of a single DP "tree" into which they all merge into, at some point.

Is it the same to use Kangaroo with 4 cores as with 12 cores? No, right? Because it is an algorithm that depends on computing power, which is limited (technology does not advance so quickly and the difficulty of the puzzles grows exponentially). That is, your probability decreases exponentially with time and the difficulty of the puzzle. It is not as you think that Kangaroo works better in higher ranges. If that were the case, 256 bits would be in danger. The correct thing to say is: Kangaroo is not useful in small ranges, and similarly, my database is not useful if you store small ranges of keys, because with this database its success rate grows over time without needing additional effort. I think that in the future this, along with BSGS, will be the most used, due to the advantages already described. You can even store random, sequential patterns and merge them with other databases shared by other users. I know it will take time, but my vision is towards the future.