Ryan Grant [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-08 📝 Original message:It looks like a good ...
📅 Original date posted:2020-12-08
📝 Original message:It looks like a good strategy for a bech32 library that is external to
Bitcoin Core would be:
- Default to the new M, under the same bech32 brand.
- Provide an interface to explicitly use both M=1 and M=0x2bc830a3.
- If decoding fails, throw an error; but in constructing that error
inform whether the other M would have succeeded.
- Provide an interface for a BIP173 implementation to peek at the
witness version byte of the data part, which may also involve
sanity-checking that byte for errors using a BIP173-specific
understanding of the appropriate checksum.
Return values for this special interface might currently be:
"it's version zero, based on a clean decoding",
"it's version one, based on a clean decoding",
"it's version zero, based on an auto-corrected byte",
"it's version one, based on an auto-corrected byte",
"no result, due to a decoding error on this byte", and
"too many errors to say anything more about decoding".
Although the reasoning is clear for doing so, looking into the data
that is supposed to be checksummed to determine which checksum to use
is not very elegant. There are two trips into a bech32 library for a
BIP173 decoding, and an indeterminate result on the version byte would
require heuristics for deciding what to do with the rest of the data
part to even advise the user on the error. Because of this, as a
library writer I would be tempted to auto-correct the witness version
byte (against the "SHOULD NOT" advice of BIP173's current version), if
it were the only one corrupted, as per the example return values
above. Please advise.
Some of the libraries that will be contemplating these steps include:
https://github.com/topics/bech32?o=desc&s=stars
Here are three existing uses of bech32 that are external to Bitcoin Core:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
https://github.com/btcontract/lnurl-rfc
https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki
Of the above, I think BIP136 can be unconditionally moved to
M=0x2bc830a3 due to having little legacy burden.
📝 Original message:It looks like a good strategy for a bech32 library that is external to
Bitcoin Core would be:
- Default to the new M, under the same bech32 brand.
- Provide an interface to explicitly use both M=1 and M=0x2bc830a3.
- If decoding fails, throw an error; but in constructing that error
inform whether the other M would have succeeded.
- Provide an interface for a BIP173 implementation to peek at the
witness version byte of the data part, which may also involve
sanity-checking that byte for errors using a BIP173-specific
understanding of the appropriate checksum.
Return values for this special interface might currently be:
"it's version zero, based on a clean decoding",
"it's version one, based on a clean decoding",
"it's version zero, based on an auto-corrected byte",
"it's version one, based on an auto-corrected byte",
"no result, due to a decoding error on this byte", and
"too many errors to say anything more about decoding".
Although the reasoning is clear for doing so, looking into the data
that is supposed to be checksummed to determine which checksum to use
is not very elegant. There are two trips into a bech32 library for a
BIP173 decoding, and an indeterminate result on the version byte would
require heuristics for deciding what to do with the rest of the data
part to even advise the user on the error. Because of this, as a
library writer I would be tempted to auto-correct the witness version
byte (against the "SHOULD NOT" advice of BIP173's current version), if
it were the only one corrupted, as per the example return values
above. Please advise.
Some of the libraries that will be contemplating these steps include:
https://github.com/topics/bech32?o=desc&s=stars
Here are three existing uses of bech32 that are external to Bitcoin Core:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
https://github.com/btcontract/lnurl-rfc
https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki
Of the above, I think BIP136 can be unconditionally moved to
M=0x2bc830a3 due to having little legacy burden.