From: Aymeric Vitte <vitteaymeric@gmail.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Dan Libby <dan@osc.co.cr>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Date: Sat, 30 Sep 2017 13:10:45 +0200 [thread overview]
Message-ID: <f83df1e7-9a90-64e4-e644-f10262408791@gmail.com> (raw)
In-Reply-To: <96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch>
I am not sure that this discussion is really off topic for this list,
this is a real issue, would everybody even here say that they feel very
comfortable with their keys? That if something happen to them there is
no pb for the family or trusted parties to retrieve the keys? That this
process is secured in case the trusted parties are finally untrusted? etc
I don't think so, if experts are not comfortable then how can we expect
non experts people to manage this? (except going to a wallet sw asking
them all the info, even online, crazy but they just don't know)
Comments below
Le 30/09/2017 à 06:49, Jonas Schnelli via bitcoin-dev a écrit :
> And I would also extend those concerns to BIP39 plaintext paper backups.
Personnaly I don't see also the advantage of proposals such as BIP39 versus backing up a seed
> IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os.
This is the intent of https://github.com/Ayms/bitcoin-wallets and
https://github.com/Ayms/zcash-wallets
But even myself can get confused, where did I put the backup seed? But
remember you did not backup the seed but the first derivation step and
you mixed it secretely, so nobody can reconstitute it except you,
well... what did I do exactly? What version is my real wallet? What is
the encryption key? How did I do last time to add the key in qt? etc
> They should never leave the device over the channel used for the signing I/O. Users should have no way to view or export the private keys (expect for the seed backup). Backups should be encrypted (whoever finds the paper backup should need a second factor to decrypt) and the restore process should be footgun-safe (especially the lost-passphrase deadlock).
Is there really nothing existing yet to address all of this?
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
prev parent reply other threads:[~2017-09-30 11:10 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
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 [this message]
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=f83df1e7-9a90-64e4-e644-f10262408791@gmail.com \
--to=vitteaymeric@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=dan@osc.co.cr \
--cc=dev@jonasschnelli.ch \
/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