BECH32(3em)

πŸ“¦ version 1.1.1, in nixos 26.05, nixpkgs unstable

πŸ’– NAME πŸ’–

okay so bestie, this is the BECH32(3em) page, and it's all about bech32 β€” the bech32 codec. that's the whole name, and yes, she's iconic. ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

first things first, you load it like this:

local bech32 = require 'bech32'

this module exposes a bech32 codec. the implementation is based on the original C++ reference implementation, but changes were made to fill user-provided buffers (instead of relying on memory allocators). the new interface is friendlier to botan.secure_byte_span. slay. πŸ’…

normally it's not important to use secure allocators for bech32, because it's mostly used to encode public keys. however, that's not always the case (e.g. nostr's nsec1... addresses). even if you do use bech32 to encode secrets, it still doesn't warrant an excuse to use secure allocators. πŸ™ˆ

nonetheless, this module will always β€” except for the human-readable part β€” avoid allocations as a way to be useful even for those few who need it. so if you need to hold bech32 data exclusively through secure allocations (except for the human-readable part[1]), you can use this module. periodt. 🫢


πŸ“ NOTES πŸ“

  • [1] memory allocations might still happen to hold the lower-case version of the human-readable part. however, even the source code for your program already holds the expected human-readable part of a bech32 address. in a way, your program is already β€œleaking” the human-readable part. it's not a safe pattern to depend on the secrecy of the human-readable part of bech32 addresses. πŸ’€
⚠️ vibe check: do not treat the human-readable part as a secret. that is not a safe pattern, bestie. no cap. 🚫

xoxo, your Unix bestie πŸ’… β€” this was from Emilua 0.12.1, dated 1980-01-01, and the page is BECH32(3em). iconic behavior, honestly. πŸŽ€βœ¨

πŸ“¦ where this page comes from