One consideration of exposing this in QT is that it may encourage users to generate paper wallets(which are generally used and recommended for cold storage) from online machines, rendering them moreso lukewarm rather than cold, since the keys weren't generated in an air-gapped environment.  When using bitaddress.org locally(we are all only using it locally and not directly from the online webpage, right? ;) ) you've at least made the effort to seek out the repo, clone it locally, and use it on an offline machine and not retain any data from that session.

If we include this as a function in the reference implementation, how many people are going to be making paper wallets with the intention of cold storage on a machine that's potentially compromised?  As adoption(hopefully) continues to increase the number of less than tech savvy people using bitcoin will increase.

I'd suggest that any UI in QT include some sort of a modal dialog that informs the user that this is not a secure cold storage address unless it was created on an offline machine and printed on a non-networked printer, and the prompt must be accepted and dismissed before the wallet will provide the requested keys.


On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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



--
Andrew Johnson