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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 233347FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Jun 2018 21:30:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
[138.201.55.219])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3F802136
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Jun 2018 21:30:55 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
id 7927615E48EC; Sun, 3 Jun 2018 23:30:54 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
Received: from [192.168.0.8] (cable-static-238-67.teleport.ch [213.188.238.67])
by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 6975615E2C34;
Sun, 3 Jun 2018 23:30:53 +0200 (CEST)
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-Id: <E06F947E-F077-4266-A93C-9904F6528BC7@jonasschnelli.ch>
Content-Type: multipart/signed;
boundary="Apple-Mail=_92B81863-570F-4219-9C05-9CC94F6B2D45";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Sun, 3 Jun 2018 23:30:48 +0200
In-Reply-To: <CAPg+sBiL9S29MV-cxrqGMeaWADO5-C3ejmxY21V_qUGHjhDHGw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@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>
X-Mailer: Apple Mail (2.3445.6.18)
X-Virus-Scanned: clamav-milter 0.99.4 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Sun, 03 Jun 2018 21:30:56 -0000
--Apple-Mail=_92B81863-570F-4219-9C05-9CC94F6B2D45
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> I have some concerns about the use of Bech32. It is designed for
> detecting 3 errors up to length 1023 (but is then picked specifically
> to support 4 errors up to length 89). However, for error correction
> this translates to just being able to efficiently correct 1 error
> (3/2, rounded down) up to length 1023. You can of course always try
> all combinations of up to N changes to the input (for any N), testing
> the checksum, and comparing the results against the UTXO set or other
> wallet information that may have been recovered. However, the checksum
> at best gives you a small constant speedup here, not a fundamentally
> improved way for recovery.
Thanks Peter
I removed the part in the proposals that made false claims about the =
error
correction or cpu-intense key recovery.
I wrote some test code and figured out that my Core i7 machine can
do 31=E2=80=99775 operations per seconds of a addr-derivation-comparison
(bech32 decode, bip32 ckd, hash160, Base58check).
This is non-optimized code running non-parallelized.
Just in case someone wants to do more math here.
Without knowing to much about BCHs, ideally there would be a code that
includes the fact that computational costs for error correction can be =
very
high during a disaster recovery and that we can probably assume that the
user can provide a derivation element like a used address or pubkey.
Deriving one million child keys and comparing them against an address
table will take less than a minute on consumer systems.
> * correct 7 errors =3D 26 checksum characters (~ length * 1.25)
>=20
> So it really boils down to a trade-off between length of the code, and
> recovery properties.
I think 5% error correction (7 errors at 555bits) with a 26 char =
checksum is
probably an acceptable tradeoff.
Resulting string with 26 checksum chars (mockup):
=
xp1qqqqqq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv=
3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgnvv4zgnvv4zgnvv4zgngn
(140 chars)
Versus the bech32 (6 char checksum):
=
xp1qqqqqq8z4rsgv54z9a92yla4m2yrsqdlwdl7gn6qldvwkuh3zrg66z8ad2snf832tgaxcuv=
3kmwugzl5x8wtnkj2q3a03ky0kg8p7dvv4czpjqgvv4zgn
(120 chars)
Versus an xpriv:
=
xprv9wHokC2KXdTSpEepFcu53hMDUHYfAtTaLEJEMyxBPAMf78hJg17WhL5FyeDUQH5KWmGjGg=
Eb2j74gsZqgupWpPbZgP6uFmP8MYEy5BNbyET
(111 chars)
Not sure if the additional 20 characters make the UX worse.
Typing in +20 chars in a disaster recovery is probably acceptable.
> If there is interest, I can construct a code + implementation for any
> of these in a few days probably, once the requirements are clear.
Yes. Please.
Lets first wait for more feedback about the error robustness though.
Thanks
-
Jonas
--Apple-Mail=_92B81863-570F-4219-9C05-9CC94F6B2D45
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlsUXgkACgkQHrd2uwPH
ki1HYg//ShslYRDfN9mPaPnoyY7BGU3PAk+WZ9XbugiE6zn1FCAjhqyd0p1djFMz
aEKit1tC+F6ab3PjMpTbtrDw74tANRXGj90kHbxmLDodtYlcLDWgRtAfPnsmUDGj
tKXjFyrBnbNeAR+X6/eeytiHQVfANhk181E/W0w2uoUAxdRq5ZNtDDONRSFRtTYF
trrapF1lKcGiFYzqFh/GfKfqSmh6f1fRxPCLMnKeYQ9ciJHYBT1hdl9GKjWj65fy
EjdKx8DFaB0gfUPHF4dh0JTWx90+w3StQmAqm5fnnpL9RqJdE9tbynkqWpzSfJCz
7uEzbyW06fHd/hN/3UJrBAYRv2rX0yyCiVUpsvJhevxnXBWZDtQ7pnDGDzlwQbBH
lAZ0V2uPm/54sUIs+V0ingF0n2iM5bgGzj/C/wWjGF5DW3X77rz0tENg/Wg5Z6Gl
pguTDRZKBfSvOvCQMPbwdFaZbNgmAJlWVNHwrLCWGSUOEkyekHlWSlW23wo4ftRL
r1EgoCva3x2N9GOrbBxyECuMQd2pNAA6n35pnrPTe+uB5rw6nhvWyxwiYPgi+Mkj
DP7K9tv3H8qR5GfRHfDmgLFxByqryjLcBaNsOIGo8w0MHhYF9V3YgLgYj5Vd77j4
lSJqYblOT9Vyw5xw71TlMs+XpcD5r2IT3t0iGn87B9U1XGc0bl4=
=a0mn
-----END PGP SIGNATURE-----
--Apple-Mail=_92B81863-570F-4219-9C05-9CC94F6B2D45--
|
