From: Dan Libby <dan@osc.co.cr>
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>
	<dcfaa57d-3fcd-973e-2548-5f9f318c0682@osc.co.cr>
Message-ID: <51935ee9-ef24-22cf-638e-cd5679df94ce@osc.co.cr>
Date: Fri, 29 Sep 2017 15:19:46 -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: <dcfaa57d-3fcd-973e-2548-5f9f318c0682@osc.co.cr>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Precedence: list

Anyway, I'll count that as a NAK from Luke.  what do others here think?

I wish to guage if I were to submit a functional pull request for one or
both of these RPC calls, if would it be likely to be accepted.

If so I'm happy to contribute my time, otherwise...

On 09/29/2017 03:13 PM, Dan Libby wrote:
> 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