Base64-encoded descriptors [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2019-12-26T05:18:00+00:00


Summary:

The Bitcoin community is discussing ways to make descriptors easier to handle for users. Currently, the syntax of descriptors, which include commas, parentheses, and brackets, can be intimidating and difficult to work with. One possible solution is to encode descriptors using Base64, although some community members prefer alternatives like Bech32, Base58, or Base62 due to their user-friendly nature.However, it is important to consider the checksum scheme used by encoding methods like Base58 and Bech32, as they already exist and may not be compatible with descriptors. Descriptors have their own BCH code for descriptor checksums that are optimized for their length and character set. This suggests that the descriptor checksum can be repurposed to work with any encoding scheme, as long as the encoding's character set is covered by the descriptor checksum character set. The descriptor checksum covers all characters on a standard keyboard, allowing for future expansion of descriptors.Chris Belcher, a developer at bitcoin-dev, proposed that descriptors should become the standard for master public keys. However, he acknowledges that the current syntax of descriptors makes it difficult for users to copy and paste them for creating watch-only wallets. The presence of parentheses and commas prevents highlighting by double-clicking, and the syntax can be overwhelming for new users. One solution suggested during discussions with Chris is to base64 encode the descriptors, resulting in a text blob as the master public key without any extra details. This would simplify the process for users and developers alike.Another developer named Will disagrees with encoding descriptors, arguing that it obfuscates useful information that can be quickly viewed. He suggests using alternative encoding methods like base58 or base62 +hrp for PSBT, as they are better suited for double-click copying and pasting. Will also prefers Bech32, base58, or base62 and believes that encoding descriptors does not make much sense in this case.In a recent discussion on the bitcoin-dev mailing list, concerns were raised about the use of bech32 for error detection in longer messages. While bech32 can still encode and decode perfectly well, it cannot guarantee detecting errors beyond a certain length. To address this issue, it was suggested to define derivatives of bech32 that retain error detection properties for longer message lengths, particularly for lightning invoices. It is worth noting that QR codes have their own BCH code scheme for built-in error detection, mitigating this problem when used with descriptors.Despite the usefulness of descriptors, some members expressed skepticism about their practicality for quick transactions, which are well-suited for QR codes. The discussion also touched upon the use of base64 encoding for descriptors as a standard for master public keys. While this encoding method simplifies working with descriptors, there are concerns about the potential for typos in the base64 text decoding into multiple character errors in the descriptor. To overcome this, it was suggested to attach the checksum to the end of the base64 text.Overall, the Bitcoin community is exploring ways to enhance the usability and efficiency of descriptors. Base64 encoding has been proposed as a solution to make descriptors more user-friendly, but complications regarding the descriptor checksum need to be addressed. Discussions with developers like achow101 have contributed to these ideas. Additionally, alternatives to Base64, such as Base58 or Bech32, have been suggested for URL/QR code friendly purposes.


Updated on: 2023-08-02T01:42:42.528074+00:00