public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dan Libby <dan@osc.co.cr>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Date: Fri, 29 Sep 2017 13:13:59 -0700	[thread overview]
Message-ID: <847d24d6-f1ee-e15c-9f85-a8bd45d57501@osc.co.cr> (raw)
In-Reply-To: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>

One additional thought:

It should be useful to also define a multi-sig generation RPC.

This would facilitate multi-sig paper wallets stored in different
physical locations, amongst other use-cases.

Something like:

-----

    genexternalmultisigaddress ( "m", "n", "type" )

    Returns a new Bitcoin address and n number of private key(s).
    This address and associated keys is intended for external usage such
    as paper wallets and will not be used by internal wallet nor written
    to disk.

    Arguments:
    1. "m"           (integer, required) The number of required signers
                                         to send funds.
    2. "n"           (integer, required) The number of authorized
                                         signers
    3. "type"        (string, optional)  one of: p2sh-p2pkh, p2sh-p2wpkh
                                         default: p2sh-p2wpkh

    Result:
    {
        "address",   (string) The address in p2pkh or p2sh-p2wpkh
                              format.
        "privkeys": [
            (string) The private key in wif format.
        ]
    }


    Examples:
    > bitcoin-cli genexternalmultisigaddress 2 3

-----



On 09/29/2017 10:29 AM, 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.


  parent reply	other threads:[~2017-09-29 20:14 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 [this message]
     [not found] ` <201709292103.36630.luke@dashjr.org>
2017-09-29 22:13   ` Dan Libby
2017-09-29 22:19     ` Dan Libby
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=847d24d6-f1ee-e15c-9f85-a8bd45d57501@osc.co.cr \
    --to=dan@osc.co.cr \
    --cc=bitcoin-dev@lists.linuxfoundation.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