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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id DA803C0881
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Dec 2019 06:36:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id D1DAA85F83
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Dec 2019 06:36:33 +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 wHWBSSckk-L4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Dec 2019 06:36:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com
[209.85.210.49])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 3E31885DD1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Dec 2019 06:36:33 +0000 (UTC)
Received: by mail-ot1-f49.google.com with SMTP id 66so14570301otd.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 09 Dec 2019 22:36:33 -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; bh=6A46RfuzPPRJdZwq8UOGRZ6JN8lcARAKg+ZtT/07ATs=;
b=QQD8GY6CcbDlAJjmRLvJRebUs5MiDpXum4lk2GmXPiPVk3mYL0PEBZgmSHASLSjHNd
PIvIgOnwnqEyNQr1KSQYpij7O8TrIdshfDQ6EQEWyqHmaTpn0nvfnfZdXsnrc3T3yTMq
jcNsWLR60dwZ750NrKO/WzsOks3GkcyHQzAtQZFDAh0FWTHdCrVDqTpAiH4vZ7OeVjRH
nvX94YE0ouR5XzM6IJpLLtZhPrFzSqqjIwbhyS5xDUE8YZHIzBNaReOnVMmfWqo1FRH1
Rn1I5goWe7qcmJdJjzpvnChmLia/ROAkYri154q5AnY7EZxiCcD9ghkZOaopqeSui55L
uoNA==
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;
bh=6A46RfuzPPRJdZwq8UOGRZ6JN8lcARAKg+ZtT/07ATs=;
b=lbT2znibVGDhyJv1IfP/Br4xnU3u1PR6uzsGFuLTAfdYIRmszZEk0XMrEcAG+PbZm9
TJFdviW8y0GBP5c+2eusng5U2b3U0D1JiPkwNmOpF0yp4PjYEx61L/dLhtrJHfj6rB1t
9FfLnmL1rjyhg5PxXi/qv7y90CWdrsRKKOYmQVLH/L2IC3hYGcmY4nmdjuFi6PKbpsVD
NZCGktNXOwk+bn7JCSXjJc0lB/1WqKQdZ4Ne9H33ZKpHBX2LDhj0UALAZ0z0hWoxf/RD
2V50KEJZcqoiHY0QwsrHxf2xrjnLCE/V9lmIcO4/bK/8dFQh2FPlVH8JiQsAs9Bhcxas
tQKQ==
X-Gm-Message-State: APjAAAXoa+JJJGsVwXWURakS1VCuORyTRluUjYISYYp8+pTzT9Mo379q
5dwvuX1WFI35syMejx0aW4DgP9/X9VTXUuY9zr4=
X-Google-Smtp-Source: APXvYqzPdLxcYIwu8MKVoqwC4ai5kYEUsvI8Sv/ny3hK5EL8FnBEcUrga8cZV7z8QDu+6Y/7HKSKX+OAJrFrBy1nZGM=
X-Received: by 2002:a05:6830:2154:: with SMTP id
r20mr7938939otd.66.1575959792156;
Mon, 09 Dec 2019 22:36:32 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBgdspmfK1qpG=9N9fAtVNkMDd+xym7yHdjq=zYnqeh5dA@mail.gmail.com>
<2YyEOYXhcEvfGJLUX4zswzSpBA0vWOC_Jwl_MOcphySLZqjfBDqqDkBvZB6kX7nvVsGNPqwuh63lgBGO5BcURaig2r5tqxFoaEZTLDMTG7U=@protonmail.com>
In-Reply-To: <2YyEOYXhcEvfGJLUX4zswzSpBA0vWOC_Jwl_MOcphySLZqjfBDqqDkBvZB6kX7nvVsGNPqwuh63lgBGO5BcURaig2r5tqxFoaEZTLDMTG7U=@protonmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Mon, 9 Dec 2019 22:36:20 -0800
Message-ID: <CAPg+sBhXrJYYLFKRZJmKe+21p9zn7ah54e36A_EpXLWO8Q+XeA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Analysis of Bech32 swap/insert/delete detection
and next steps
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: Tue, 10 Dec 2019 06:36:34 -0000
> > So my suggestion for the next steps are:
> >
> > - Update BIP173 to include the insertion weakness as an erratum, and
> > the results of this analysis.
> >
>
> To clarify, this step does not modify anything about the implementation of BIP173, only adds this as an additional erratum section?
Correct - just documenting the issue.
> > - Amend segwit addresses (either by amending BIP173, or by writing a
> > short updated BIP to modify it) to be restricted to only length 20 or
> > 32 (as fixed-length strings are unaffected by the insertion issue, and
> > I don't think inserting 20 characters is an interesting error class).
>
> To clarify, this refers to all SegWit address versions from 1 to 15, as this restriction exists for SegWit address v0?
Right, for v0 there is an inherent restriction to size 20 or 32
already, so this would only semantically change anything for version 1
through 16 (not 15).
> > - Define a variant of Bech32 with the modified constant, so that
> > non-BIP173 uses of Bech32 can choose a non-impacted version if they
> > worry about this class of errors.
> >
>
> Okay, this probably needs to be raised in lightning-dev as well, for invoice formats, as well as planned offers feature.
It seems BOLT11 already doesn't care very much about the error
detection properties, as it's using Bech32 outside its design
parameters (max length 90 characters).
> By my understanding, best practice for readers of Bech32-based formats would be something like the below:
>
> 1. Define two variants of checksum, the current Bech32 checksum and the modified Bech32 checksum.
> 2. Support both variants (software tries one first, then tries the other if it fails).
> 3. Flag or signal some deprecation warning if current Bech32 checksum was detected.
> 4. At some undefined point in the future, drop support for the current Bech32 checksum.
I think it depends on the application and their tolerance to this sort
of errors. In some cases, these insertions may be detected already
with high probability (e.g. because of length restrictions, or the
fact that it adds random unstructured symbols at the end of the data
part).
> > - Later, if and when we expect a need for non-32-byte witness programs
> > in the medium term, define an updated segwit address scheme that uses
> > the modified Bech32 variant.
>
> Okay, so we will only use the modified Bech32 if and only if we expect to need a non-32-byte witness program for a particular non-0 SegWit version.
Exactly.
--
Pieter
|
