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
next prev parent 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