PQ-single-address-backup - BIP-38 for P2MR (bc1z) - 104-char encrypted backup format

The recent update on the cryptographic payload format introduces significant improvements to enhance security and user experience. The new format, described as BIP-360 compatible, eliminates the hardcoded prefixes bc1z/bc1r, ensuring a more flexible and robust design. The seed configuration remains a pure 32-byte SLH-DSA. In the upcoming version 2, there will be an internal restructuring where the versioning information will be moved within the authenticated payload. This adjustment allows for a payload structure that includes a 1-byte version, a 1-byte algorithm identifier, and a 32-byte seed encrypted through AEAD using scrypt(password). This change aims to enhance the reliability of the decoding process by enabling it to reject mismatched wrappers due to incorrect passwords or unsupported versions while maintaining human-readable algorithm/key derivation function/encryption lines solely as hints.

Further enhancements focus on the recovery user experience, particularly concerning long-lived paper backups. The plan includes maintaining a 104-character outer fixed length to aid in scanning and visual completeness checks, akin to the BIP-38 6P invariant. Additionally, a checksum will be integrated within this 104-character encoding to facilitate pre-key derivation function typo detection. The recovery flow will involve a sequence of checks: length verification, checksum validation, followed by key derivation function processing, AEAD decryption, and explicit error handling for typos, wrong passwords, or unsupported versions. Test vectors will also be added to address scenarios involving corrupted, truncated, or incorrectly passworded backups.

Lastly, the decision to keep the outer size at 104 characters is driven by the need to balance human usability factors with technical interoperability. Although there's an openness to increasing the outer wrapper size slightly if required by community preferences, the essential attributes of having a fixed length combined with a checksum and maintaining the one-line-per-key standard are prioritized over the precise number of characters. These updates have been reflected in the updated repository, and the specifications for version 2 will soon be published to incorporate these changes.