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
|
Return-Path: <rgrant@rgrant.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A1DC6C013B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2020 18:11:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 8B489873EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2020 18:11:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id WWRXMpyX5pPy
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2020 18:11:23 +0000 (UTC)
X-Greylist: delayed 00:23:51 by SQLgrey-1.7.6
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com
[209.85.218.49])
by whitealder.osuosl.org (Postfix) with ESMTPS id 2F205873D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2020 18:11:23 +0000 (UTC)
Received: by mail-ej1-f49.google.com with SMTP id ga15so25938651ejb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2020 10:11:23 -0800 (PST)
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=/mLIvsF+2rOsoMwqziOH2BYgtSEbLwg/+bqE4aYYLUY=;
b=VX3JxPasxIDKDRu1bCsv0kKphqD6wsiQMeaEctdMUfmdsUGX7KtDseiMOViHi2xqsy
Qx8bUUVE7API2A8djJPe5g9jbYyP4XBamuRRJTZTardSUfy4pJqXM8c3I7TNi1EK65u4
OGAJhRaorV4TUT7d6fUTO5KxH0ZdAPjXSw8ru0iTKlF/thqkIx7KnJwMQ0rierqMQYtt
1/mJ8SC5MyOVdYuSLSPRJT2v8dTNlC/m/B3V7UDolg+9lRuoIGFiSr+s4G0A1XgspdiE
3Qm++4VUz15gNj7Hdnzyg9nr0BcUdxEHadtVGyHyDMVoI9air7+gtfYsHwAJrrgW2C3a
k1LQ==
X-Gm-Message-State: AOAM531wRWwTXghWJrEr8J7KHzOUaLO6bTuEJfBcTPaM7oGuf96ePNB6
2eN837A6SntTnQyfIrVPFqzPJccJfvlLsRAHXb2O+7A3LiaUP/dc
X-Google-Smtp-Source: ABdhPJwAyPx41YdYzy2a/bGi1gk6fsV5ojL/W6NQk3P3Lf86Q8Rzn+GKEBwVoa+ZiMF4hoYCKVT/Jic4ZM09gIPpbpY=
X-Received: by 2002:adf:e60e:: with SMTP id p14mr25605128wrm.188.1607449189584;
Tue, 08 Dec 2020 09:39:49 -0800 (PST)
MIME-Version: 1.0
References: <87imblmutl.fsf@rustcorp.com.au>
<sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
<877drn2g6q.fsf@rustcorp.com.au>
<S6FCoLsmwaQUhrtSURemcTcG8tUWTXYkBf-0Q0hxCpObfJQ0TXNcmJrQhoqy7ttWwtGnvyS-bJ5RSXJoPizAgjuMognzVnu3SM3wMujKy88=@wuille.net>
<878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede>
<Kw_jwhASjriebJpsuUyi0u9EQmIVR1pQ3Jocqd9VeVDlmoH9s36bFAwr3PXu_pJd-Xly-hKun_yenLwbJvVIYWmlAiF5lMxuquLO2pTmlLo=@wuille.net>
<CAMeZzJeG00q9DPQacidto5H16Ryb6ou6tnMDK1jnAuncnVXnsA@mail.gmail.com>
<CAMeZzJdQuS1-0qPvY+0-yqRfVXgZV_2hmHB5hZwykm5WxjUkgg@mail.gmail.com>
<5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net>
<20201206130453.tiu36iigva2jj5qn@ganymede>
In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Tue, 8 Dec 2020 17:39:23 +0000
Message-ID: <CAMnpzfqy-=65gZ_Nj1EjhLV3ExZhnJQ=9o+nAqf11VjxXP3L+Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
(BIP-173)
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, 08 Dec 2020 18:11:24 -0000
It looks like a good strategy for a bech32 library that is external to
Bitcoin Core would be:
- Default to the new M, under the same bech32 brand.
- Provide an interface to explicitly use both M=1 and M=0x2bc830a3.
- If decoding fails, throw an error; but in constructing that error
inform whether the other M would have succeeded.
- Provide an interface for a BIP173 implementation to peek at the
witness version byte of the data part, which may also involve
sanity-checking that byte for errors using a BIP173-specific
understanding of the appropriate checksum.
Return values for this special interface might currently be:
"it's version zero, based on a clean decoding",
"it's version one, based on a clean decoding",
"it's version zero, based on an auto-corrected byte",
"it's version one, based on an auto-corrected byte",
"no result, due to a decoding error on this byte", and
"too many errors to say anything more about decoding".
Although the reasoning is clear for doing so, looking into the data
that is supposed to be checksummed to determine which checksum to use
is not very elegant. There are two trips into a bech32 library for a
BIP173 decoding, and an indeterminate result on the version byte would
require heuristics for deciding what to do with the rest of the data
part to even advise the user on the error. Because of this, as a
library writer I would be tempted to auto-correct the witness version
byte (against the "SHOULD NOT" advice of BIP173's current version), if
it were the only one corrupted, as per the example return values
above. Please advise.
Some of the libraries that will be contemplating these steps include:
https://github.com/topics/bech32?o=desc&s=stars
Here are three existing uses of bech32 that are external to Bitcoin Core:
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
https://github.com/btcontract/lnurl-rfc
https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki
Of the above, I think BIP136 can be unconditionally moved to
M=0x2bc830a3 due to having little legacy burden.
|
