From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 35E366C for ; Sat, 30 Sep 2017 07:06:45 +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 BBB4DFC for ; Sat, 30 Sep 2017 07:06:44 +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 C285B20D69; Sat, 30 Sep 2017 00:06:43 -0700 (PDT) To: Jonas Schnelli , Bitcoin Protocol Discussion References: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch> From: Dan Libby Message-ID: <05caf783-cba2-b37a-0f28-2d0020386279@osc.co.cr> Date: Sat, 30 Sep 2017 00:06:42 -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: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch> Content-Type: text/plain; charset=windows-1252 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: Sat, 30 Sep 2017 10:41:53 +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: Sat, 30 Sep 2017 07:06:45 -0000 On 09/29/2017 09:49 PM, Jonas Schnelli wrote: > AFAIK, client implementations such as your proposal are off-topic for this ML. > Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals. ok, thanks. I will take the proposal there. > I have to agree with Luke. thanks for your feedback. > And I would also extend those concerns to BIP39 plaintext paper backups. > > IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os. uhh.... do you apply this logic to the bitcoin-core wallet itself? because clearly it generates keys and is intended to be used for signing in online environments. Lots of real-world use-cases depend on that today. So if existing bitcoin-core wallet behavior is "ok" in any context then how is it any worse for it to generate a key/address that will not be stored in the internal wallet, and the user may do with it as they wish? That is all my proposed RPC call does and unlike the existing RPC calls it never even stores the key or address to disk. It is also useful when run on an offline hardware device, such as a laptop connected to an non-networked printer. Further, you mention the word trust. That's the crux of the matter. As a full node operator, I've already placed my trust in the bitcoin-core developers and dev/release practices. Why exactly should I trust the software in this minimal offline hardware/os you mention if it is NOT bitcoin core? And even if open source software, does that not at least double my workload/expense to audit theat software in addition to bitcoin-core? > Users should have no way to view or export the private keys (expect for > the seed backup). I suppose that in your view then, dumpprivkey and dumpwallet RPCs should be removed from bitcoin-core to fit this paradigm? (Personally I actively avoid wallet software that takes this view and treat users like children, preventing individuals direct access to the keys for their own funds, which disempowers and sometimes results in a form of lockin) > Backups should be encrypted (whoever finds the paper backup should need a second factor to decrypt) and the restore process should be footgun-safe (especially the lost-passphrase deadlock). This is more relevant to an application layer above the 2 RPC calls I proposed. Encryption could be implemented (or not) by whichever software calls the proposed RPC apis. And further the APIs can be called for use-cases beyond just paper wallets.