Published on: 2018-06-23T19:49:54+00:00
Pieter and Russell O'Connor have been discussing the correctable error rates of codes designed for length 341, which is the first length enough to support 512 bits of data. The number of correctable errors includes errors inside the checksum characters themselves, meaning that aiming for a certain percentage of correctable characters increases the numbers dramatically. Pieter provides some numbers for codes restricted to a total of 341 characters and assuming 103 data characters, including 26 checksum characters (adding 25%, 20% of overall string), seven errors can be corrected (5% of overall string). With 62 checksum characters (adding 60%, 38% of overall string), 17 errors can be corrected (10% of overall string). With 116 checksum characters (adding 113%, 53% of overall string), 33 errors can be corrected (15% of overall string) and with 195 checksum characters (adding 189%, 65% of overall string), 60 errors can be corrected (20% of overall string). Furthermore, for codes restricted to 1023 characters total (including the checksum characters) and assuming 103 data characters, including 27 checksum characters (adding 26%, 21% of overall string), seven errors can be corrected (5% of overall string). With 64 checksum characters (adding 62%, 38% of overall string), 17 errors can be corrected (10% of overall string), with 127 checksum characters (adding 123%, 57% of overall string), 36 errors can be corrected (15% of overall string), with 294 checksum characters (adding 285%, 74% of overall string), 80 errors can be corrected (20% of overall string), and with 920 checksum characters (adding 893%, 90% of overall string), 255 errors can be corrected (25% of overall string). Russell O'Connor suggests that it might be better to support multiple checksum variants instead of having a trade-off between the length of the code and recovery properties, as the user's medium of storage is likely to vary from person to person. He personally would probably be interested in the 51 or even 102 character checksums variants. Pieter offers to construct reference source code for any of these variants.The number of checksum characters needed to correct errors in codes designed for a length of 341 varies based on the number of errors to be corrected. For correcting one error, three checksum characters are required, and for correcting two errors, seven checksum characters are required. This pattern continues up to correcting 28 errors, which requires 102 checksum characters, or approximately double the length of the code. The trade-off between code length and recovery properties is determined by the user's medium of storage. It may be beneficial to support multiple checksum variants to accommodate varying storage mediums. The proposal suggests supporting longer checksum variants, such as the 51 or 102 character checksums.In an email to the bitcoin-dev mailing list, Jonas Schnelli discussed the presence of 520 bits in a BIP32 chain code with a compressed public key. According to Schnelli, the first 256 bits are the chain code and the remaining 264 bits define the public key. He also explained that in a 33 byte compressed public key, only one bit from the first byte is necessary to convey information, allowing for the other seven bits to be discarded. This reduction can result in a one-character decrease in the bech32 encoded result.Pieter proposed to construct a code and implementation for various BCH codes on the request of Jonas Schnelli. Pieter presented an example BCH code for base32 data which adds 27 checksum characters and can correct up to 7 errors in strings with length up to 1023, including the checksum characters themselves. The code can encode sequences of integers ranging from 0 to 31. He also provided an example of how to decode and correct errors in the encoded message. However, the code he provided has no special properties beyond the ones it is designed for. Pieter suggested that he could easily generate similar code for BCH codes with different properties.The writer expresses concerns about the use of Bech32 for error correction, noting that it is only efficient at correcting one error up to length 1023. While the checksum provides a small constant speedup, it doesn't fundamentally improve recovery. The writer suggests a code that includes computational costs for error correction during disaster recovery and notes that deriving one million child keys and comparing them against an address table would take less than a minute on consumer systems. They propose a trade-off between code length and recovery properties, suggesting that 5% error correction with a 26 char checksum is acceptable. The resulting string with 26 checksum chars is longer than the Bech32 equivalent but still considered acceptable for disaster recovery purposes.
Updated on: 2023-08-01T23:19:34.371665+00:00