diff options
| author | Sjors Provoost <sjors@sprovoost.nl> | 2017-09-29 22:21:48 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-29 20:21:54 +0000 |
| commit | d42857f916f6dc30a8ff98da54b7c598a8136f40 (patch) | |
| tree | c3a35f6776b1b6c16b8a22cd8416abc2a8dab1c9 /c9 | |
| parent | 71ea3588e40cad88e1884c25db7b700f1ee92fe3 (diff) | |
| download | pi-bitcoindev-d42857f916f6dc30a8ff98da54b7c598a8136f40.tar.gz pi-bitcoindev-d42857f916f6dc30a8ff98da54b7c598a8136f40.zip | |
Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Diffstat (limited to 'c9')
| -rw-r--r-- | c9/e8ca2410c582f74e2875435c8a0596c8a3c158 | 446 |
1 files changed, 446 insertions, 0 deletions
diff --git a/c9/e8ca2410c582f74e2875435c8a0596c8a3c158 b/c9/e8ca2410c582f74e2875435c8a0596c8a3c158 new file mode 100644 index 000000000..427c893a3 --- /dev/null +++ b/c9/e8ca2410c582f74e2875435c8a0596c8a3c158 @@ -0,0 +1,446 @@ +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 might be room for improvement [0]. <div class=3D""><br = +class=3D""></div><div class=3D"">Sjors</div><div class=3D""><br = +class=3D""></div><div class=3D"">[0] <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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> 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. When = +using <a href=3D"http://bitaddress.org/" class=3D"">bitaddress.org</a> = +locally(we <i class=3D"">are </i>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.<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? 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""><<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>></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>. This requires placing trust in an = +additional body of<br class=3D""> +code from a less-trusted and less peer-reviewed source. 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. 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""> + genexternaladdress ( "type" )<br class=3D""> +<br class=3D""> + Returns a new Bitcoin address and private key for = +receiving<br class=3D""> + payments. This key/address is intended for external usage = +such as<br class=3D""> + paper wallets and will not be used by internal wallet nor = +written to<br class=3D""> + disk.<br class=3D""> +<br class=3D""> + Arguments:<br class=3D""> + 1. "type" (string, optional) = +one of: p2pkh, p2sh-p2wpkh<br class=3D""> + = + = +default: p2sh-p2wpkh<br class=3D""> +<br class=3D""> + Result:<br class=3D""> + {<br class=3D""> + "privKey" (string) The private = +key in wif format.<br class=3D""> + "address" (string) The address = +in p2pkh or p2sh-p2wpkh<br class=3D""> + = + format.<br class=3D""> + }<br class=3D""> +<br class=3D""> +<br class=3D""> + Examples:<br class=3D""> + > 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. 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. 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-- + |