summaryrefslogtreecommitdiff
path: root/3d/90db9685626b1f34e6f98134857d34991a9d17
blob: 887d19a17507702cb11c9dc08e74cb60633ecd0c (plain)
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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
Return-Path: <aritter@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id ADF6D3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 09:35:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5AF8157
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 09:35:06 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id w134so1658384qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 02:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=jn1oizFJk33DnOkyT32C7NN5/adRgjYmHpSuFfhqCBc=;
	b=M4K1kcW+yqkEinbisyqCHUQrB5ur0JyWpI/oHU9HAu8zgS7IOWNq8TBxXxCEwNF14e
	QK8x5NzMzr5aqAJrtHvP/j6siiEE9TY4FriSR6cQHvkruIWbXfyiMhMmKHIF6XW5HuJ5
	s4xaGxN9Zev834wBdGOOUK50KE4ho9f9S6xwYtF3/lS5t2ocgRlpAcqy/F4wr9PPcDeQ
	FZ1MRXD93dlvvTGa/4hsnbi2ICbSQJ5fx9A4QWw6EPQNg++UqZlrCfyzkaEfIlcDMYzW
	K9dRRD20ZZXu2e823AvKeMkb24Bd8GNl220ydz0HFnsWbJpZ3hbm8RF0kFmXzAz7BgZg
	d3GQ==
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;
	bh=jn1oizFJk33DnOkyT32C7NN5/adRgjYmHpSuFfhqCBc=;
	b=B8q0xsB9LEsorfrzOl2Pg0Ceb6UAgk1vKXkQwhk5YT7yOkJLwVkyE/lq7CvAfhBn0s
	M+Atuwuitw1+XVOhDE2AktsQdHNxNr/diQfDZItnNvOE0X6hrmxmwk+vlA5VT301Wtqs
	hikIXAp3EgMao37Y8GKNP3+lNm/TySIw1O33lLsqQCTPg/JMmWrI7dwEA7Et85VnNTe4
	89BDdmMfuWN0FUxBx+OCbkgUtkdyjWNK0hrZG8WIoqguyzZ9K77Ty92ouDoKG7epHoRJ
	pENZQx1ERq0ZsvcOe5/aXHHrUPE83vL5NTTRVjWWs/yuHkZ7s/RC0tq+j/vljn/hNe7O
	ptgw==
X-Gm-Message-State: AMCzsaUYSZWRY0H06n1H56nei0uuDMv8NGb+nGdS29glV2bKTyM31kS2
	Q1KPDWPtgGz4q2i60CwFkTTVe5UJ18aWrQCZYJA=
X-Google-Smtp-Source: AOwi7QCtm83CNpZWn7qqr8jUoiFHWYEE/MySz3J2hKeds0yEMP46sy76GgXaxrcsiGNnvrj4cN9kkqXCrgXbEYHOuY8=
X-Received: by 10.55.21.30 with SMTP id f30mr7305407qkh.335.1506764105803;
	Sat, 30 Sep 2017 02:35:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.161.69 with HTTP; Sat, 30 Sep 2017 02:35:05 -0700 (PDT)
In-Reply-To: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch>
References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
	<96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch>
From: Adam Ritter <aritter@gmail.com>
Date: Sat, 30 Sep 2017 11:35:05 +0200
Message-ID: <CAKuKjyWN-K9xSuwebtTxEG7Em6jSLsKdE8VY2n72FBdpeycZxA@mail.gmail.com>
To: Dan Libby <dan@osc.co.cr>, Jonas Schnelli <dev@jonasschnelli.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1147da4e496c65055a64dbf0"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 30 Sep 2017 10:40:49 +0000
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
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: Sat, 30 Sep 2017 09:35:07 -0000

--001a1147da4e496c65055a64dbf0
Content-Type: text/plain; charset="UTF-8"

I'm happy to help with secure paper wallet support. Bitcoin core is already
used offline by the Glacier Protocol, though there's no official offline
support.

I extended the Glacier Protocol with an extra password derivation function.
I used Scrypt with 2GB RAM requirement, though maybe using Argon2id V1.3
would be better.

Also I'd prefer using BIP45 Multisig HD Wallets over a multisig address, as
in the current Glacier Protocol implementation the redeem key is public
because of the test withdrawal transaction.

On Sat, Sep 30, 2017 at 6:49 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > Hi,
> >
> > I'm writing to suggest and discuss the addition of paper wallet
> > functionality in bitcoin-core software, starting with a single new RPC
> > call: genExternalAddress [type].
> >
>
> AFAIK, client implementations such as your proposal are off-topic for this
> ML.
> Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for
> such proposals.
>
>
> > On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> > Paper wallets are a safety hazard, insecure, and generally not advisable.
> >
>
> I have to agree with Luke.
> And I would also extend those concerns to BIP39 plaintext paper backups.
>
> IMO, private keys should be generated and used (signing) on a trusted,
> minimal and offline hardware/os. They should never leave the device over
> the channel used for the signing I/O. Users should have no way to view or
> export the private keys (expect for the seed backup). Backups should be
> encrypted (whoever finds the paper backup should need a second factor to
> decrypt) and the restore process should be footgun-safe (especially the
> lost-passphrase deadlock).
>
>
> /jonas
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">I&#39;m happy to help with secure paper wallet support. Bi=
tcoin core is already used offline by the Glacier Protocol, though there&#3=
9;s no official offline support.<div><br><div>I extended the Glacier Protoc=
ol with an extra password derivation function. I used Scrypt with 2GB RAM r=
equirement, though maybe using Argon2id V1.3 would be better.</div></div><d=
iv><br></div><div>Also I&#39;d prefer using BIP45 Multisig HD Wallets over =
a multisig address, as in the current Glacier Protocol implementation the r=
edeem key is public because of the test withdrawal transaction.</div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Sep 30, 2017 at=
 6:49 AM, Jonas Schnelli via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span><br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m writing to suggest and discuss the addition of paper wallet<br=
>
&gt; functionality in bitcoin-core software, starting with a single new RPC=
<br>
&gt; call: genExternalAddress [type].<br>
&gt;<br>
<br>
</span>AFAIK, client implementations such as your proposal are off-topic fo=
r this ML.<br>
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for suc=
h proposals.<br>
<span><br>
<br>
&gt; On 09/29/2017 02:03 PM, Luke Dashjr wrote:<br>
&gt; Paper wallets are a safety hazard, insecure, and generally not advisab=
le.<br>
&gt;<br>
<br>
</span>I have to agree with Luke.<br>
And I would also extend those concerns to BIP39 plaintext paper backups.<br=
>
<br>
IMO, private keys should be generated and used (signing) on a trusted, mini=
mal and offline hardware/os. They should never leave the device over the ch=
annel used for the signing I/O. Users should have no way to view or export =
the private keys (expect for the seed backup). Backups should be encrypted =
(whoever finds the paper backup should need a second factor to decrypt) and=
 the restore process should be footgun-safe (especially the lost-passphrase=
 deadlock).<br>
<br>
<br>
/jonas<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div><br></div></div>

--001a1147da4e496c65055a64dbf0--