summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRussell O'Connor <roconnor@blockstream.io>2018-06-15 11:54:30 -0400
committerbitcoindev <bitcoindev@gnusha.org>2018-06-15 15:54:51 +0000
commitee79237fb8d43ccc454d06b798dd3b1388ef12b7 (patch)
tree29f6104eac78001d929b60e13e2a9bc776b80f97
parent41926b8a88a6712eba8d6bd00cdea8b0ae7a2e4e (diff)
downloadpi-bitcoindev-ee79237fb8d43ccc454d06b798dd3b1388ef12b7.tar.gz
pi-bitcoindev-ee79237fb8d43ccc454d06b798dd3b1388ef12b7.zip
Re: [bitcoin-dev] New serialization/encoding format for key material
Diffstat
-rw-r--r--fb/e733622f537468e3ed4a9b0ab0bbf9b7391e4f127
1 files changed, 127 insertions, 0 deletions
diff --git a/fb/e733622f537468e3ed4a9b0ab0bbf9b7391e4f b/fb/e733622f537468e3ed4a9b0ab0bbf9b7391e4f
new file mode 100644
index 000000000..4ad4904b1
--- /dev/null
+++ b/fb/e733622f537468e3ed4a9b0ab0bbf9b7391e4f
@@ -0,0 +1,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&#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--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-16 03:14:06 +0000