> bech32 | segwit | bc1 <

Bech32 is a checksummed base32 format used primarily for Bitcoin SegWit addresses. It was designed to be more reliable than previous address formats with better error detection.

Bech32m is an improved version that fixes a weakness in the original Bech32 checksum algorithm. It's used for Taproot addresses (bc1p) while original SegWit uses Bech32.

Lowercase-only addresses create smaller QR codes and are easier to type. The format is case-insensitive but canonically lowercase for consistency.

HRP (Human Readable Part) identifies the type and network. Common examples: 'bc' for Bitcoin mainnet, 'tb' for testnet, 'ltc' for Litecoin.

Bech32（BIP-173，2017 年提出）是比特币 SegWit（隔离见证）地址 的新格式，取代了早期的 Base58Check。一个典型的 SegWit 地址长这样：
bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

结构分解：
• bc → HRP（Human Readable Part，人类可读部分）：bc = 比特币主网，tb = 测试网，bcrt = regtest。
• 1 → 分隔符（始终是字符 1，因为 1 不在 Bech32 字符集中，所以用它划分 HRP 和 data）。
• qw508d6qejxtdg4y5r3zarvary0c5xw7kv → 数据部分（5-bit 分组的 Base32 编码，包含见证版本 + 见证程序）。
• 最后 6 个字符 kv8f3t4 → BCH 校验码，可检测任意位置的 4 个错误，并精确定位到出错位置。

为什么比 Base58 好？
• 更强的错误检测：Base58Check 仅用双 SHA-256 前 4 字节做校验，Bech32 的 BCH 码能精确告诉你 "第 7 位错了"。
• 全小写：QR 码以 Alphanumeric Mode 存储，比 Base58 的混合大小写节省 ~30% 空间。
• 字符集避免歧义：移除了 1、b、i、o 等易混淆字符。

Bech32m（BIP-350，2021 年）是 Bech32 的修订版，修复了原始 Bech32 校验和一个微妙的弱点：在某些特定长度下，末尾附加 q 不会破坏校验和（即可能把一个合法地址错误扩展成另一个合法地址）。

使用规则：
• SegWit v0 地址（bc1q...，P2WPKH/P2WSH）：使用 原版 Bech32。
• SegWit v1+ 地址（bc1p...，Taproot/P2TR）：使用 Bech32m。

两者的编码/解码流程几乎相同，唯一区别是校验和生成时常数不同：
• Bech32：常数为 1。
• Bech32m：常数为 0x2bc830a3。

如何区分：看地址第 3 个字符（分隔符 1 之后的第一个字符）。q = v0（Bech32），p = v1（Bech32m/Taproot），z/... = v2+（未来版本，继续用 Bech32m）。

Bech32 字符集特意设计为 32 个不易混淆的字符：
q p z r y 9 x 8 g f 2 t v d w 0 s 3 j n 5 4 k h c e 6 m u a 7 l

被刻意排除的字符：
• 1, b, i, o — 与数字 1 和 0 以及字母 l 难以区分（特别是在某些字体下）。
• 1 还被征用作为 HRP 分隔符（因为它永远不会出现在数据中）。
• Base58（比特币老地址）排除 0、O、I、l，但保留了 i 和 b——Bech32 更进一步。

字符排序设计有意图：字母表中相邻的字符二进制位差异 汉明距离较大（≥ 2 位），这样打字错误一般导致 ≥ 2 位翻转，BCH 校验就能检测到。这就是 Bech32 为何能 精确定位错误位置 而不仅仅是检测到 "某处有错"——字符集本身编码了几何冗余。

是的。Lightning Network 的 BOLT-11 发票（lnbc1p...、lntb1p...）使用 原版 Bech32（不是 Bech32m），因为 BOLT-11 规范（2017）在 Bech32m 出现之前就定型了。

HRP 约定：
• lnbc — Lightning on Bitcoin mainnet
• lntb — Lightning on Bitcoin testnet
• lnbcrt — Lightning on regtest
• lnsb — Lightning on signet

Lightning 发票能非常长（最多几千字符），因为它在 Bech32 数据区编码了：金额、到期时间、路由提示、payment hash、节点公钥签名等。传统 Bitcoin 地址只有 ~40 字符，Lightning 发票可能有 300+ 字符。但校验和机制仍是同一套 BCH 码 + Bech32 字符集。

其他使用 Bech32 的链：Cosmos（cosmos1...）、Zcash Sapling 地址（zs1...）、Monero 的 OpenAlias 记录——Bech32 已成为跨链地址编码的事实标准。