# Synopsis

The Bech32 standard for error-correcting base32 strings was developed explicitly for relative ease and reliability in human communication of pseudorandom bitstrings.  I invite discussion of specifying Bech32 as an alternative means for representing RFC 7686 .onion domain names.  Should the response hereto be positive, then I will offer a formal proposal.

I have written and released a tool which automatically recognizes and encodes/decodes .onion addresses in Bech32.  To complement whatever I here say, please get a hands-on feel for Bech32 .onions:

https://github.com/nym-zone/bech32

Manpage (yes, a real manpage!):
https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt

# Background: About Bech32

Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by Pieter Wuille and Greg Maxwell.  According to Mr. Maxwell, “Bech32 is designed for human use and basically nothing else”; the underlying research and development process involved extensive testing with human users, analysis of NIST visual confusability data, and the integration of a BCH code with strong error correction and detection properties.

[1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

I refer to BIP 173 for further explanation of Bech32’s design properties, its rationales, and the limits of its error handling.

A specific application of Bech32 is Bitcoin’s new address format for the future, which I call “Bravo Charlie Addresses” after the letters “bc” specified for Bitcoin addresses in the standard’s “human-readable part” (HRP).  However, the standard was written to permit general use in other applications.

Having in hand a standard explicitly designed to ease the pain which wetware suffers when it comes into contact with pseudorandom gibberish, the cypherpunk in me is overjoyed at the potentials.  One is a concept which I call “PGP Descriptors”, which I am currently working to specify with a few extra features and nuances.  And of course, I think of .onions!

# Bech32 for .onion

I hereby nominate “onion” as the logical HRP for RFC 7686 .onion special-use domain names.

Here is Bech32 .onion by example, using my bech32 tool with its built-in .onion support to encode and decode the name for the Tor Project’s .onion equivalent of its “www” site:

```
$ bech32 -e expyuzz4wqqyqhjn.onion
onion1yh0c5eeuksscs8fdyd8406
$ bech32 -d onion1yh0c5eeuksscs8fdyd8406
expyuzz4wqqyqhjn.onion
```

The string is longer, because it contains 6 base32 characters’ worth of error-correcting code.  N.b. also, the foregoing should work just fine for v3 onions (formerly prop-224).

Imagine the impact on users who have a practical need to transmit a .onion address by verbal communication, or via a handwritten note.  Now they can get some help with errors, instead of wondering why they can’t connect to a nonexistent .onion site.

The standard enjoins applications against autocorrecting Bitcoin addresses, so as to prevent even the slightest possibility of causing funds loss by being too “helpful”.  But in applications where it would be safe to do so, Bech32 can indeed correct small errors (as well as reliably detecting much worse errors).  I suggest that such automatic correction would be suitable for .onion addresses.

Bech32 co-author Dr. Wuille (sipa) has published Javascript reference code, plus a Javascript error-correction demo, under an MIT license.  Perhaps this may be easily adapted into Torbutton, for automagic decoding of Bech32 “onion1” to .onion domains in the Tor Browser address bar.  The code is in the same repository whence I copied the Bech32 reference C code I use internally in my tool:

https://github.com/sipa/bech32

# Conclusion—or, to be continued...

An alternative representational format with error-correcting codes will make .onion addresses more human-friendly.  I look forward to the day when “onion1” addresses can be passed by handwritten notes, vocalized with a radio alphabet, stuffed into QR codes, scrawled on parchments placed in bottles tossed to sea, rocketed into space, and then conveniently transformed with appropriate corrections into the DNS-style .onion format specified by RFC 7686.

Here’s to the alternative Onion format of the future!

--
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev