It's not just about getting the protocol stack right, but also the ancillary software environment; people keep asking me for "V3 support in EOTK" and my stock response is this: ==== BEGIN ==== OnionBalance requires STEM support for V3, before it can be updated (possibly a substantial rewrite will be needed) to support the new format onions. It's not only a matter of "longer addresses" but also a matter of cross-signing the descriptors to support new-style cryptography, so in fact it might be safest to create a new, separate OnionBalance for V3. So: STEM needs updating and testing for V3, and then OnionBalance needs to support the new STEM library and encryption. Then (for me) EOTK needs to support the new OnionBalance. I am not expecting a solution to ship until 2019, earliest. ==== END ==== ...and that's even without refactoring the other bits of EOTK to address the changes when STEMv3 lands. OTOH, I have been performance testing simultaneous regular-expression matching of v2/3 addresses, and so far this is the winner: "\\b([a-z2-7]{16}(?:[a-z2-7]{40})?\\.onion)\\b" ...and it's already in the codebase at https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt#L... - alec :-) -- http://dropsafe.crypticide.com/aboutalecm