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 EF7B4C013A for ; Mon, 18 Jan 2021 04:15:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id D712785701 for ; Mon, 18 Jan 2021 04:15:59 +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 Y3OnxEXh9nt4 for ; Mon, 18 Jan 2021 04:15:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 09D798561E for ; Mon, 18 Jan 2021 04:15:57 +0000 (UTC) Date: Mon, 18 Jan 2021 04:15:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail2; t=1610943355; bh=lSsqimuHU9nNLemaarvugAdbwhCnK8Asx1527b5uu8c=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=WO5Ntx29HrIbarvvGSlnDfnNb0cHwrCkeD9dWvhiPiqgpyyRvZplGuw95kWFJ8Wxg du4HgFgOq6/vvm680IPq6D45NBxpduS1c62S1gblfJVt2LNsu4oqRUF1nNWicR46S4 7Fpl8a2EiSeJduq6jlPvavGhspB6baaiG6u1DX2VkUNwQGTjQQ95B+OXiRPmvuq2aK lfglQYeNdKE+TiGZrfWltcESQ0Z89D/ukWHSlJPexNuXd4gMb6x9J/SCnAKjhfuXX9 XttbH+Lt+ADV5fD4tBfddapXbA9eqQQc8z2CzBgu5xuokDxHwkaL3G8uedNGu0FY2D dWaFI5BVEAMwA== To: nakagat From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address 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: Mon, 18 Jan 2021 04:16:00 -0000 Hi all, A few updates, in response to comments here and in a few other places: - Updated several reference implementations (C, C++, Python, Javascript) to= support Bech32m: https://github.com/sipa/bech32/tree/bech32m (but contribu= tions to update other languages are welcome!) - Updated website, including error-locating JS decoder, and demo: http://bi= tcoin.sipa.be/bech32/demo/demo.html - Opened a Bitcoin Core PR: https://github.com/bitcoin/bitcoin/pull/20861 - Updates to the BIP draft (https://github.com/sipa/bips/blob/bip-bech32m/b= ip-bech32m.mediawiki): * Made the title clearer (so it doesn't imply Bech32m is used for v0) * Added rationale for not permitting both Bech32 and Bech32m for v0 * Added a section on error location * Added links for more reference implementations On Friday, January 15, 2021 12:01 AM, nakagat wrote: > I read the BIP draft of Bech32m and implemented it in Go. Cool! Do feel like contributing it to https://github.com/sipa/bech32/tree/b= ech32m? > Let me ask you one question. > Does Checksum have to be fixed? > The 'bech32_verify_checksum' function has hrp and data as parameters, > so how about committing Checksum with these two values? > > For example, calculate Checksum from hrp and data using hash, chacha20, e= tc. I'm not entirely sure what you mean. Do you mean: 1) Can we use a hash function to compute the checksum instead of Bech32's a= lgorithm? If you compute the checksum using the HRP and the data using a hash functio= n, you just 2^-30 failure probability for any error. The idea behind Bech32= was doing better than that for common errors: any error that consists of u= p to 4 substitutions are a failure probability of 0 - far better than a has= h can do. 2) Can we keep using Bech32's algorithm, but compute the final xorred-in co= nstant from the HRP and the data using a hash function? That would be functionally equivalent to (1). 3) Can we keep using Bech32's algorithm, but compute the final xorred-in co= nstant from the HRP (but not the data) using a hash function? It would mean that some (very) small set of potential HRPs would exhibit mu= ch worse behavior than others - including the 'q'-before-'p' that the origi= nal Bech32 has. Does that clarify things? Cheers, -- Pieter