As part of its initial feature set, bech32(1) has special handling for RFC 7686 .onion special-use domain names; it detects such a name, and transcodes the RFC 4648 Base32 to and from Bech32 with an HRP of “onion”. For Bitcoin “Bravo Charlie” addresses, bech32(1) takes and gives the witness version and the hexadecimal-coded octets of the witness program. Otherwise, for the most part, it encodes and decodes hexadecimal data with user-provided HRPs. I intend to add special interpretation of “pgp1” with a concept I call “PGP Descriptors”; but I need to spec that out first.

Some usage examples from the manpage:

Code:

Extract the witness version and Hash160 from the bech32 utility author'sBech32 tip address:

This is an alpha-quality initial release. The code is still a bit messy; it needs test vectors, which seem insufficiently specified; features and the finer details of behaviour may be a bit in flux. However, the basic user interface should be considered stable. I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

As part of its initial feature set, bech32(1) has special handling for RFC 7686 .onion special-use domain names; it detects such a name, and transcodes the RFC 4648 Base32 to and from Bech32 with an HRP of “onion”. For Bitcoin “Bravo Charlie” addresses, bech32(1) takes and gives the witness version and the hexadecimal-coded octets of the witness program. Otherwise, for the most part, it encodes and decodes hexadecimal data with user-provided HRPs. I intend to add special interpretation of “pgp1” with a concept I call “PGP Descriptors”; but I need to spec that out first.

Some usage examples from the manpage:

Code:

Extract the witness version and Hash160 from the bech32 utility author'sBech32 tip address:

This is an alpha-quality initial release. The code is still a bit messy; it needs test vectors, which seem insufficiently specified; features and the finer details of behaviour may be a bit in flux. However, the basic user interface should be considered stable. I am here opening a Bitcoin Forum thread for discussion of this utility; over time, I will edit and update this post as appropriate.

Well, thanks for looking at my source code! At least at the top of the main .c file. And yes, all strings with a suffix of “.onion” are automagically detected. The bech32(1) tool does not know about any specific .onion sites, although I had to pick one for a manpage example.

If you like this particular feature, then you will be pleased to see the proposal I just made on tor-dev:

Edit: 404 from Github apparently resolved by support. It appears that you can access my repositories now; please tell me if you have any problems.

Quote from: Jimmy (GitHub Staff)

Sorry about that. Sometimes our spam-detecting systems miss the mark and you were accidentally flagged in the process. I've gone ahead and removed the flag and you shouldn't see that message again.

I’ve requested further info, in hope that I could avoid this happening ever again. I will edit or post with further info, if and as appropriate. Regardless—if things are indeed working now, I apologize to the forum for the noise. You may well understand how I reacted when I saw my public source code repositories suddenly go 404.

Quote:>Your account has been flagged.>Because of that, your profile is hidden from the public. If you believe>this is a mistake, contact support to have your account status reviewed.

This was on the same page as displayed the following message:

>Thanks for getting in touch with us!>We’ll get back to you shortly.

I did *not* see the flagged notice before. I also have not receivedany other notification, by e-mail or otherwise.

Obviously, I must request that you review and undo this forthwith.I must also inquire as to the ostensible grounds for this action.There is *no* legitimate reason for my account to be “flagged”.

For the record:

- All the code I have published to the Github account “nym-zone” was either written by me, or used under an open-source license.

- I have not engaged in any abusive behaviour.

- I have done nothing wrong.

- I have absolutely no idea what this is about. Nobody has even complained to me; and Github did not give me the courtesy of so much as an e-mail to advise that I’d been suddenly 404ed. I was lucky to have caught this when I did; and I am blindsided here.

This message is signed with the PGP key I have registered in myGithub account, and have used to sign my commits. Its fingerprint is0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.

The text of my prior message, which I had saved before sending (that’s my habit on the forum, too!):

Quote

Subject: 404 on my profile and projects!

In a non-logged-in browser, I am receiving a 404 “Page not found” error for my own profile and projects! In a logged-in browser, I can see my profile and projects; but a project with 10 total open/closed issues shows 0 issues, total.

<2> Regards to Bech32 I am trying to compile it on Visual Studio 2017 community edition using c +1+(https://i.imgur.com/yo5J4Q6.jpg jargon ... hang on (I am running out time) going to ed; this post again ... So I am not sure if it going to compile or not ...since there are some barvarian char set and maybe I only will see the out put at Oktoberfest. (pls relax this is a joke, when we'serious we ARE serious)

I think that this should probably work, mostly. For its “user interface”, the utility uses POSIX getopt(3) functionality, and also the BSD-style <err.h> (also available on Linux). I don’t know to deal with that on Windows. Otherwise, it is just STDC.

I myself can’t test MSVC compilation; for I have no Windows in my house. Please let me know what results you get.

Should there be indicators of demand, I may try to produce Windows binaries with mingw.

If you need to replace anything with code from WIN32, I strongly suggest that you #define WIN32_LEAN_AND_MEAN. I seem to vaguely also remember some define for Unicode, but I don’t remember what it is. If somebody comes up with Windows/MSVC compat code, I may try to abstract that into a separate file. I will not clutter main files with #ifdefed Windows code, or Windows “decorations”; I was recently trying to audit a simple cross-platform library where every function is “decorated” with DLLEXPORT, and that junk makes code unreadable.

<2> Regards to Bech32 I am trying to compile it on Visual Studio 2017 community edition using c +1+(https://i.imgur.com/yo5J4Q6.jpg jargon ... hang on (I am running out time) going to ed; this post again ... So I am not sure if it going to compile or not ...since there are some barvarian char set and maybe I only will see the out put at Oktoberfest. (pls relax this is a joke, when we'serious we ARE serious)

I think that this should probably work, mostly. For its “user interface”, the utility uses POSIX getopt(3) functionality, and also the BSD-style <err.h> (also available on Linux). I don’t know to deal with that on Windows. Otherwise, it is just STDC.

I myself can’t test MSVC compilation; for I have no Windows in my house. Please let me know what results you get.

Should there be indicators of demand, I may try to produce Windows binaries with mingw.

If you need to replace anything with code from WIN32, I strongly suggest that you #define WIN32_LEAN_AND_MEAN. I seem to vaguely also remember some define for Unicode, but I don’t remember what it is. If somebody comes up with Windows/MSVC compat code, I may try to abstract that into a separate file. I will not clutter main files with #ifdefed Windows code, or Windows “decorations”; I was recently trying to audit a simple cross-platform library where every function is “decorated” with DLLEXPORT, and that junk makes code unreadable.

Thanks nullius,

Definitely I will try MSVC compilation and I will let you know the results I get. But, ( as my usual academic methodology ) firstly, I need to do a research on system development history. For instance, I know that Microsoft POSIX subsystem is old as Windows NT Kernel ( ). ( I don't know, in my memory Microsoft's Unix reminds me Xenix. Also regards to cryptology and Redmond campus... in general I find a pleasure reading Niels Ferguson, Bruce, and Kohno book ISBN: 978-0470474242

ps-> Nice to see that your *nix flavour is BSD Group ;-) Most of the time I have really nice experience on SDF Public Access UNIX System .. Est. 1987 ...

This message is for SDFers who are interested in Amateur Radio. The SDFARC is open to all people interested in Amateur Radio. Many club activities are for licensed operators, but new comers are welcome.

If you want to get on our mailing list, simply send "subscribe sdfarc-l" in an email to majordomo@sdf.org

We currently have about 50 members scattered all over the world. Because of this, it makes for a very unique club. We're interested in discussing ideas such as HamWan, file sharing and other experiemntal digital modes.

This proves, that you are not only from FreeBSD world, you are probably more from the OpenBSD world! Looking at the code of bitcoin, there are too many people, which say "code is doc". Well, I can even remember a thread here, were Greg M is challenging others in reading code and asking to explain. This might prove him be a genius, but in companies you need team capabilities, not single point of failure knowledge. Reliability, combined with fall back scenarios is required. This is why good code is not only readable, but also documented. Otherwise the world would still be in (Z80 ?) assembler.

Appreciating your code distribution, looking at it, and trying to find out, what to do with it. Thanx for posting.

This proves, that you are not only from FreeBSD world, you are probably more from the OpenBSD world! Looking at the code of bitcoin, there are too many people, which say "code is doc". Well, I can even remember a thread here, were Greg M is challenging others in reading code and asking to explain. This might prove him be a genius, but in companies you need team capabilities, not single point of failure knowledge. Reliability, combined with fall back scenarios is required. This is why good code is not only readable, but also documented. Otherwise the world would still be in (Z80 ?) assembler.

Thanks, pebwindkraft. Why yes, I think all the major BSDs have a strong manpage culture. I myself have much benefitted from that, and I have been inculcuated with it along the way.

I was there speaking to my annoyance at code only “documented” by wikis, webpages, or (for libraries) the output of Doxygen. If software lacks reasonably complete usage documentation which can be quickly referenced at the tty by typing `man xxx`, without firing up a web browser or even being online, then that severely impairs its usability.

From the producer end, it sometimes occurs that when writing a manpage, I realize that I am documenting a wish for what the program should do, not what it actually does. Then, I change the code to bring it in line with the manpage. This happened repeatedly with easyseed. Different levels of thought are required respectively for writing code, and explaining its external features in natural language. Exercising both improves the code.

I do believe that the code itself is a form of documentation; and I love reading well-written C code. For those who wish to modify the code, the code itself documents what it does; and code comments explain why, when that is nonobvious or based on some external specification. Written specifications are certainly needed for that teamwork you mention; and I judge specifications based on whether or not I need to refer to existing code to implement from spec. The manpage is most of all for those who wish to use the results; and ultimately, it is the results that count.