From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CA60CF18 for ; 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 ; Fri, 15 Jun 2018 15:54:51 +0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id e15-v6so11153876iog.1 for ; 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: References: From: "Russell O'Connor" Date: Fri, 15 Jun 2018 11:54:30 -0400 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

=
For codes designed for length 341 (the first length enough to support
512 bits of data):
* correct 1 error =3D 3 checksum characters
* correct 2 errors =3D 7 checksum characters
* correct 3 errors =3D 11 checksum characters
* correct 4 errors =3D 15 checksum characters
* correct 5 errors =3D 19 checksum characters
* ...
* correct 7 errors =3D 26 checksum characters (~ length * 1.25)
* correct 13 errors =3D 51 checksum characters (~ length * 1.5)
* correct 28 errors =3D 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 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.
--0000000000006de1d0056eb03cfd--