This week’s newsletter summarizes a discussion about the fastest way to verify that a BIP32 master seed backup probably hasn’t been corrupted without using any digital devices. Also included are our regular sections with announcements of new releases and release candidates, plus summaries of notable changes to popular Bitcoin infrastructure software.
● Faster seed backup checksums: Peter Todd replied to the discussion about a draft BIP for Codex32 (see last week’s newsletter), a scheme that allows creating, verifying, and using recovery codes for a BIP32 seed. A particular advantage of Codex32 over existing schemes is the ability to verify the integrity of backups using just pen, paper, documentation, and a modest amount of time.
As designed, Codex32 provides very strong assurances about its ability to detect errors in the backups. Peter Todd suggested a far easier method would be to generate recovery codes that could have their parts added together to produce a checksum. If dividing the checksum by a known constant produced no remainder, it would verify the integrity of the backup within the parameters of the checksum algorithm. Peter Todd suggested using an algorithm that provided roughly 99.9% protection against any typos, which he thought would be sufficiently strong, easy for people to use, and easy for people to memorize so that they didn’t need the extra Codex32 materials.
Russell O’Connor replied that a full Codex32 recovery code can be checked much faster than full verification if the user is willing to accept less protection. Checking just two characters at a time would guarantee detection of any single-character mistake in a recovery code and provide 99.9% protection against other substitution errors. The process would be somewhat similar to generating the type of checksum that Peter Todd described, although it would require using a special lookup table which ordinary users would be unlikely to memorize. If verifiers were willing to use a different lookup table each time they checked their code, each additional verification would increase their chance of detecting an error up until the seventh verification, where they would have the same assurance as they would receive from performing full Codex32 verification. No changes are required to Codex32 to obtain the reinforcing quick check property, although Codex32’s documentation will need to be updated to provide the necessary tables and worksheets in order to make it usable.
Releases and release candidates
New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.
Notable code and documentation changes
Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.
● Bitcoin Core #25943 adds a parameter to the
sendrawtransactionRPC to limit the amount of funds burned per output. If the transaction contains an output whose script is heuristically deemed to be unspendable (one with an
OP_RETURN, an invalid opcode, or exceeding the maximum script size) and whose value is greater than
maxburnamount, it will not be submitted to the mempool. By default, the amount is set to zero, protecting users from unintentionally burning funds.
● Bitcoin Core #26595 adds
passphraseparameters to the
migratewalletRPC in order to support migrating encrypted legacy wallets and wallets not currently loaded into descriptor wallets.
● Bitcoin Core #27068 updates how Bitcoin Core handles passphrase entry. Previously, a passphrase containing an ASCII null character (0x00) would be accepted—but only the part of the string up to the first null character would be used in the process of encrypting the wallet. This could lead to a wallet having a much less secure passphrase than the user expected. This PR will use the entire passphrase, including null characters, for encryption and decryption. If the user enters a passphrase containing null characters which fails to decrypt an existing wallet, indicating they may have set a passphrase under the old behavior, they’ll be provided with instructions for a workaround.
● LDK #1977 makes public its structures for serializing and parsing offers as defined in draft BOLT12. LDK doesn’t yet have support for blinded paths, so it can’t currently send or receive offers directly, but this PR allows developers to begin experimenting with them.