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 CA67FC013A for ; Mon, 18 Jan 2021 05:59:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id B1AB6856BF for ; Mon, 18 Jan 2021 05:59:18 +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 j7RRrh5GMrOc for ; Mon, 18 Jan 2021 05:59:17 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 5181D854C4 for ; Mon, 18 Jan 2021 05:59:17 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id x20so22306623lfe.12 for ; Sun, 17 Jan 2021 21:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L8hHfu+pCaD8Cd8409CUTcAOEmnimyfMfrwYeNEbgXw=; b=Jlrv5HYdqOQseUvOZ5PEULn99Fdbujetr0cg/EPjcwXSDpFGUfYB5yy55cTJy9+aq+ rO86AmO0QRCJ3/i7q4KLFOwh+KQ7fkpaKoXttJQg8EFDcGKFYMnIH4QrKwQk2OUAo1Cv UOsMSpeAjYhSktP/VFuU3Gyr+anBximL0d8ijQ6xQljw4MJqwPDWa+zW+n5fJclBEajZ YyWBlA7dankw7JMBWRiRmAr4aHLcScENMwMwIhdIjuThO0sXn0wmUyyzBY5dfpxI0gOJ JRJ2Yu0aEmUvvSFgjIH3QfVAU7zEzkjnGwk2iVzjStg103AbJnqDJvA89GBxM2ddxIB+ rnNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L8hHfu+pCaD8Cd8409CUTcAOEmnimyfMfrwYeNEbgXw=; b=P6GimdYsRUleQ7UqZeq+oODgDw8iUJiQzsGv9aHyPy6fhvDovJugNGJxziGPKcqWrE XckvWmchlEKMo16tbRC7VYbA0ruAVN/krT98IouMQX38RlIJqi9MZhf302l88Pio+Sjb xRTTisqb8OFnWJvF/g/tMRxE3oC07kUcW/lnkIItqlpRpfuxTCiBR7LnRgKN+0rF9rhz fWVBc4j65gcfEYjWdDwpb/UtLMCghBoygAA85olcyck2H+Wyb4nK9j1E8O9zDUrDU2Te FBxjrjFOjbkrhn95vKEP+HOIS8CuHHVnObaykHZSVu9Ufo9b26fXA/2robs1CaWEeuff 8l2A== X-Gm-Message-State: AOAM531lekLpakRf8/KqFrQnS4EyRoXjlOTQ0bo97z6kL2znDtfSR5uY kt93AzVn/pjPTnPjqRsZRbMPOemjLBnwR4VgRdPy5S9rcs0= X-Google-Smtp-Source: ABdhPJx8WLyZPRVTvN/cIHTK4FWT1YT7fpVhafIzhzw6ZXkttkjzFaGiImQ5PztUYggu2AMRss/QzdXqbZ772tvvoTM= X-Received: by 2002:ac2:418e:: with SMTP id z14mr11066764lfh.126.1610949555141; Sun, 17 Jan 2021 21:59:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: nakagat Date: Mon, 18 Jan 2021 14:59:05 +0900 Message-ID: To: Pieter Wuille Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Jan 2021 07:40:22 +0000 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 05:59:18 -0000 Dear. Peter, I'm not good at English, so I'm sorry for the poor explanation. I thought that BECH32M_CONST could be created from hrp and data instead of constants. I thought that the error position would be the same as bech32 by recalculating the value created from hrp and data. If this were possible, I thought I could commit hrp and data to the checksu= m. Thank you. Takatoshi Nakagawa 2021=E5=B9=B41=E6=9C=8818=E6=97=A5(=E6=9C=88) 13:15 Pieter Wuille : > > 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 contri= butions to update other languages are welcome!) > > - Updated website, including error-locating JS decoder, and demo: http://= bitcoin.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= /bip-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= /bech32m? > > > 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,= etc. > > 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= algorithm? > > If you compute the checksum using the HRP and the data using a hash funct= ion, you just 2^-30 failure probability for any error. The idea behind Bech= 32 was doing better than that for common errors: any error that consists of= up to 4 substitutions are a failure probability of 0 - far better than a h= ash can do. > > 2) Can we keep using Bech32's algorithm, but compute the final xorred-in = constant 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 = constant from the HRP (but not the data) using a hash function? > > It would mean that some (very) small set of potential HRPs would exhibit = much worse behavior than others - including the 'q'-before-'p' that the ori= ginal Bech32 has. > > Does that clarify things? > > Cheers, > > -- > Pieter >