A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of not 
needing to trust a printer.

However without also supporting BIP43/44/49 this would probably cause 
confusion. Supporting these would be a larger project as well. Although widely 
used, the standards are still Proposed / Draft. There's  might be room for 
improvement [0].

Sjors

[0] https://github.com/satoshilabs/slips/issues/103

> Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> 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 <http://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 
> <mailto: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 <http://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.

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to