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
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CA60CF18
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 15:54:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 63CA267F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 15:54:51 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id e15-v6so11153876iog.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Jun 2018 08:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=SfLAhlxJ69V8KGMu9rRYUXHF8jHjvL0nahEXkWz7wZ8=;
b=Zoj3jf1RjRMyD2tWeQRhsYcc2Xj5rCiT9vbMt2yh+K+mWuDynDpoIMwuTVwgvUvDv6
IQcEAQQ4Wy11i96hutMef/DepLKQZT/KEzSyuKnZGSX5SoONnFKTiboC7LERvktYGbkN
OZeHl+iYm79SoNlbWTSjjlrt7oLqqJYHQtit8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=SfLAhlxJ69V8KGMu9rRYUXHF8jHjvL0nahEXkWz7wZ8=;
b=UP89hRamt16PYNKofTiFcT8mZoAIJ3UjWON9jwdVoVUBArltJR3H2GUgW7y3JDgywI
qfw5e4GddE8WwJFvT7ztT1Bn6Gw5WV6Z9eWPhNPpN9Nb7s17/JiwYqCayARqy41yzUre
KagT26V2OVdP4soNMBYk5T89PRZc5r7ZauwSRpMqyPqW8i5LSslR9v1yaPAk2PlDvTeQ
PXmVuSNJI9I3vyqiKYri/pPSGUkyP/nYC5avKwVcCM9qneNng72yorOusiX3NCqxd7BR
ZIQU/6CBSIiup7Hz2VQaILFABQA1h75H2Rck3c2DDbHfc4pGFbP/nhdQyXL6P1HobVLy
pPiw==
X-Gm-Message-State: APt69E2ckxZAQG1VPDm6VNiKUlxRL/mD7O1Bk2cF3qiNmGlrkJr4T8xt
ybdZKv+NNPaiXAWI6xInDWL+bZC5BPKbffHnI506wA==
X-Google-Smtp-Source: ADUXVKLKb+It1D7Zciezi603ws7ejpTYcAGljLpq5kOKs7/uZ8S0xpreeBd+ls9sagUXfQdvroZGoeCzQJPB+Lg7oeE=
X-Received: by 2002:a6b:9ec7:: with SMTP id
h190-v6mr1950811ioe.185.1529078090668;
Fri, 15 Jun 2018 08:54:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:1253:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 08:54:30
-0700 (PDT)
In-Reply-To: <CAPg+sBiL9S29MV-cxrqGMeaWADO5-C3ejmxY21V_qUGHjhDHGw@mail.gmail.com>
References: <CABuOfuhMGFGc1tyjcOmnUk1OrWp2d6ppKc8phLT9pXCj8vs+qg@mail.gmail.com>
<FE65454B-B30A-4CEF-B568-B2746BD2BC0B@jonasschnelli.ch>
<E449A58B-08C4-4A1C-8109-38C800B718AF@jonasschnelli.ch>
<CAPg+sBiL9S29MV-cxrqGMeaWADO5-C3ejmxY21V_qUGHjhDHGw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Fri, 15 Jun 2018 11:54:30 -0400
Message-ID: <CAMZUoKkXhyGcHs3z-qq-eVwnTg3oqZf3dO25BtBY=PvTnOoucg@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006de1d0056eb03cfd"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] New serialization/encoding format for key material
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: Fri, 15 Jun 2018 15:54:51 -0000
--0000000000006de1d0056eb03cfd
Content-Type: text/plain; charset="UTF-8"
> For codes designed for length 341 (the first length enough to support
> 512 bits of data):
> * correct 1 error = 3 checksum characters
> * correct 2 errors = 7 checksum characters
> * correct 3 errors = 11 checksum characters
> * correct 4 errors = 15 checksum characters
> * correct 5 errors = 19 checksum characters
> * ...
> * correct 7 errors = 26 checksum characters (~ length * 1.25)
> * correct 13 errors = 51 checksum characters (~ length * 1.5)
> * correct 28 errors = 102 checksum characters (~ length * 2)
>
> So it really boils down to a trade-off between length of the code, and
> recovery properties.
>
At the risk of making the proposal more complex, I wonder if it might be
better to support multiple checksum variants? The trade-off between code
length and recovery seems to be largely determined by the user's medium of
storage, which is likely to vary from person to person. I personally would
probably be interested in the 51 or even 102 character checksums variants.
--0000000000006de1d0056eb03cfd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
For codes designed for length 341 (the first length enough to support<br>
512 bits of data):<br>
* correct 1 error =3D 3 checksum characters<br>
* correct 2 errors =3D 7 checksum characters<br>
* correct 3 errors =3D 11 checksum characters<br>
* correct 4 errors =3D 15 checksum characters<br>
* correct 5 errors =3D 19 checksum characters<br>
* ...<br>
* correct 7 errors =3D 26 checksum characters (~ length * 1.25)<br>
* correct 13 errors =3D 51 checksum characters (~ length * 1.5)<br>
* correct 28 errors =3D 102 checksum characters (~ length * 2)<br>
<br>
So it really boils down to a trade-off between length of the code, and<br>
recovery properties.<br></blockquote><div><br></div><div>At the risk of mak=
ing the proposal more complex, I wonder if it might be better to support mu=
ltiple checksum variants?=C2=A0 The trade-off between code length and recov=
ery seems to be largely determined by the user's medium of storage, whi=
ch is likely to vary from person to person.=C2=A0 I personally would probab=
ly be interested in the 51 or even 102 character checksums variants.<br></d=
iv></div></div></div>
--0000000000006de1d0056eb03cfd--
|
