Ok, so that follows my primary key hash concat logic that i striked out in OP (only BIP-32 calls it index, or sequence
here), but then I need to store that index/sequence next to my child key... also I need to make sure the index/sequence is used only once too! hm, was looking for something cleaner.
Thx!
Depending on how many child keys you want you could search for child keys where the index is encoded in the bits of the child key. No need to store the index with the child key.
Most child keys would not have this property, but those that do are obviously children of the master key. You extract the index from the child key and re-derive the child key from the master key.
For example you could start generating child keys with index i starting at 1 and going up. The first few bits of the hash of the child key could be compared to i. If it matches, this is a usable child key.
Unfortunately, you'd be lucky to find a key with this property. You can increase the probability of finding a child key if you allow yourself more child key candidates per index. You could hash n times for example and if the first few bits of any of those hashes matches i you have a usable child key. Of course you have to check possibly all n candidate indexes to show that the child is derived from the master.
Probably too complicated for your application, but then, I don't know your application.