From: Ryan Grant <bitcoin-dev@rgrant•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)
Date: Tue, 8 Dec 2020 17:39:23 +0000 [thread overview]
Message-ID: <CAMnpzfqy-=65gZ_Nj1EjhLV3ExZhnJQ=9o+nAqf11VjxXP3L+Q@mail.gmail.com> (raw)
In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede>
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.
next prev parent reply other threads:[~2020-12-08 18:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 0:21 Rusty Russell
2020-10-08 14:59 ` David A. Harding
2020-10-08 15:21 ` Russell O'Connor
2020-10-15 1:40 ` Rusty Russell
2020-10-16 21:09 ` Pieter Wuille
2020-10-19 0:49 ` Rusty Russell
2020-10-19 22:55 ` Pieter Wuille
2020-10-20 0:42 ` Rusty Russell
2020-10-20 3:31 ` Rusty Russell
2020-10-20 9:21 ` Riccardo Casatta
2020-10-20 10:29 ` David A. Harding
2020-10-20 20:12 ` Pieter Wuille
2020-10-20 23:52 ` Mike Schmidt
2020-10-21 4:51 ` Rusty Russell
2020-11-06 19:49 ` Mike Schmidt
2020-12-05 23:10 ` Pieter Wuille
2020-12-06 13:04 ` David A. Harding
2020-12-06 20:43 ` Pieter Wuille
2020-12-08 17:39 ` Ryan Grant [this message]
2020-12-18 2:02 ` Pieter Wuille
2020-10-21 3:05 ` ZmnSCPxj
2020-10-21 4:39 ` Rusty Russell
2020-10-28 0:20 ` Pieter Wuille
2020-12-05 22:59 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMnpzfqy-=65gZ_Nj1EjhLV3ExZhnJQ=9o+nAqf11VjxXP3L+Q@mail.gmail.com' \
--to=bitcoin-dev@rgrant$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox