Thanks! That's very interesting! TIL :-) What would you propose to do with subdomains, like www.facebookcorewwwi.onion? Or is that outside the scope of your proposal?
- alec On 31 Dec 2017 00:53, "nullius" <null...@nym.zone> wrote: > # 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! > > -- > null...@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 > >
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev