Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 588C29B9 for ; Fri, 29 Sep 2017 20:14:01 +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 DBB21D3 for ; Fri, 29 Sep 2017 20:14:00 +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 22568202A8 for ; Fri, 29 Sep 2017 13:14:00 -0700 (PDT) To: Bitcoin Protocol Discussion References: From: Dan Libby Message-ID: <847d24d6-f1ee-e15c-9f85-a8bd45d57501@osc.co.cr> Date: Fri, 29 Sep 2017 13:13:59 -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: 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 20:21:43 +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:14:01 -0000 One additional thought: It should be useful to also define a multi-sig generation RPC. This would facilitate multi-sig paper wallets stored in different physical locations, amongst other use-cases. Something like: ----- genexternalmultisigaddress ( "m", "n", "type" ) Returns a new Bitcoin address and n number of private key(s). This address and associated keys is intended for external usage such as paper wallets and will not be used by internal wallet nor written to disk. Arguments: 1. "m" (integer, required) The number of required signers to send funds. 2. "n" (integer, required) The number of authorized signers 3. "type" (string, optional) one of: p2sh-p2pkh, p2sh-p2wpkh default: p2sh-p2wpkh Result: { "address", (string) The address in p2pkh or p2sh-p2wpkh format. "privkeys": [ (string) The private key in wif format. ] } Examples: > bitcoin-cli genexternalmultisigaddress 2 3 ----- On 09/29/2017 10:29 AM, 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.