From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Date: Tue, 12 Nov 2019 22:30:18 -0800 [thread overview]
Message-ID: <CAPg+sBio_8vT9NNp39rz7m+omfaRs0Mf6JkET1=caoVwvziJSA@mail.gmail.com> (raw)
In-Reply-To: <2sU6YozN9nn30cofkAMhffgjDLZwjG3mvF0nBgOsVQQEY9ROmP72GuHWjnBlF_qa8eeQPU8bxleZqcvRGJgS-uJ2xWYmAm9HjrFWWx_9o8k=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]
On Tue, Nov 12, 2019, 21:33 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Good morning all,
>
> It seems to me that adding the length for checksumming purposes need not
> require the length to be *actually* added in the address format.
>
Indeed!
This has the following properties:
>
> * The bech32 address format is retained, and no explicit length is added.
> * There are now two checksum formats: one with just the witness program,
> the other which validates with the witness program length.
> * Readers that do not understand the new checksum format will simply
> reject them without mis-sending to the wrong witness program.
>
That's very close to what I was suggesting: create an improved bech32
algorithm and use that for future addresses, rather than working around the
problem in the address encoding while keeping the existing bech32 checksum.
Sorry if that wasn't clear from my previous email.
In this case, there is no need to even implicitly include the length in the
checksum algorithm. Replacing the "xor 1" at the end of the algorithm to
"xor (2^30 - 1)" would reduce the occurrence of this weakness from 1/32 to
1/2^30, and have no downsides otherwise. I'd like to do some analysis to
ascertain it actually will catch any other kind of insertion/deletion
errors with high probability as well before actually proposing it, though.
There are other solutions which do include the length in some fashion
directly in the checksum calculation, which may be preferable (I need to
analyse things...). It's also possible to do this in such a way that for
33-symbol and 53-symbol data parts (corresponding to P2WPKH and P2WSH
lengths) the new algorithm is defined as identical to the old one. That
would simplify upstream users of a bech32 library (which would then
effectively need no changes at all, apart from updating the
checksum/decoder code).
That brings me to Matt's point: there is no need to do this right now. We
can simply amend BIP173 to only permit length 20 and length 32 (and only
length 20 for v0, if you like; but they're so far apart that permitting
both shouldn't hurt), for now. Introducing the "new" address format (the
one using an improved checksum algorithm) only needs to be there in time
for when a non-32-byte-witness-program would come in sight.
Of course, I should update BIP173 to indicate the issue, and have a
suggested improvement for other users of bech32, if they feel this issue is
significant enough.
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 3684 bytes --]
next prev parent reply other threads:[~2019-11-13 6:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 22:35 Pieter Wuille
2019-11-07 22:45 ` Greg Sanders
2019-11-08 0:41 ` Matt Corallo
2019-11-08 2:15 ` David A. Harding
2019-11-08 3:15 ` Eric Voskuil
2019-11-10 21:51 ` Pieter Wuille
2019-11-11 1:02 ` Matt Corallo
2019-11-13 2:56 ` Clark Moody
2019-11-13 5:32 ` ZmnSCPxj
2019-11-13 6:30 ` Pieter Wuille [this message]
2020-07-15 20:56 ` Russell O'Connor
2020-07-15 21:05 ` Greg Sanders
2020-07-15 21:11 ` Russell O'Connor
2019-11-08 5:11 ` ZmnSCPxj
2019-11-08 13:03 ` Russell O'Connor
2019-11-08 13:42 ` Damian Mee
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='CAPg+sBio_8vT9NNp39rz7m+omfaRs0Mf6JkET1=caoVwvziJSA@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--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