From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5A6F0C0893 for ; Fri, 18 Dec 2020 02:02:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 4EB81871ED for ; Fri, 18 Dec 2020 02:02:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bh4aPWy8bRr for ; Fri, 18 Dec 2020 02:02:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 8B4B6871D8 for ; Fri, 18 Dec 2020 02:02:12 +0000 (UTC) Date: Fri, 18 Dec 2020 02:02:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1608256929; bh=hnhxInQgpvDHJAK5KCKJllkM+tlkGiF+TckdhcVCrQ0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=qDt3CzFfSZNiwUvxA3mfHzLJcDOk+WT8B0NB/GIMvwYBwbE+gjMKJ8Z4E988R6jQS sEzAOmGWIByAl6Hr3csaXtIEiiManSmmx1vELXlue/MvxDX//2pBdJbtxd5DcR9FO1 fG25NH8oYfuL8gSMy7Lh8u0V8t07wGoH7TODGfi/eu4bM2xjJr5Cv15ppUBKchmyM1 GehTpdB5V6rM4BZ/0/cWSk3/4WbusPAmVZ9XO5X5FKiHkUdWhpKAnmUnRbclwOHwmA eAjNJWadjLKgQ2b3/FefNFzmYTPPDwU1a9jYXNWTS6FLQpcyOoFAzWxFLG/hSp5fSy tnvvmKiH33JmA== To: Ryan Grant From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: References: <87imblmutl.fsf@rustcorp.com.au> <878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede> <5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net> <20201206130453.tiu36iigva2jj5qn@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2020 02:02:14 -0000 On Tuesday, December 8, 2020 9:39 AM, Ryan Grant w= rote: > 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=3D1 and M=3D0x2bc830a3. > - 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. I think there are two possible interfaces that make sense: - Have the caller explicitly specify whether they want bech32 or bech32m (w= hich someone - I think Rusty? - started using in reference to this new code= and I'm going to adopt now). - Have the bech32 decoding function return a tristate (failed, valid as bec= h32, valid as bech32m). No string is ever valid as both, so there is no los= s of information here. The former is a bit cleaner, and also the only real choice if error locatio= n hinting is desired. The second is more efficient if decoding twice is a p= erformance concern. Cheers, -- Pieter