MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] New serialization/encoding format for key material
Precedence: list

--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&#39;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--