Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 72E83A95 for ; 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 ; 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 ; 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: 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 ; Fri, 29 Sep 2017 16:21:50 -0400 (EDT) From: Sjors Provoost 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: To: Bitcoin Protocol Discussion In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 = 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 = > 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 . 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 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:

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.

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