path: root/45/6cea38cddc3cc7ee6c5d360de3dd6e74128a9f

Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A997B9B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 18:07:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
	[209.85.216.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB1BA46B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 18:07:27 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id q4so563842qtq.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 11:07:27 -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=WBIp9KpEQjsDL+Cof8snNlM/+Y7IexIbHPn1DwNZv4k=;
	b=n9Vfgu7ouPINw11y3zFhGi7U2BuLaua2j5WAzl05m/IGPqqdxQk3+S1mpCqgWwKkr0
	woWocjkUff3h/Xj/Gow3+jUMtQRvu6SiKrg2pXOuSkCiXWgOuKQ/JV+w9LWpM04jnb+h
	VHCjjxFzaalFgQyg4ibd5ovyiK6n8IhJoqu19fxiXAlbuvN2KI77Z0lJ3WlIgzUGoF2o
	mwCyCqsvCqcFMwhoZul4CW/bvJdNAiuIcdTOxo4/VS43w073KifYTUb/R3JghlxoOWeO
	ed5mWiW9ROOkNyFwaJH2jSgprsprtx3IjCvfvtQVa4Cw2YvznXwjL4bY9dK1RiXo9wZX
	yzRQ==
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=WBIp9KpEQjsDL+Cof8snNlM/+Y7IexIbHPn1DwNZv4k=;
	b=qIKYFseJQnNcpUmTAFn0emowN5tKkmeqJ4p65/wiQZFyvgrDg9kkWkIMlQ1cbENvfV
	yJOf+8PcUypkZ17i9QfP9t7AGW/52BtZRSN6iAi5lFMNGStXpyjQKsiSifu2yj28fQ7J
	ErXW15QA0hEmOjAxqmepnfLAePN/ucMF8B7YrcZL97U1iSr6AH4VJtXmuYU9T7YTlwSW
	SaNza1ckPyhdl3P1tDD3gTpdMcFRfBfODzjYkLEJonDpoTRaNc8MUENz9DmtwUJceDsD
	RIxdsC8Qi1Xy8gEt1p+0hYPonJIegwBdKngA6fNyNESAEf4PDzvZrLf1ff2w7A56zFeT
	UdhQ==
X-Gm-Message-State: AMCzsaVMFyeBmCXbncA/lVAT1ZHtK1ZdpGn++XCUO+TjILjlkNQZfUQT
	B2KcRn9t3YIC+YT7NSYfGtlOM9S8KcRpnxRSHmE=
X-Google-Smtp-Source: AOwi7QA2GzVybI5I7QSSCMAROZ+zhOkhQTiJwow9+pPATTGxQfK3l+v99V1W0EBs5P1mehNu7MEChVtFDSXa9kzIWWQ=
X-Received: by 10.237.62.129 with SMTP id n1mr7512765qtf.39.1506708446751;
	Fri, 29 Sep 2017 11:07:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.61.245 with HTTP; Fri, 29 Sep 2017 11:07:26 -0700 (PDT)
In-Reply-To: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Fri, 29 Sep 2017 13:07:26 -0500
Message-ID: <CAAy62_Jfp00gsAjTWvr1E8aYx9z9aYM9y6AqqrgK8HizQm08xQ@mail.gmail.com>
To: Dan Libby <dan@osc.co.cr>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114441aebfb2cb055a57e550"
X-Spam-Status: No, score=-0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,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: Fri, 29 Sep 2017 18:08:14 +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 18:07:28 -0000

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

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 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.

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.

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.


On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby 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].
>
> -- rationale --
>
> bitcoin-core is the most trusted and most secure bitcoin implementation.
>
> Yet today (unless I've missed something) paper wallet generation
> requires use of third party software, or even a website such as
> 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.
>
> 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.
>
> I *would* recommend for others to trust a paper wallet that uses
> address(es) generated by bitcoin-core itself.
>
> 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.
>
> 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.
>
> As such, I'm throwing out the following half-baked proposal as a
> starting point for discussion:
>
>
> -----
>
>     genexternaladdress ( "type" )
>
>     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.
>
>     Arguments:
>     1. "type"        (string, optional) one of: p2pkh, p2sh-p2wpkh
>                                         default: p2sh-p2wpkh
>
>     Result:
>     {
>         "privKey"    (string) The private key in wif format.
>         "address"    (string) The address in p2pkh or p2sh-p2wpkh
>                               format.
>     }
>
>
>     Examples:
>     > bitcoin-cli genexternaladdress
>
>
> ----
>
> 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.
>
> 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.
>
> If anyone has reasons why it is a BAD IDEA to include such an RPC call
> in bitcoind, I'm curious to hear it.
>
> 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.
>
>
> ---- further work ----
>
>
> Further steps could be taken in this direction, but are not necessary
> for a useful first-step.  In particular:
>
> 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.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Andrew Johnson

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

<div dir=3D"ltr">One consideration of exposing this in QT is that it may en=
courage users to generate paper wallets(which are generally used and recomm=
ended for cold storage) from online machines, rendering them moreso lukewar=
m rather than cold, since the keys weren&#39;t generated in an air-gapped e=
nvironment.=C2=A0 When using <a href=3D"http://bitaddress.org">bitaddress.o=
rg</a> locally(we=C2=A0<i>are </i>all only=C2=A0using it locally and not di=
rectly from the online webpage, right? ;) )=C2=A0you&#39;ve at least made t=
he 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><br></div><div>If we=
 include this as a function in the reference implementation, how many peopl=
e are going to be making paper wallets with the intention of cold storage o=
n a machine that&#39;s potentially compromised?=C2=A0 As adoption(hopefully=
) continues to increase the number of less than tech savvy people using bit=
coin will increase.</div><div><br></div><div>I&#39;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 machi=
ne 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>=
<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">Hi,<br>
<br>
I&#39;m writing to suggest and discuss the addition of paper wallet<br>
functionality in bitcoin-core software, starting with a single new RPC<br>
call: genExternalAddress [type].<br>
<br>
-- rationale --<br>
<br>
bitcoin-core is the most trusted and most secure bitcoin implementation.<br=
>
<br>
Yet today (unless I&#39;ve missed something) paper wallet generation<br>
requires use of third party software, or even a website such as<br>
<a href=3D"http://bitaddress.org" rel=3D"noreferrer" target=3D"_blank">bita=
ddress.org</a>.=C2=A0 This requires placing trust in an additional body of<=
br>
code from a less-trusted and less peer-reviewed source.=C2=A0 Ideally, one<=
br>
would personally audit this code for one&#39;s self, but in practice that<b=
r>
rarely happens.<br>
<br>
In the case of a website generator, the code must be audited again each<br>
time it is downloaded.=C2=A0 I cannot in good faith recommend to anyone to<=
br>
use such third party tools for wallet generation.<br>
<br>
I *would* recommend for others to trust a paper wallet that uses<br>
address(es) generated by bitcoin-core itself.<br>
<br>
At least for me, this requirement to audit (or implicitly trust) a<br>
secondary body of bitcoin code places an additional hurdle or<br>
disincentive on the use of paper wallets, or indeed private keys<br>
generated outside of bitcoin-core for any purpose.<br>
<br>
Unfortunately, one cannot simply use getnewaddress, getaccountaddress,<br>
or getrawchangeaddress for this purpose, because the associated private<br>
keys are added to the bitcoin-core wallet and cannot be removed... or in<br=
>
the case of hd-wallets are deterministically derived.<br>
<br>
As such, I&#39;m throwing out the following half-baked proposal as a<br>
starting point for discussion:<br>
<br>
<br>
-----<br>
<br>
=C2=A0 =C2=A0 genexternaladdress ( &quot;type&quot; )<br>
<br>
=C2=A0 =C2=A0 Returns a new Bitcoin address and private key for receiving<b=
r>
=C2=A0 =C2=A0 payments. This key/address is intended for external usage suc=
h as<br>
=C2=A0 =C2=A0 paper wallets and will not be used by internal wallet nor wri=
tten to<br>
=C2=A0 =C2=A0 disk.<br>
<br>
=C2=A0 =C2=A0 Arguments:<br>
=C2=A0 =C2=A0 1. &quot;type&quot;=C2=A0 =C2=A0 =C2=A0 =C2=A0 (string, optio=
nal) one of: p2pkh, p2sh-p2wpkh<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default:=
 p2sh-p2wpkh<br>
<br>
=C2=A0 =C2=A0 Result:<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;privKey&quot;=C2=A0 =C2=A0 (string) The p=
rivate key in wif format.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;address&quot;=C2=A0 =C2=A0 (string) The a=
ddress in p2pkh or p2sh-p2wpkh<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 format.<br>
=C2=A0 =C2=A0 }<br>
<br>
<br>
=C2=A0 =C2=A0 Examples:<br>
=C2=A0 =C2=A0 &gt; bitcoin-cli genexternaladdress<br>
<br>
<br>
----<br>
<br>
This API is simple to implement and use.=C2=A0 It provides enough<br>
functionality for any moderately skilled developer to create their own<br>
paper wallet creation script using any scripting language, or even for<br>
advanced users to perform using bitcoin-cli or debug console.<br>
<br>
If consensus here is in favor of including such an API, I will be happy<br>
to take a crack at implementing it and submitting a pull request.<br>
<br>
If anyone has reasons why it is a BAD IDEA to include such an RPC call<br>
in bitcoind, I&#39;m curious to hear it.<br>
<br>
Also, I welcome suggestions for a better name, or maybe there could be<br>
some improvements to the param(s), such as calling p2sh-p2wpkh &quot;segwit=
&quot;<br>
instead.<br>
<br>
<br>
---- further work ----<br>
<br>
<br>
Further steps could be taken in this direction, but are not necessary<br>
for a useful first-step.=C2=A0 In particular:<br>
<br>
1. an RPC call to generate an external HD wallet seed.<br>
2. an RPC call to generate N key/address pairs from a given seed.<br>
3. GUI functionality in bitcoin-qt to facilitate easy paper wallet<br>
generation (and printing?) for end-users, complete with nice graphics,<br>
qr codes, etc.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.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-<wbr>dev</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature">Andrew Johnson<br><=
div><br></div></div>
</div>

--001a114441aebfb2cb055a57e550--