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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B7CE040B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 22:35:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com
[209.85.210.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E06F196
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Nov 2019 22:35:55 +0000 (UTC)
Received: by mail-ot1-f46.google.com with SMTP id t4so3529509otr.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Nov 2019 14:35:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=xdAvDds6hRdYlEp8o7MddHQIb2QSUSIY3FoiTjk2uKg=;
b=LIG2GKvgTZ81hmiLtFEb1hzOOvrwHIibIB08nlA5abkY+XelRiyKYxvZGoLZp1TMCt
4OqwwFUeDzoMmrp+Dwi+vXnfnA+dhWYdaH9U+UaoKXZWSUg4eqV7RX37nzYxY7PQkDsg
ziPhIE6yByersp0qIqJQyai5NnmTRk1QTCTqR8+i5IEOfUW4ut9VUPTJk+EHtOWvHCFl
HJu4p7iu80kqa7FAA5HV+vMSXMfX8oUuWIo4z3580qdH7t+vw9XGrn3Y9fR7qa1rOnVc
CT0OJwp1bRs0g7X4IiFT1pVaJNoPMCfgNkn3udF5SiB5usRqBiRqUASpQasQqtHTGk9X
jqNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=xdAvDds6hRdYlEp8o7MddHQIb2QSUSIY3FoiTjk2uKg=;
b=h62T+J4N/SyGr6tipcel3B8PKop6iYshl2qFZQScXnR5wfM6iZWbxE1bnKd3SBQGnN
eP9SJi5kDj0gYky51NkgmPh9U3CBYZDvrvzE9LvHw+qPXmHQe98AGOPBuojQKSPVB/dK
aNf5knXm1XcmRh7ld8qmNVVXLGTWhTMEWrfsiCs1CEkC+/ahgodaTbqZgvChlPATX+QU
SYPeO65EjveS+82fwWMzmjLPrXkEbrsGG3D2QDLbn3YogBJj3wMSlTuNg3toDZZHcAX8
C2plvLPY39fvuZPn0caPtXk5rhTkIwt18aNKcqyvQ2iYPlFQ67ov+DYFW/dE6R/m67QO
DbpQ==
X-Gm-Message-State: APjAAAVMcp9oYH8STZJH65T0YW4d/aPCS9fvrAzeND2K/AtZ/LSzcoS7
ysUIEhPoD5bsCQtNcmosB04Z66p+zB5YIe13O3zwYIQVKlc=
X-Google-Smtp-Source: APXvYqxWDP3ymPw+q2Fdjm6wibq0H24G7AFyBgIkP0MZyHmMGKEiBxioqmC5E/m7aqLYKhjYikR8gznNgC7G7HOOub8=
X-Received: by 2002:a9d:568:: with SMTP id 95mr4875738otw.99.1573166153689;
Thu, 07 Nov 2019 14:35:53 -0800 (PST)
MIME-Version: 1.0
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 7 Nov 2019 14:35:42 -0800
Message-ID: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [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 <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: Thu, 07 Nov 2019 22:35:55 -0000
Hello all,
A while ago it was discovered that bech32 has a mutation weakness (see
https://github.com/sipa/bech32/issues/51 for details). Specifically,
when a bech32 string ends with a "p", inserting or erasing "q"s right
before that "p" does not invalidate it. While insertion/erasure
robustness was not an explicit goal (BCH codes in general only have
guarantees about substitution errors), this is very much not by
design, and this specific issue could have been made much less
impactful with a slightly different approach. I'm sorry it wasn't
caught earlier.
This has little effect on the security of P2WPKH/P2WSH addresses, as
those are only valid (per BIP173) for specific lengths (42 and 62
characters respectively). Inserting 20 consecutive "p"s in a typo
seems highly improbable.
I'm making this post because this property may unfortunately influence
design decisions around bip-taproot, as was brought up in the review
session (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.html)
past tuesday. 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.
Thoughts?
Cheers,
--
Pieter
|
