1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <dan@osc.co.cr>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BF1EB96F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 22:13:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.osc.co.cr (unknown [168.235.79.83])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A0E74DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 22:13:49 +0000 (UTC)
Received: from [192.168.2.225] (miner1 [71.94.45.245])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested) (Authenticated sender: danda)
by mail.osc.co.cr (Postfix) with ESMTPSA id DC0F3202A8;
Fri, 29 Sep 2017 15:13:48 -0700 (PDT)
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
<201709292103.36630.luke@dashjr.org>
From: Dan Libby <dan@osc.co.cr>
Message-ID: <dcfaa57d-3fcd-973e-2548-5f9f318c0682@osc.co.cr>
Date: Fri, 29 Sep 2017 15:13:47 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <201709292103.36630.luke@dashjr.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=disabled
version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 29 Sep 2017 22:15:54 +0000
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 22:13:51 -0000
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
|
