I don't see any benefits of this. If you have N baby steps with 1 bit of each, then roughly N/2 steps will collide with each giant step. This mean you will need to perform at least N/2 additional operations on each giant step to check false positives.
This leads to the fact that the ability to store n-times more baby steps leads to an n-times increase in the size of the giant step, but at the same time increases the number of operations required to check the collision by the same number.
Simply put, this ultimately will not give any increase in speed compared to maintaining the full baby step value.
Each key is represented by 1 bit; but 64 keys are calculated and hashed to binary, so basically 64, zeros and ones, represent 64 keys. False collision 1 out of every 2^64? So DB is smaller but search is slower. DB is much smaller.
I managed to represent each key with 8 bits and add false collision check. Larger DB size than the OPs original, but search Key/s is faster.
Working on another angle now. It works with normal search but I have not tried to implement into BSGS as OP did.