Base64 ASCII armoring

[dr-orlovsky]

Bech32(m) has a restriction that its algorithms are efficient only to handle no more than 90 characters of bech32 encoded length. Also, the whole purpose of Bech32 is to encode the data which a frequently copied and pasted around (like in instant messages or texts), of a small size.

In many cases in LNP/BP and RGB we have to deal with blocks of binary data, which must be transferred between users, but which are for sure longer than 90 characters. Thus, they do not necessary fit a single e-mail or instant message, and would not benefit from bech32 single-click copy/paste; tat the same time Bech32 is twice longer than Base64 encoding.

Doing plain Base64 (as done in PSBT) is not very usable: it carries no information for the user about which data are encrypted, and no checksum. PGP/GPG did a good job inventing ASCII armoring, and I think in LNP/BP we have to follow the same approach.

What can benefit from Base64 encoding and ASCII armoring:

• RGB smart contract consignments (especially for asset issue consignments)
• Small RGB transfer consignments sent in e-mail etc
• Compiled RGB schemata
• Compiled strict encoding type system
• Compiled AluVM code

Also, armoring may enhance existing types which already use Base64:

• PSBT

CC @cryptoquick

Related:

• Switch to Base64 encoding for the consignments RGB-WG/rgb-std#10
• Implement Base64 ASCII armoring library rust-lnpbp#224
• https://github.com/RGB-WG/rgb-node/discussions/243