diff options
author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-11-13 05:32:32 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-11-13 05:32:43 +0000 |
commit | 9a133d54de290dd00e5aede0592559054abef7aa (patch) | |
tree | d182fa1c9d8577d48ca9b778b14a8979139bd69e /40 | |
parent | 3fb83205810c6a0647c94d1f1c0739d5f5885d30 (diff) | |
download | pi-bitcoindev-9a133d54de290dd00e5aede0592559054abef7aa.tar.gz pi-bitcoindev-9a133d54de290dd00e5aede0592559054abef7aa.zip |
Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Diffstat (limited to '40')
-rw-r--r-- | 40/10e5929363af2f60940da2b03c140839632316 | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/40/10e5929363af2f60940da2b03c140839632316 b/40/10e5929363af2f60940da2b03c140839632316 new file mode 100644 index 000000000..41dd5647b --- /dev/null +++ b/40/10e5929363af2f60940da2b03c140839632316 @@ -0,0 +1,110 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A20FAB9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 13 Nov 2019 05:32:43 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch + [185.70.40.130]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4CFF9712 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 13 Nov 2019 05:32:42 +0000 (UTC) +Date: Wed, 13 Nov 2019 05:32:32 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1573623159; + bh=T9OU3qE0drWG/79A/K6n2+4/Z+7mFjCKUVjGy7FuP7M=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: + From; + b=SjYj7kphyyQik9nYNlR/xO9pL9HTVEtXfQqwUEpXSrvQnFcgv+4hvJ2l6CC6ptIcE + 8S9kA+rHthla5B8IlqSHw9owUbQgALck0RUGuIMAd2qwowGCsFxogSZwWIyt+yGidL + FFBPH7yweSwzconvjwqNulh53kDIL6VCeyUORkLg= +To: Clark Moody <clark@clarkmoody.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <2sU6YozN9nn30cofkAMhffgjDLZwjG3mvF0nBgOsVQQEY9ROmP72GuHWjnBlF_qa8eeQPU8bxleZqcvRGJgS-uJ2xWYmAm9HjrFWWx_9o8k=@protonmail.com> +In-Reply-To: <CAHGSxGv_BQAAkdcxsqVsjphqaoE=Xm05jXhdBnGw+m+vRxeQYQ@mail.gmail.com> +References: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com> + <20191108021541.n3jk54vucplryrbl@ganymede> + <CAPg+sBgus6HgYPVbXaAx51nO2ArsR3-6=obe2AwkO8kh11fB6Q@mail.gmail.com> + <611b4e5b-e7cf-adc7-31e1-b5ff24b6574b@mattcorallo.com> + <CAHGSxGv_BQAAkdcxsqVsjphqaoE=Xm05jXhdBnGw+m+vRxeQYQ@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot + addresses +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 13 Nov 2019 05:32:43 -0000 + +Good morning all, + +It seems to me that adding the length for checksumming purposes need not re= +quire the length to be *actually* added in the address format. + +So, currently, below is my understanding of bech32 validation: + +* Run BCH checksum on witness program. +* Compare checksum to checksum in address. + * If the checksum matches: + * If version is 0, validate that the witness program is length 20 or 32= +. + * Else accept. + * If the checksum does not match: + * Reject + +Let me propose then: + +* Run BCH checksum on witness program. +* Compare checksum to checksum in address. + * If the checksum matches: + * If version is 0, validate that the witness program is length 20 or 32= +. + * Else validate that the witness program is length 32. + * If the checksum does not match: + * Get the length of the witness program. + * Prepend the length to the witness program. + * Run BCH checksum on concatenated length | witness program. + * Compare checksum to checksum in address. + * If the checksum matches: + * Accept. + * Else reject. + +A writer of bech32 addresses would then: + +* If the witness program is length 32, or witness version is 0 and witness = +program length is 20, use a non-length-prefixed checksum. +* Otherwise, use a length-prefixed checksum (but not include the length in = +the address, just change the BCH checksum). + +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, th= +e other which validates with the witness program length. + * Readers that do not understand the new checksum format will simply reje= +ct them without mis-sending to the wrong witness program. + +Is the above acceptable? + +Regards, +ZmnSCPxj + + |