path: root/c9/e8ca2410c582f74e2875435c8a0596c8a3c158

Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 72E83A95
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 20:21:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
	[66.111.4.25])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B7464F1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 20:21:52 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id DB18F21321
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 16:21:51 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
	by compute1.internal (MEProxy); Fri, 29 Sep 2017 16:21:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
	content-type:date:from:in-reply-to:message-id:mime-version
	:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc
	:x-sasl-enc; s=fm1; bh=1lIBxjRD7+V5ynnXs2PRiBE9eLYXaQmfJOFWkTupo
	4U=; b=giCPFV4c7zc18ft7PLS9Cbe0u6QzIh3s8Cj4S1LhVXBMOpAlj5VVy35y0
	1fsZmwij1dvr/7ssjJi3NNrFFvZvgxz13aEBzNp12Y0wMp6WSvV0pjbCQ4UN11CW
	rmGyE6L0Mllr3L4aIbsQ8mwiEOCDYuLrQ9fE6vLTb7mRJeR/Fc/k9QN2J7fN9jCf
	bQIDJ8t2SId4wWahMrHFFsxEBY8YBJtYKQpGwvmkKP3Y4+Q7RP9UxBEl5uTxGjBw
	ep0F0r3EnZHjX4/AL4VCYKlsJRba+BWXFH6PEwy2dSkOdijoBciuK8/Hfle/QAyW
	fxT7JxkRaAIR2dLjpCSrLOhYxu+7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=1lIBxjRD7+V5ynnXs2
	PRiBE9eLYXaQmfJOFWkTupo4U=; b=GaDvEc0f9gyk1tj3v0XOkmP5ae1lkm/Cal
	QGgdnNSYMgq5MFeIP0/1xTM+rIJdq3sZFXNqHlm+w7JgVJisoznvNQkaFVxsAuia
	+oPx75jWgZfwMj2XDOEkeFabkCrqwkXTO6hCMleqs+nVqTf6d76w/FRYhd6Xt2IV
	TY0hk9TwdFu6VhqbyzmOUtMOTjg6Hj+e5MuDezJ0HH3bgkQYHidZi3TwStHtAULv
	3/Z14uj2XDkptqxostleFHOCiOylCv+w+Vp1JKwqckpO5j9MiCc8bw+XrnIQL35u
	VUZlN1dqsmuQajjSVjZyizkf5R7TNh/1SHO2lFFofSWOQHOqFWwQ==
X-ME-Sender: <xms:X6vOWQjohdFk6qQRyv5plsxgQt2nx4dvpJq32vK-ViezaBsrjHybkA>
X-Sasl-enc: ase5EeKf6Q8nw97qwBXVvYuXEKVvSm3QWNY9UICLuAxa 1506716511
Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl
	[84.105.61.15])
	by mail.messagingengine.com (Postfix) with ESMTPA id EC7977E12B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 16:21:50 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_CD33B5AD-EFE6-48BD-90CD-56A4E2085019";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
Date: Fri, 29 Sep 2017 22:21:48 +0200
References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
	<CAAy62_Jfp00gsAjTWvr1E8aYx9z9aYM9y6AqqrgK8HizQm08xQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAAy62_Jfp00gsAjTWvr1E8aYx9z9aYM9y6AqqrgK8HizQm08xQ@mail.gmail.com>
Message-Id: <1FF598B0-52BD-4DE6-8DD3-7A31025CF313@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW 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: Fri, 29 Sep 2017 22:23:48 +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: Fri, 29 Sep 2017 20:21:54 -0000


--Apple-Mail=_CD33B5AD-EFE6-48BD-90CD-56A4E2085019
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7F879A41-4709-4C3B-8F62-AA099BA9FBBE"


--Apple-Mail=_7F879A41-4709-4C3B-8F62-AA099BA9FBBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of =
not needing to trust a printer.

However without also supporting BIP43/44/49 this would probably cause =
confusion. Supporting these would be a larger project as well. Although =
widely used, the standards are still Proposed / Draft. There's  might be =
room for improvement [0].

Sjors

[0] https://github.com/satoshilabs/slips/issues/103

> Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> One consideration of exposing this in QT is that it may encourage =
users to generate paper wallets(which are generally used and recommended =
for cold storage) from online machines, rendering them moreso lukewarm =
rather than cold, since the keys weren't generated in an air-gapped =
environment.  When using bitaddress.org <http://bitaddress.org/> =
locally(we are all only using it locally and not directly from the =
online webpage, right? ;) ) you've at least made the effort to seek out =
the repo, clone it locally, and use it on an offline machine and not =
retain any data from that session.
>=20
> If we include this as a function in the reference implementation, how =
many people are going to be making paper wallets with the intention of =
cold storage on a machine that's potentially compromised?  As =
adoption(hopefully) continues to increase the number of less than tech =
savvy people using bitcoin will increase.
>=20
> I'd suggest that any UI in QT include some sort of a modal dialog that =
informs the user that this is not a secure cold storage address unless =
it was created on an offline machine and printed on a non-networked =
printer, and the prompt must be accepted and dismissed before the wallet =
will provide the requested keys.
>=20
>=20
> On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Hi,
>=20
> 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].
>=20
> -- rationale --
>=20
> bitcoin-core is the most trusted and most secure bitcoin =
implementation.
>=20
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> bitaddress.org <http://bitaddress.org/>.  This requires placing trust =
in an additional body of
> code from a less-trusted and less peer-reviewed source.  Ideally, one
> would personally audit this code for one's self, but in practice that
> rarely happens.
>=20
> In the case of a website generator, the code must be audited again =
each
> time it is downloaded.  I cannot in good faith recommend to anyone to
> use such third party tools for wallet generation.
>=20
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>=20
> At least for me, this requirement to audit (or implicitly trust) a
> secondary body of bitcoin code places an additional hurdle or
> disincentive on the use of paper wallets, or indeed private keys
> generated outside of bitcoin-core for any purpose.
>=20
> Unfortunately, one cannot simply use getnewaddress, getaccountaddress,
> or getrawchangeaddress for this purpose, because the associated =
private
> keys are added to the bitcoin-core wallet and cannot be removed... or =
in
> the case of hd-wallets are deterministically derived.
>=20
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
>=20
>=20
> -----
>=20
>     genexternaladdress ( "type" )
>=20
>     Returns a new Bitcoin address and private key for receiving
>     payments. This key/address is intended for external usage such as
>     paper wallets and will not be used by internal wallet nor written =
to
>     disk.
>=20
>     Arguments:
>     1. "type"        (string, optional) one of: p2pkh, p2sh-p2wpkh
>                                         default: p2sh-p2wpkh
>=20
>     Result:
>     {
>         "privKey"    (string) The private key in wif format.
>         "address"    (string) The address in p2pkh or p2sh-p2wpkh
>                               format.
>     }
>=20
>=20
>     Examples:
>     > bitcoin-cli genexternaladdress
>=20
>=20
> ----
>=20
> This API is simple to implement and use.  It provides enough
> functionality for any moderately skilled developer to create their own
> paper wallet creation script using any scripting language, or even for
> advanced users to perform using bitcoin-cli or debug console.
>=20
> If consensus here is in favor of including such an API, I will be =
happy
> to take a crack at implementing it and submitting a pull request.
>=20
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
>=20
> Also, I welcome suggestions for a better name, or maybe there could be
> some improvements to the param(s), such as calling p2sh-p2wpkh =
"segwit"
> instead.
>=20
>=20
> ---- further work ----
>=20
>=20
> Further steps could be taken in this direction, but are not necessary
> for a useful first-step.  In particular:
>=20
> 1. an RPC call to generate an external HD wallet seed.
> 2. an RPC call to generate N key/address pairs from a given seed.
> 3. GUI functionality in bitcoin-qt to facilitate easy paper wallet
> generation (and printing?) for end-users, complete with nice graphics,
> qr codes, etc.


--Apple-Mail=_7F879A41-4709-4C3B-8F62-AA099BA9FBBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">A =
12-24 word BIP39 mnemonic is easy to write down and has the benefit of =
not needing to trust a printer.<div class=3D""><br class=3D""></div><div =
class=3D"">However without also supporting BIP43/44/49 this would =
probably cause confusion. Supporting these would be a larger project as =
well. Although widely used, the standards are still Proposed / Draft. =
There's &nbsp;might be room for improvement [0].&nbsp;<div class=3D""><br =
class=3D""></div><div class=3D"">Sjors</div><div class=3D""><br =
class=3D""></div><div class=3D"">[0]&nbsp;<a =
href=3D"https://github.com/satoshilabs/slips/issues/103" =
class=3D"">https://github.com/satoshilabs/slips/issues/103</a><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; het volgende =
geschreven:</div><br class=3D"Apple-interchange-newline"><div =
class=3D""><div dir=3D"ltr" class=3D"">One consideration of exposing =
this in QT is that it may encourage users to generate paper =
wallets(which are generally used and recommended for cold storage) from =
online machines, rendering them moreso lukewarm rather than cold, since =
the keys weren't generated in an air-gapped environment.&nbsp; When =
using <a href=3D"http://bitaddress.org/" class=3D"">bitaddress.org</a> =
locally(we&nbsp;<i class=3D"">are </i>all only&nbsp;using it locally and =
not directly from the online webpage, right? ;) )&nbsp;you've at least =
made the effort to seek out the repo, clone it locally, and use it on an =
offline machine and not retain any data from that session.<div =
class=3D""><br class=3D""></div><div class=3D"">If we include this as a =
function in the reference implementation, how many people are going to =
be making paper wallets with the intention of cold storage on a machine =
that's potentially compromised?&nbsp; As adoption(hopefully) continues =
to increase the number of less than tech savvy people using bitcoin will =
increase.</div><div class=3D""><br class=3D""></div><div class=3D"">I'd =
suggest that any UI in QT include some sort of a modal dialog that =
informs the user that this is not a secure cold storage address unless =
it was created on an offline machine and printed on a non-networked =
printer, and the prompt must be accepted and dismissed before the wallet =
will provide the requested keys.</div><div class=3D""><br =
class=3D""></div></div><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via =
bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class=3D"">
<br class=3D"">
I'm writing to suggest and discuss the addition of paper wallet<br =
class=3D"">
functionality in bitcoin-core software, starting with a single new =
RPC<br class=3D"">
call: genExternalAddress [type].<br class=3D"">
<br class=3D"">
-- rationale --<br class=3D"">
<br class=3D"">
bitcoin-core is the most trusted and most secure bitcoin =
implementation.<br class=3D"">
<br class=3D"">
Yet today (unless I've missed something) paper wallet generation<br =
class=3D"">
requires use of third party software, or even a website such as<br =
class=3D"">
<a href=3D"http://bitaddress.org/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">bitaddress.org</a>.&nbsp; This requires placing trust in an =
additional body of<br class=3D"">
code from a less-trusted and less peer-reviewed source.&nbsp; Ideally, =
one<br class=3D"">
would personally audit this code for one's self, but in practice that<br =
class=3D"">
rarely happens.<br class=3D"">
<br class=3D"">
In the case of a website generator, the code must be audited again =
each<br class=3D"">
time it is downloaded.&nbsp; I cannot in good faith recommend to anyone =
to<br class=3D"">
use such third party tools for wallet generation.<br class=3D"">
<br class=3D"">
I *would* recommend for others to trust a paper wallet that uses<br =
class=3D"">
address(es) generated by bitcoin-core itself.<br class=3D"">
<br class=3D"">
At least for me, this requirement to audit (or implicitly trust) a<br =
class=3D"">
secondary body of bitcoin code places an additional hurdle or<br =
class=3D"">
disincentive on the use of paper wallets, or indeed private keys<br =
class=3D"">
generated outside of bitcoin-core for any purpose.<br class=3D"">
<br class=3D"">
Unfortunately, one cannot simply use getnewaddress, =
getaccountaddress,<br class=3D"">
or getrawchangeaddress for this purpose, because the associated =
private<br class=3D"">
keys are added to the bitcoin-core wallet and cannot be removed... or =
in<br class=3D"">
the case of hd-wallets are deterministically derived.<br class=3D"">
<br class=3D"">
As such, I'm throwing out the following half-baked proposal as a<br =
class=3D"">
starting point for discussion:<br class=3D"">
<br class=3D"">
<br class=3D"">
-----<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; genexternaladdress ( "type" )<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; Returns a new Bitcoin address and private key for =
receiving<br class=3D"">
&nbsp; &nbsp; payments. This key/address is intended for external usage =
such as<br class=3D"">
&nbsp; &nbsp; paper wallets and will not be used by internal wallet nor =
written to<br class=3D"">
&nbsp; &nbsp; disk.<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; Arguments:<br class=3D"">
&nbsp; &nbsp; 1. "type"&nbsp; &nbsp; &nbsp; &nbsp; (string, optional) =
one of: p2pkh, p2sh-p2wpkh<br class=3D"">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
default: p2sh-p2wpkh<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; Result:<br class=3D"">
&nbsp; &nbsp; {<br class=3D"">
&nbsp; &nbsp; &nbsp; &nbsp; "privKey"&nbsp; &nbsp; (string) The private =
key in wif format.<br class=3D"">
&nbsp; &nbsp; &nbsp; &nbsp; "address"&nbsp; &nbsp; (string) The address =
in p2pkh or p2sh-p2wpkh<br class=3D"">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; format.<br class=3D"">
&nbsp; &nbsp; }<br class=3D"">
<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; Examples:<br class=3D"">
&nbsp; &nbsp; &gt; bitcoin-cli genexternaladdress<br class=3D"">
<br class=3D"">
<br class=3D"">
----<br class=3D"">
<br class=3D"">
This API is simple to implement and use.&nbsp; It provides enough<br =
class=3D"">
functionality for any moderately skilled developer to create their =
own<br class=3D"">
paper wallet creation script using any scripting language, or even =
for<br class=3D"">
advanced users to perform using bitcoin-cli or debug console.<br =
class=3D"">
<br class=3D"">
If consensus here is in favor of including such an API, I will be =
happy<br class=3D"">
to take a crack at implementing it and submitting a pull request.<br =
class=3D"">
<br class=3D"">
If anyone has reasons why it is a BAD IDEA to include such an RPC =
call<br class=3D"">
in bitcoind, I'm curious to hear it.<br class=3D"">
<br class=3D"">
Also, I welcome suggestions for a better name, or maybe there could =
be<br class=3D"">
some improvements to the param(s), such as calling p2sh-p2wpkh =
"segwit"<br class=3D"">
instead.<br class=3D"">
<br class=3D"">
<br class=3D"">
---- further work ----<br class=3D"">
<br class=3D"">
<br class=3D"">
Further steps could be taken in this direction, but are not necessary<br =
class=3D"">
for a useful first-step.&nbsp; In particular:<br class=3D"">
<br class=3D"">
1. an RPC call to generate an external HD wallet seed.<br class=3D"">
2. an RPC call to generate N key/address pairs from a given seed.<br =
class=3D"">
3. GUI functionality in bitcoin-qt to facilitate easy paper wallet<br =
class=3D"">
generation (and printing?) for end-users, complete with nice =
graphics,<br class=3D"">
qr codes, etc.<br =
class=3D""></blockquote></div></div></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_7F879A41-4709-4C3B-8F62-AA099BA9FBBE--

--Apple-Mail=_CD33B5AD-EFE6-48BD-90CD-56A4E2085019
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-----

iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlnOq1wACgkQV/+b28ww
EAkNsQ//QWQ9eFkvGLwT+fzFV5cQKKR0WdK+iRAkMKyaYdu/wPfiMnh8n6sLhXBt
E4BeQQH7Yqg/FoDGh1pjI8+2RixfYLRsGgtKc16GNXNOdubJihpBWxKC++//4mPz
3hOt/Vfw1LvfNYxywmMqXsPoOLHBoyKM2mrlggiYQkDVZw+xulmlh/0o16hW6420
LY8bwE4P1pSXtIbnT02p3kjjRQ60GWctlbdmhPWhWnpXNBcwg4Ghl6SsdRwj8P2O
cBC1QHz0Kmg8i2bfjN+8Q7sGG4gp851gv+JFjpoFcf9Y74xnX3DQqaxtsV7BIxTB
NVaHM+V37RjHvueBjn9g3AsgDcOH4JUvP8xT+MBxtrkKwI3gAiDJ7WRPAaD8SMVG
a38XhkzK30yc/SsxDdCm+Nv2uHSv718CheCT7d2jkR+bK8/m7OSXYsJy3OzJafPW
nQ+4bCA0csb+8MCM5PiSbAMAuiZ/pJTuwDSgZIAZDsIzkDLFsuPt/UTkgsJzs9wJ
uJVnGuxm7gLDfw/2P/WLCEShoFUQ7jkzdGVkD1J1P5Vyt3jlGJUgM/3DEZeKN1ug
/VNaARfY7RQQlLJCnPGrFGMe65cp73ShyMp/BgpIfvZx5/z3ck52zGYKOVyO5Juf
8kxsi7d+aqbro40M5ANvmjvN1uxaOVtmvAlKw6RBvO+RUtpKg4o=
=zxkh
-----END PGP SIGNATURE-----

--Apple-Mail=_CD33B5AD-EFE6-48BD-90CD-56A4E2085019--