nullius (OP)
|
I have released an initial version of the bech32(1) utility for encoding and decoding of BIP 173 Bech32 strings and Bitcoin “Bravo Charlie Addresses” (“bc1”). As any worthwhile software, it comes replete with a manpage ( text), q.v.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: Extract the witness version and Hash160 from the bech32 utility author's Bech32 tip address:
bech32 -S bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h 0:0xc76172ea149002114027b90f0759084f93aea326
Get a “hello, world” introduction to Bech32:
bech32 -e -h hello_world 48656c6c6f2c20776f726c6421 hello_world1fpjkcmr09ss8wmmjd3jzzwhs4ff
Generate a “burn address” with a Hash160 of all zeroes, which would be spendable by the same unknown private keys as the infamous 1111111111111111111114oLvT2. Warning: Do NOT send coins here:
bech32 -s 0 0x0000000000000000000000000000000000000000 bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs
Bech32-encode the address for Wikileaks, to add error-correcting codes:
bech32 -e wlupld3ptjvsgwqw.onion onion1kt50trm0nf4jxkskpcjy74
Now, decode the address someone gave you:
bech32 -d onion1kt50trm0nf4jxkskpcjy74 wlupld3ptjvsgwqw.onion
Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders. 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.
|
|
|
|
Andre_Goldman
Sr. Member
Offline
Activity: 322
Merit: 253
Property1of1OU
|
|
December 30, 2017, 10:17:09 PM |
|
I have released an initial version of the bech32(1) utility for encoding and decoding of BIP 173 Bech32 strings and Bitcoin “Bravo Charlie Addresses” (“bc1”). As any worthwhile software, it comes replete with a manpage ( text), q.v.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: Extract the witness version and Hash160 from the bech32 utility author's Bech32 tip address:
bech32 -S bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h 0:0xc76172ea149002114027b90f0759084f93aea326
Get a “hello, world” introduction to Bech32:
bech32 -e -h hello_world 48656c6c6f2c20776f726c6421 hello_world1fpjkcmr09ss8wmmjd3jzzwhs4ff
Generate a “burn address” with a Hash160 of all zeroes, which would be spendable by the same unknown private keys as the infamous 1111111111111111111114oLvT2. Warning: Do NOT send coins here:
bech32 -s 0 0x0000000000000000000000000000000000000000 bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs
Bech32-encode the address for Wikileaks, to add error-correcting codes:
bech32 -e wlupld3ptjvsgwqw.onion onion1kt50trm0nf4jxkskpcjy74
Now, decode the address someone gave you:
bech32 -d onion1kt50trm0nf4jxkskpcjy74 wlupld3ptjvsgwqw.onion
Licensing includes a Bitcoin Consensus Clause, to prevent use by scamcoin pretenders. 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. MODE_ONION_ENCODE Thanks for that. btw I notice that others well-known web sites (such as uj3wazyk5u4hnvtk.onion ) already get updated
|
Patent1number: ****-****
|
|
|
nullius (OP)
|
|
December 31, 2017, 01:07:25 AM |
|
MODE_ONION_ENCODE Thanks for that. btw I notice that others well-known web sites (such as uj3wazyk5u4hnvtk.onion ) already get updated 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: https://lists.torproject.org/pipermail/tor-dev/2017-December/012743.html
|
|
|
|
nullius (OP)
|
|
January 02, 2018, 06:18:25 AM Last edit: January 02, 2018, 06:51:39 AM by nullius |
|
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. 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. Aside, n.b. that I habitually PGP-sign my commits using the ECC key with fingerprint 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C. Notice: The Github repositories for easyseed(1) and bech32(1) have suddenly gone 404. Little remains of me on Github but for my open pull request to the BIP repository ( archive.org, archive.is). I saw that, before I saw this: Here is the message I sent to Github support via their web form after I saw the latter: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Immediately upon sending my last support message, whereby I requested support with my profile and projects being 404, I received for the first time the following message:
![github_flagged_nym-zone](https://user-images.githubusercontent.com/33915087/34474941-ffa49fc4-ef7d-11e7-8c9c-e87fa7c498ae.png)
Image SHA-256: 4be910e882cd68b62bf1390c608f8407070e43a9d5c4f040e31a8a2e56e2df6d github_flagged_nym-zone.png
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 received any 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 my Github account, and have used to sign my commits. Its fingerprint is 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C.
~ Signed, ~
nullius@nym.zone 2018-01-02 -----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWksc4wAKCRDEJ5MVn575 SY3NAQC3otsvONLOxDI/C20CqKUFzy9WH+SkQOewA/aqAq/mVQD/cNQxKcHjyhhO GRajS4PH+Gy1PstnoZ5JalIfIZJI3gM= =BDZi -----END PGP SIGNATURE-----
The text of my prior message, which I had saved before sending (that’s my habit on the forum, too!): And just when I’d been contemplating my next improvements and little projects.... Persons interested in my code are invited to contact me directly, via e-mail (preferred) or PM. However this resolves, I will also must needs seek more reliable means of publishing my source code.
|
|
|
|
nullius (OP)
|
|
January 04, 2018, 01:00:19 PM |
|
<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.
|
|
|
|
Andre_Goldman
Sr. Member
Offline
Activity: 322
Merit: 253
Property1of1OU
|
|
January 05, 2018, 02:29:56 AM |
|
<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 ...
|
Patent1number: ****-****
|
|
|
Andre_Goldman
Sr. Member
Offline
Activity: 322
Merit: 253
Property1of1OU
|
|
January 06, 2018, 09:53:27 PM |
|
Today ( 1515275048210391 ) I moved some steps ahead ... I cloned the source and as usual I started read the .txt file ( https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt ) which tells me what the utility/function does) then I will read the LICENCE terms. btw, Thinking about Bravo-C it came to my mind ... Date: Fri, 29 Dec 2017 04:24:59 GMT From: SDF Amateur Radio Club < sdfarc@sdf.org> Subject: SDF Amateur Radio Club! 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. Some quick notes: * Our website: http://sdfarc.org * Our weekly NET is held on ECHOLINK node 9424 (AB9FJ) Mondays at 0000 UTC * Our mailing list is sdfarc-l@sdf.org 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. 73! Kind Regards, see you on monday
|
Patent1number: ****-****
|
|
|
nullius (OP)
|
|
January 29, 2018, 11:58:40 PM |
|
Today ( 1515275048210391 ) I moved some steps ahead ...
Apologies for the delayed reply. Any luck with getting it to compile on your platform?
|
|
|
|
pebwindkraft
|
|
January 30, 2018, 03:52:09 PM |
|
just stepped through the readme file in the code: Software is unworthy of release if it does not have a proper manpage. 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.
|
|
|
|
nullius (OP)
|
|
January 30, 2018, 07:33:26 PM |
|
just stepped through the readme file in the code: Software is unworthy of release if it does not have a proper manpage. 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. Appreciating your code distribution, looking at it, and trying to find out, what to do with it. Thanx for posting.
I hope that you find this utility useful for your Bech32 encoding needs. Please don’t hesitate to inquire with any questions or suggestions.
|
|
|
|
denifednu
Newbie
Offline
Activity: 4
Merit: 0
|
|
December 22, 2018, 11:55:15 PM |
|
Thanks very much for this! fyi, I'm using it to generate BIP84/P2WPKH addresses from privatekeys for bitcoin, e.g.: $ KEY="L2QQ7BHxpTwvi68BS9BcARM3W6UUbiJcLeUVnCcJ2wNLebGBwgHB" $ bech32 2>&- -s 0 `echo ${KEY} | bx wif-to-public | bx bitcoin160` bc1qnlj5pe9yzngat378vcezjc2c07r02k2rthqqyu It would be cool if instead of passing hexdata as an argument it could be passed as stdin (possibly with hexdata arg specified as a hyphen, -, to indicate such), and to remove the 'data_len' output going to stderr. Then I could use: $ echo ${KEY} | bx wif-to-public | bx bitcoin160 | bech32 -s 0 -
|
|
|
|
|