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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
