What the researchers were doing was creating "honeypots", the relays weren't "honeypots". The snooping HSDir is something that's long been acknowledged as a weakness in the current rendezvous protocol. Most of these relays have likely been ejected from the consensus but as arma stated the methods that the
bad-relays hunters currently employ aren't always perfect, and it's good to have other researchers working towards the same goal through different means.
The idea works like this, onion services use HSDirs to publish their descriptors. A naughty HSDir can see these descriptors as they are published, and operators can use this to index onion services even if the onion address is never made public. Essentially, if you publish an onion service then any HSDir that you publish to can try to connect to the onion service as a normal user, since they know the address from the descriptor you gave them.
The next-gen onion services will attempt to stop this kind of activity by HSDirs being possible by encrypting the descriptors contents with information that a user who knows the onion address would know but the HSDir does not, through keyblinding. This will defeat such attempts to discover in-use onion addresses.
It is also currently possible to encrypt the onion service descriptor with a secret that is shared out-of-band through the use of
stealth mode on the onion service and
HidServAuth on the client. This would mean a snooping HSDir would be unable to decrypt the descriptors contents and discover the introduction points used by the onion service or the public keys that it should use to signal to them that it would like to rendezvous with the onion service. A lesser
basic mode is also available that would stop them successfully completing a connection but would allow them to discover the introduction points, because it does not encrypt the descriptor it just requires that the client proves knowledge of the shared secret before it will allow a user to connect.