diff options
author | Dan Libby <dan@osc.co.cr> | 2017-09-29 15:13:47 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-09-29 22:13:50 +0000 |
commit | 71ea3588e40cad88e1884c25db7b700f1ee92fe3 (patch) | |
tree | 04c308979bce50c16826186f66e7df130cefca40 | |
parent | 7c604f304b5d0fca2f560708780035b265384f64 (diff) | |
download | pi-bitcoindev-71ea3588e40cad88e1884c25db7b700f1ee92fe3.tar.gz pi-bitcoindev-71ea3588e40cad88e1884c25db7b700f1ee92fe3.zip |
Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
-rw-r--r-- | 3f/19e237054e41a1e6d88bfb2b06e2b59f0c3a19 | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/3f/19e237054e41a1e6d88bfb2b06e2b59f0c3a19 b/3f/19e237054e41a1e6d88bfb2b06e2b59f0c3a19 new file mode 100644 index 000000000..1f785e888 --- /dev/null +++ b/3f/19e237054e41a1e6d88bfb2b06e2b59f0c3a19 @@ -0,0 +1,187 @@ +Return-Path: <dan@osc.co.cr> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BF1EB96F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Sep 2017 22:13:50 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail.osc.co.cr (unknown [168.235.79.83]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A0E74DB + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 29 Sep 2017 22:13:49 +0000 (UTC) +Received: from [192.168.2.225] (miner1 [71.94.45.245]) + (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) + (No client certificate requested) (Authenticated sender: danda) + by mail.osc.co.cr (Postfix) with ESMTPSA id DC0F3202A8; + Fri, 29 Sep 2017 15:13:48 -0700 (PDT) +To: Luke Dashjr <luke@dashjr.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr> + <201709292103.36630.luke@dashjr.org> +From: Dan Libby <dan@osc.co.cr> +Message-ID: <dcfaa57d-3fcd-973e-2548-5f9f318c0682@osc.co.cr> +Date: Fri, 29 Sep 2017 15:13:47 -0700 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 + Thunderbird/52.3.0 +MIME-Version: 1.0 +In-Reply-To: <201709292103.36630.luke@dashjr.org> +Content-Type: text/plain; charset=utf-8 +Content-Language: en-US +Content-Transfer-Encoding: 8bit +X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=disabled + version=3.3.1 +X-Spam-Level: * +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:15:54 +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 22:13:51 -0000 + +It seems to me that the same statement can be made for *any* key storage +mechanism depending on one's security/threat model, including +bitcoin-core's internal wallet storage. There certainly are cases where +a paper (or metal) offline wallet makes a lot of sense, particularly for +long-term offline storage... something that electronic media pretty much +sucks at. + +Though if you care to elaborate I'd be interested to learn of your +specific critiques, if you have any beyond the generic statements here: +https://en.bitcoin.it/wiki/Paper_wallet + +Regardless, the APIs I've proposed have uses beyond paper wallets. It +can also be used by third party wallets, or any number of reasons that +individuals or devs might have to generate keys. + + + +On 09/29/2017 02:03 PM, Luke Dashjr wrote: +> Paper wallets are a safety hazard, insecure, and generally not advisable. +> +> +> On Friday 29 September 2017 5:29:17 PM Dan Libby via bitcoin-dev 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 + + +-- +Dan Libby + +Open Source Consulting S.A. +Santa Ana, Costa Rica +http://osc.co.cr +phone: 011 506 2204 7018 +Fax: 011 506 2223 7359 + |