From: Dan Libby <dan@osc.co.cr>
To: Andrew Johnson <andrew.johnson83@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Date: Fri, 29 Sep 2017 12:34:57 -0700 [thread overview]
Message-ID: <6cd2299b-d38e-7bbc-e95e-9ce5ff13fc9e@osc.co.cr> (raw)
In-Reply-To: <CAAy62_Jfp00gsAjTWvr1E8aYx9z9aYM9y6AqqrgK8HizQm08xQ@mail.gmail.com>
On 09/29/2017 11:07 AM, Andrew Johnson wrote:
> One consideration of exposing this in QT is that it may encourage users
> to generate paper wallets(which are generally used and recommended for
> cold storage) from online machines, rendering them moreso lukewarm
> rather than cold, since the keys weren't generated in an air-gapped
> environment.
true that. Though there's nothing stopping a diligent person from
installing bitcoin-core on a dedicated offline machine. The blockchain
wouldn't need to be synced at all for key generation purposes.
> When using bitaddress.org <http://bitaddress.org>
> locally(we /are /all only using it locally and not directly from the
> online webpage, right? ;) ) you've at least made the effort to seek out
> the repo, clone it locally, and use it on an offline machine and not
> retain any data from that session.
yeah, so I noticed this issue about Paper Wallet generation not being
possible with bitcoin-core exactly because I was recommending to a
non-technical user to use paper wallets, but then I also had to point
out that really bitaddress code should be downloaded, audited, etc,
before use. Things that are actually impossible for a non-technical user.
So I figured that instead I would make a simple script for them that
would use bitcoin-core to generate the addresses... and that's when it
dawned on me that it won't actually work with present day RPCs that are
all tied to internal wallet.
hence, this proposal.
> I'd suggest that any UI in QT include some sort of a modal dialog that
> informs the user that this is not a secure cold storage address unless
> it was created on an offline machine and printed on a non-networked
> printer, and the prompt must be accepted and dismissed before the wallet
> will provide the requested keys.
yes, agreed.
next prev parent reply other threads:[~2017-09-29 19:35 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 [this message]
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
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=6cd2299b-d38e-7bbc-e95e-9ce5ff13fc9e@osc.co.cr \
--to=dan@osc.co.cr \
--cc=andrew.johnson83@gmail.com \
--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