public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dan Libby <dan@osc.co.cr>
To: Luke Dashjr <luke@dashjr.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Date: Fri, 29 Sep 2017 15:19:46 -0700	[thread overview]
Message-ID: <51935ee9-ef24-22cf-638e-cd5679df94ce@osc.co.cr> (raw)
In-Reply-To: <dcfaa57d-3fcd-973e-2548-5f9f318c0682@osc.co.cr>

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


  reply	other threads:[~2017-09-29 22:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-29 17:29 [bitcoin-dev] Paper Wallet support in bitcoin-core Dan Libby
2017-09-29 18:07 ` Andrew Johnson
2017-09-29 19:34   ` Dan Libby
2017-09-29 20:21   ` Sjors Provoost
2017-09-29 20:13 ` Dan Libby
     [not found] ` <201709292103.36630.luke@dashjr.org>
2017-09-29 22:13   ` Dan Libby
2017-09-29 22:19     ` Dan Libby [this message]
2017-09-30  4:49 ` Jonas Schnelli
2017-09-30  7:06   ` Dan Libby
2017-09-30 21:14     ` Jonas Schnelli
2017-09-30 23:51       ` Aymeric Vitte
2017-09-30  7:36   ` Sjors Provoost
2017-09-30  9:35   ` Adam Ritter
2017-09-30 11:10   ` Aymeric Vitte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51935ee9-ef24-22cf-638e-cd5679df94ce@osc.co.cr \
    --to=dan@osc.co.cr \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox