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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev