summaryrefslogtreecommitdiff
path: root/40
diff options
context:
space:
mode:
authorZmnSCPxj <ZmnSCPxj@protonmail.com>2019-11-13 05:32:32 +0000
committerbitcoindev <bitcoindev@gnusha.org>2019-11-13 05:32:43 +0000
commit9a133d54de290dd00e5aede0592559054abef7aa (patch)
treed182fa1c9d8577d48ca9b778b14a8979139bd69e /40
parent3fb83205810c6a0647c94d1f1c0739d5f5885d30 (diff)
downloadpi-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/10e5929363af2f60940da2b03c140839632316110
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
+
+