Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C637B66 for ; Fri, 29 Sep 2017 17:29:21 +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 8CF431A6 for ; Fri, 29 Sep 2017 17:29:20 +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 B8E321F031 for ; Fri, 29 Sep 2017 10:29:19 -0700 (PDT) To: Bitcoin Protocol Discussion From: Dan Libby Message-ID: Date: Fri, 29 Sep 2017 10:29:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 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 17:32:50 +0000 Subject: [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 17:29:21 -0000 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.