1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <nakagat@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id CA67FC013A
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 18 Jan 2021 05:59:17 +0000 (UTC)
Received: by mail-lf1-f54.google.com with SMTP id x20so22306623lfe.12
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <jfRUzc8uB5fpIQy-a_TfTwjAD4FMtf2eInfHdgZRoLwc0NdTv7srnRLtmwFHPLInJfglSzOXXe0SVR3cgHejGPi0Kwl81UV_wkwVJcQi1rA=@wuille.net>
<CAHk9a9d_xm2nO1t5GsLJiny1V3H=uv8jGuUTywQetZQOXxyG9w@mail.gmail.com>
<N9ny4XfpI4SATvCXSKO_ns03ONm4p17tAGXxInoXIe16S7zfH6b8Uj2SkS-pL5sEEp7Wpyi0RZ8J92WZPDeHYKBBuq1xnV6eEUbKouej-TU=@wuille.net>
In-Reply-To: <N9ny4XfpI4SATvCXSKO_ns03ONm4p17tAGXxInoXIe16S7zfH6b8Uj2SkS-pL5sEEp7Wpyi0RZ8J92WZPDeHYKBBuq1xnV6eEUbKouej-TU=@wuille.net>
From: nakagat <nakagat@gmail.com>
Date: Mon, 18 Jan 2021 14:59:05 +0900
Message-ID: <CAHk9a9egxmTQqSLs9PUuH1L8q_c7hp_oo4jT1+BP0ga=aFCPhQ@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <bitcoin-=
dev@wuille.net>:
>
> 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 <nakagat@gmail.com> 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
>
|
