From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7220FB1F for ; Fri, 8 Nov 2019 02:16:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED8D4710 for ; Fri, 8 Nov 2019 02:16:32 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1iStp9-0000JN-Oi; Thu, 07 Nov 2019 21:16:31 -0500 Date: Thu, 7 Nov 2019 16:15:41 -1000 From: "David A. Harding" To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: <20191108021541.n3jk54vucplryrbl@ganymede> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B, KHOP_HELO_FCRDNS autolearn=no 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 02:16:33 -0000 On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev wrote: > In the current draft, witness v1 outputs of length other > than 32 remain unencumbered, which means that for now such an > insertion or erasure would result in an output that can be spent by > anyone. If that is considered unacceptable, it could be prevented by > for example outlawing v1 witness outputs of length 31 and 33. Either a consensus rule or a standardness rule[1] would require anyone using a bech32 library supporting v1+ segwit to upgrade their library. Otherwise, users of old libraries will still attempt to pay v1 witness outputs of length 31 or 33, causing their transactions to get rejected by newer nodes or get stuck on older nodes. This is basically the problem #15846[2] was meant to prevent. If we're going to need everyone to upgrade their bech32 libraries anyway, I think it's probably best that the problem is fixed in the bech32 algorithm rather than at the consensus/standardness layer. -Dave [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017444.html [2] https://github.com/bitcoin/bitcoin/pull/15846 P.S. My thanks as well to the people who asked the question during review that lead to this discussion: http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html#l-88