path: root/1f/3b76c7a60236c15e6418a25b067a804f9458a3

Return-Path: <roconnor@blockstream.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1AB30C013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Mar 2020 11:11:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 12011868A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Mar 2020 11:11:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BHpqaqO80EWI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Mar 2020 11:11:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f65.google.com (mail-io1-f65.google.com
 [209.85.166.65])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id EBB378688B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 Mar 2020 11:11:24 +0000 (UTC)
Received: by mail-io1-f65.google.com with SMTP id r15so1732806iog.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 06 Mar 2020 03:11:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=XGcuBiI/Kr0AtX5z4bdnMbSqkZCz1nzaAQA1mY4sepQ=;
 b=sWqlLB18y7me4QQAJnLUmyf/oL/n880iOsjZT87azLEwyA2XO//FomPGC39DCB4RvK
 GtKp+PcZAC7pB3yk/UnngTQspRKycLzpeZHS6/WdWody3Qmy3chWt0KiaSfanB1zkskB
 NQpzbgvpsj12vj3ni6aKnXCeWt8qQ9waguGHpQmqzFmbmcSMjNZGO/pV35sZvOmnUrXS
 AHcQVYetD/Jf6yNv1gWlACHB6X21xFA0sysqkT1MsMP0QbVhJGtRD/2usq1bDM6q9cj4
 cLPUcCXMHutag9oI1CmrdrUKzIeYpsfzA7KxwPiX4kvY0NmfCa0DHwU6JIgD9xlO5QgT
 Oj2g==
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;
 bh=XGcuBiI/Kr0AtX5z4bdnMbSqkZCz1nzaAQA1mY4sepQ=;
 b=EudiNzqktquA8DYc094bzBRAGGry0ftP2Y0gpzK8Q/qc60qeqikHOXolMCE3qhUcl3
 EuxvAFvA7PCmWQVXkNjRUeBtp0OcPkYi3WGD5gh02bnbH+i+EOH6RSUtRSTTSTOS7+YT
 M1ouWaeBweZVqO4vzrStkQ9m1e7Mc35wn9h0xUzjExDKI94ec4+QPU1fk/V4zLWWxNGG
 CXSJr9g2gQDN4bfU3TvtyX30WaaD95tw3n5/62NFa3XNDsjPdGqcFUauyluWOfLo9Isq
 A+yy0llXzHoWNo1J8F/dedIpnDJXUPFFYz20dBBlGe5Ka0O6iMGeh3DaJDYFoicwmhuN
 iBPA==
X-Gm-Message-State: ANhLgQ32IOX57TvldIl0dmNN3v9OfI3gcEpY3D5whMjmAkv/6c3GDBDi
 U+DxI9+8shrOVjv4zLB0+zNxe3416o+SA8MPxWecyA==
X-Google-Smtp-Source: ADFU+vsoTJbLvS6Y17TR/zjFUV0IwORvhH52uGINzF7h4fDECXMhspxoRbqhBXd+H98Xdf3VaNNopTV+Nf4qDi8yyN0=
X-Received: by 2002:a02:9624:: with SMTP id c33mr2421207jai.117.1583493082626; 
 Fri, 06 Mar 2020 03:11:22 -0800 (PST)
MIME-Version: 1.0
References: <CAEcfjBRCA1sKcFC5M++WECsgYD-jDBYGuwxLfh0PSzRkCehEDA@mail.gmail.com>
 <CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>
In-Reply-To: <CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 6 Mar 2020 06:11:11 -0500
Message-ID: <CAMZUoKnNK-_shu4BQXK=FbtqYUn8MT=yjNDY1VFx73AAcSAzsQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b1d4f205a02db684"
Subject: Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase
	Storage
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: Fri, 06 Mar 2020 11:11:26 -0000

--000000000000b1d4f205a02db684
Content-Type: text/plain; charset="UTF-8"

On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As a replacement for paper, something like this makes sense v.s. what you
> do with a ledger presently.
>
> However, shamir's shares notoriously have the issue that the key does
> exist plaintext on a device at some point.
>
> Non-interactive multisig has the benefit of being able to sign
> transactions without having keys in the same room/place/device ever.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>

The way I see it, the main benefit of Shamir's Secret Sharing is for those
people who are already willing or wanting to be able to sign transactions
on a single device, in a single room, etc., but would prefer not to keep
their secret backup in a single room/place/device.  It is one thing to go
and gather your shares whenever you need to recover from a broken/wiped
hardware wallet versus having to go gather your shares whenever you want to
make a transaction.  (I do agree that SSS is not a suitabl for creating a
multisig from multiple participants.)

This thread inspired me tidy up and post my concept for creating secret
shares using paper computers (slide charts) and can be found at
https://github.com/roconnor-blockstream/SSS32/blob/master/SSS32.ps. It is a
design for splitting a secret encoded in the Bech32 alphabet into 2-of-n
shares (where n <= 31) using pencil, paper and lookup tables.  There are
numerous issues <https://github.com/roconnor-blockstream/SSS32/issues> and
more that need to be addressed before one could even think about using it
for actual valuable data.  Right now I'm mostly interested to find out if
paper sharing is really feasible.

A secret of 26 random Bech32 characters provides 130 bits of entropy, and a
secret of 51 random Bech32 characters provides 255 bits of entropy.
However, to enable robust recovery, the secret data ought to contain an
error correcting code.  Because each character of the secret is
independently split into shares, any single character error in one of the
shares translates into a single character error in the recovered secret
which can be corrected by the error correcting code.  See the exercise at
the end of "Verifying Bech32 Checksums with Pen and Paper" <
http://r6.ca/blog/20180106T164028Z.html> on how to attach the Bech32 error
correcting code to a raw secret string by hand.  However, protecting the
secret data is so important that one would want to design a checksum BCH
code longer than 6 characters to get strong error correcting capabilities.

I still don't know if this proposed method all a good idea or not.  I've
only experimented with encoding and recovering a 10 character "secret"
data.  Generating 2-of-n shares is quite easy as all the shares are a
function of the secret share and the first random share.  It only takes
lookup up a pair of coordinates in a table to generate one character for
each of the n shares together.  Recovering the secret data is more work;
however, if your plan is to recover a hardware wallet anyways, it is
reasonable for the hardware wallet to do the recovery from the shares
itself for you.  Generating the error correcting code by hand is a bit more
worrying, because it doesn't do you much good if your generate an incorrect
checksum.  However, by doing 1 or 2 manual passes to verify the checksum is
maybe adequate.  Also passing the secret data into the hardware wallet you
wish to use, along with its checksum, would let the hardware wallet tell
you if there was an error in the checksum.  I think creating more general
3-of-n schemes can be implemented too, but require work similar to recovery
to generate rather than the simple lookup table process.  Generating 4-of-n
and higher schemes may also be possible, but would require even more hand
computation (i.e. computing lagrange polynomials.)

Maybe this scheme is workable for the subset of people that this would
appeal to.  In anycase, my document is open source and available for those
who want to tinker with it.

--000000000000b1d4f205a02db684
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Feb 26, 2020 at 2:56 PM Jeremy via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">As a replacement for paper, something like this makes sense v.s. what =
you do with a ledger presently.</div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Howe=
ver, shamir&#39;s shares notoriously have the issue that the key does exist=
 plaintext on a device at some point.</div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">Non-interactive multisig has the benefit of being able to sign transactio=
ns without having keys in the same room/place/device ever.<br clear=3D"all"=
></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://t=
witter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div></blo=
ckquote><div><br></div><div>The way I see it, the main benefit of Shamir&#3=
9;s Secret Sharing is for those people who are already willing or wanting t=
o be able to sign transactions on a single device, in a single room, etc., =
but would prefer not to keep their secret backup in a single room/place/dev=
ice.=C2=A0 It is one thing to go and gather your shares whenever you need t=
o recover from a broken/wiped hardware wallet versus having to go gather yo=
ur shares whenever you want to make a transaction.=C2=A0 (I do agree that S=
SS is not a suitabl for creating a multisig from multiple participants.)<br=
></div><div><br></div><div>This thread inspired me tidy up and post my conc=
ept for creating secret shares using paper computers (slide charts) and can=
 be found at <a href=3D"https://github.com/roconnor-blockstream/SSS32/blob/=
master/SSS32.ps" target=3D"_blank">https://github.com/roconnor-blockstream/=
SSS32/blob/master/SSS32.ps</a>. It is a design for splitting a secret encod=
ed in the Bech32 alphabet into 2-of-n shares (where n &lt;=3D 31) using pen=
cil, paper and lookup tables.=C2=A0 There are numerous issues &lt;<a href=
=3D"https://github.com/roconnor-blockstream/SSS32/issues" target=3D"_blank"=
>https://github.com/roconnor-blockstream/SSS32/issues</a>&gt; and more that=
 need to be addressed before one could even think about using it for actual=
 valuable data.=C2=A0 Right now I&#39;m mostly interested to find out if pa=
per sharing is really feasible.</div><div><br></div><div>A secret of 26 ran=
dom Bech32 characters provides 130 bits of entropy, and a secret of 51 rand=
om Bech32 characters provides 255 bits of entropy.=C2=A0 However, to enable=
 robust recovery, the secret data ought to contain an error correcting code=
.=C2=A0 Because each character of the secret is independently split into sh=
ares, any single character error in one of the shares translates into a sin=
gle character error in the recovered secret which can be corrected by the e=
rror correcting code.=C2=A0 See the exercise at the end of &quot;Verifying =
Bech32 Checksums with Pen and Paper&quot; &lt;<a href=3D"http://r6.ca/blog/=
20180106T164028Z.html" target=3D"_blank">http://r6.ca/blog/20180106T164028Z=
.html</a>&gt; on how to attach the Bech32 error correcting code to a raw se=
cret string by hand.=C2=A0 However, protecting the secret data is so import=
ant that one would want to design a checksum BCH code longer than 6 charact=
ers to get strong error correcting capabilities.</div><div><br></div><div>I=
 still don&#39;t know if this proposed method all a good idea or not.=C2=A0=
 I&#39;ve only experimented with encoding and recovering a 10 character &qu=
ot;secret&quot; data.=C2=A0 Generating 2-of-n shares is quite easy as all t=
he shares are a function of the secret share and the first random share.=C2=
=A0 It only takes lookup up a pair of coordinates in a table to generate on=
e character for each of the n shares together.=C2=A0 Recovering the secret =
data is more work; however, if your plan is to recover a hardware wallet an=
yways, it is reasonable for the hardware wallet to do the recovery from the=
 shares itself for you.=C2=A0 Generating the error correcting code by hand =
is a bit more worrying, because it doesn&#39;t do you much good if your gen=
erate an incorrect checksum.=C2=A0 However, by doing 1 or 2 manual passes t=
o verify the checksum is maybe adequate.=C2=A0 Also passing the secret data=
 into the hardware wallet you wish to use, along with its checksum, would l=
et the hardware wallet tell you if there was an error in the checksum.=C2=
=A0 I think creating more general 3-of-n schemes can be implemented too, bu=
t require work similar to recovery to generate rather than the simple looku=
p table process.=C2=A0 Generating 4-of-n and higher schemes may also be pos=
sible, but would require even more hand computation (i.e. computing lagrang=
e polynomials.)<br></div><div><br></div><div>Maybe this scheme is workable =
for the subset of people that this would appeal to.=C2=A0 In anycase, my do=
cument is open source and available for those who want to tinker with it.<b=
r></div></div></div>

--000000000000b1d4f205a02db684--