[bitcoin-dev] Paper Wallet support in bitcoin-core

[Dan Libby via bitcoin-dev]

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.
}

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.

[Andrew Johnson via bitcoin-dev]

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. When
using 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.

If we include this as a function in the reference implementation, how many
people are going to be making paper wallets with the intention of cold
storage on a machine that's potentially compromised? As
adoption(hopefully) continues to increase the number of less than tech
savvy people using bitcoin will increase.

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.


On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev <

Post by Dan Libby via bitcoin-dev
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
-----
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.
1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
{
"privKey" (string) The private key in wif format.
"address" (string) The address in p2pkh or p2sh-p2wpkh
format.
}

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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Dan Libby via bitcoin-dev]

Post by Andrew Johnson via bitcoin-dev
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.

Post by Andrew Johnson via bitcoin-dev
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.

Post by Andrew Johnson via bitcoin-dev
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.

[Sjors Provoost via bitcoin-dev]

A 12-24 word BIP39 mnemonic is easy to write down and has the benefit of not needing to trust a printer.

However without also supporting BIP43/44/49 this would probably cause confusion. Supporting these would be a larger project as well. Although widely used, the standards are still Proposed / Draft. There's might be room for improvement [0].

Sjors

[0] https://github.com/satoshilabs/slips/issues/103

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. 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.
If we include this as a function in the reference implementation, how many people are going to be making paper wallets with the intention of cold storage on a machine that's potentially compromised? As adoption(hopefully) continues to increase the number of less than tech savvy people using bitcoin will increase.
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.
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 <http://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
-----
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.
1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
{
"privKey" (string) The private key in wif format.
"address" (string) The address in p2pkh or p2sh-p2wpkh
format.
}

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
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.

[Dan Libby via bitcoin-dev]

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.
]
}

bitcoin-cli genexternalmultisigaddress 2 3

-----

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.

[Dan Libby via bitcoin-dev]

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.

Paper wallets are a safety hazard, insecure, and generally not advisable.

Post by Dan Libby via bitcoin-dev
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
-----
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.
1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
{
"privKey" (string) The private key in wif format.
"address" (string) The address in p2pkh or p2sh-p2wpkh
format.
}

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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Dan Libby via bitcoin-dev]

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...

Post by Dan Libby via bitcoin-dev
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
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.

Paper wallets are a safety hazard, insecure, and generally not advisable.

Post by Dan Libby via bitcoin-dev
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
-----
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.
1. "type" (string, optional) one of: p2pkh, p2sh-p2wpkh
default: p2sh-p2wpkh
{
"privKey" (string) The private key in wif format.
"address" (string) The address in p2pkh or p2sh-p2wpkh
format.
}

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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jonas Schnelli via bitcoin-dev]

Post by Dan Libby via bitcoin-dev
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].

AFAIK, client implementations such as your proposal are off-topic for this ML.
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.

Post by Dan Libby via bitcoin-dev
Paper wallets are a safety hazard, insecure, and generally not advisable.

I have to agree with Luke.
And I would also extend those concerns to BIP39 plaintext paper backups.

IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os. 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).


/jonas

[Adam Ritter via bitcoin-dev]

I'm happy to help with secure paper wallet support. Bitcoin core is already
used offline by the Glacier Protocol, though there's no official offline
support.

I extended the Glacier Protocol with an extra password derivation function.
I used Scrypt with 2GB RAM requirement, though maybe using Argon2id V1.3
would be better.

Also I'd prefer using BIP45 Multisig HD Wallets over a multisig address, as
in the current Glacier Protocol implementation the redeem key is public
because of the test withdrawal transaction.

On Sat, Sep 30, 2017 at 6:49 AM, Jonas Schnelli via bitcoin-dev <

Post by Jonas Schnelli via bitcoin-dev

Post by Dan Libby via bitcoin-dev
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].

AFAIK, client implementations such as your proposal are off-topic for this ML.
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.

Post by Dan Libby via bitcoin-dev
Paper wallets are a safety hazard, insecure, and generally not advisable.

I have to agree with Luke.
And I would also extend those concerns to BIP39 plaintext paper backups.
IMO, private keys should be generated and used (signing) on a trusted,
minimal and offline hardware/os. 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).
/jonas
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Dan Libby via bitcoin-dev]

Post by Jonas Schnelli via bitcoin-dev
AFAIK, client implementations such as your proposal are off-topic for this ML.
Better use bitcoin-core-dev (ML or IRC) or Github (bitcoin/bitcoin) for such proposals.

ok, thanks. I will take the proposal there.

Post by Jonas Schnelli via bitcoin-dev
I have to agree with Luke.

thanks for your feedback.

Post by Jonas Schnelli via bitcoin-dev
And I would also extend those concerns to BIP39 plaintext paper backups.
IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os.

uhh.... do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments. Lots of real-world use-cases depend on that today.

So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk. It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.

Further, you mention the word trust. That's the crux of the matter. As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices. Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core? And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?

Post by Jonas Schnelli via bitcoin-dev
Users should have no way to view or export the private keys (expect for
the seed backup).

I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?

(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)

Post by Jonas Schnelli via bitcoin-dev
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).

This is more relevant to an application layer above the 2 RPC calls I
proposed. Encryption could be implemented (or not) by whichever software
calls the proposed RPC apis. And further the APIs can be called for
use-cases beyond just paper wallets.

[Jonas Schnelli via bitcoin-dev]

Post by Dan Libby via bitcoin-dev
uhh.... do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments. Lots of real-world use-cases depend on that today.

The current Bitcoin Core wallet setup is not as ideal as it could be.
An good example is, that the wallet and the full node (the p2p logic on 8333) do share the same process (same memory space).
AFAIK a lot of users use Core in watch-only mode and do the signing offline (offline / through HWWs).
Although, Core has currently no direct support for offline signing (expect the rawtx API which are pretty expert-ish).

The Core development process goes into that direction but it takes time due to the strict and extremely important code quality insurance.

Post by Dan Libby via bitcoin-dev
So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk. It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.

IMO we should make it better not worse.
Paper wallets delude to do address reuse, the spending-procedure is unclear, and very likely insecure.
A quick photo-snapshot by an attack may result in a full compromised key.
Printer buffers, etc. are also something to worry here.

Post by Dan Libby via bitcoin-dev
Further, you mention the word trust. That's the crux of the matter. As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices. Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core? And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?

I think Bitcoin Core does a great job there. But not sure about other security layers are outside of Core.
Especially your operating system.
The reason why we see a growing demand in hardware wallets is probably because people no longer trust in current available operating systems as well as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).

Post by Dan Libby via bitcoin-dev

Post by Jonas Schnelli via bitcoin-dev
Users should have no way to view or export the private keys (expect for
the seed backup).

I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?

Yes. That actually something we are considering (especially if we would allow BIP44 or other HD public key derivation forms).
Also, we heard of "support sessions“ on IRC where attackers told victims they must enter „dumpprivkey“ in the Console and give them the output in order „to fix the problem“.

Post by Dan Libby via bitcoin-dev
(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)

I dislike that as well – in general. But I guess most users like self-protection. Also, the user layer is attackable. If _you_ can access the private-keys, an attacker can do also. What most users want is a key-safe that only signs transactions which they could verify beforehand in a safe environment, and not a way to export private keys or something else that can touch the keys.

Post by Dan Libby via bitcoin-dev

Post by Jonas Schnelli via bitcoin-dev
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?

The answer is probably: No (for now). But working towards this should be the focus.


---
/jonas

[Aymeric Vitte via bitcoin-dev]

By "all of this" I meant the other issues that I mentioned too "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 am extending the
problematic while the very basic concerns are still unsolved

Then I don't agree with the fact that users should not have the control
of their keys, but if I try to summarize, your suggestions probably lead
to the fact that the "wallet" part should be outside of bitcoin-qt, in a
simple offline module (assuming that you can trust the simple sw + the
os + the hw +the cpu, but ok, the pb is the same with a hw wallet),
which I think is a good idea

That's why I made a module some time ago, supposed to be "bitcoin
transactions made simple", you do your transactions offline, check them,
and send them to the network via qt, the web or other, it's working but
is not online on github because unfinished, and unfinished because
nothing is simple and it's unlikely that normal people can use this for
now, unfortunately you need to be a bit online to make your transaction,
fetch the output you want to spend or get the info, then associate the
right key, calculate the fees, that's not simple, that's why it's
different from a standard wallet, but probably a good way

Small sw a bit like a credit card finally, and people know they must not
disclose their code(s) in case they are asked on IRC or elsewhere

Post by Jonas Schnelli via bitcoin-dev

Post by Dan Libby via bitcoin-dev
uhh.... do you apply this logic to the bitcoin-core wallet itself?
because clearly it generates keys and is intended to be used for signing
in online environments. Lots of real-world use-cases depend on that today.

The current Bitcoin Core wallet setup is not as ideal as it could be.
An good example is, that the wallet and the full node (the p2p logic on 8333) do share the same process (same memory space).
AFAIK a lot of users use Core in watch-only mode and do the signing offline (offline / through HWWs).
Although, Core has currently no direct support for offline signing (expect the rawtx API which are pretty expert-ish).
The Core development process goes into that direction but it takes time due to the strict and extremely important code quality insurance.

Post by Dan Libby via bitcoin-dev
So if existing bitcoin-core wallet behavior is "ok" in any context then
how is it any worse for it to generate a key/address that will not be
stored in the internal wallet, and the user may do with it as they wish?
That is all my proposed RPC call does and unlike the existing RPC calls
it never even stores the key or address to disk. It is also useful when
run on an offline hardware device, such as a laptop connected to an
non-networked printer.

IMO we should make it better not worse.
Paper wallets delude to do address reuse, the spending-procedure is unclear, and very likely insecure.
A quick photo-snapshot by an attack may result in a full compromised key.
Printer buffers, etc. are also something to worry here.

Post by Dan Libby via bitcoin-dev
Further, you mention the word trust. That's the crux of the matter. As
a full node operator, I've already placed my trust in the bitcoin-core
developers and dev/release practices. Why exactly should I trust the
software in this minimal offline hardware/os you mention if it is NOT
bitcoin core? And even if open source software, does that not at least
double my workload/expense to audit theat software in addition to
bitcoin-core?

I think Bitcoin Core does a great job there. But not sure about other security layers are outside of Core.
Especially your operating system.
The reason why we see a growing demand in hardware wallets is probably because people no longer trust in current available operating systems as well as current used desktop/laptop CPUs (like Intel wit it’s MME, etc.).

Post by Dan Libby via bitcoin-dev

Post by Jonas Schnelli via bitcoin-dev
Users should have no way to view or export the private keys (expect for
the seed backup).

I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?

Yes. That actually something we are considering (especially if we would allow BIP44 or other HD public key derivation forms).
Also, we heard of "support sessions“ on IRC where attackers told victims they must enter „dumpprivkey“ in the Console and give them the output in order „to fix the problem“.

Post by Dan Libby via bitcoin-dev
(Personally I actively avoid wallet software that takes this view and
treat users like children, preventing individuals direct access to the
keys for their own funds, which disempowers and sometimes results in a
form of lockin)

I dislike that as well – in general. But I guess most users like self-protection. Also, the user layer is attackable. If _you_ can access the private-keys, an attacker can do also. What most users want is a key-safe that only signs transactions which they could verify beforehand in a safe environment, and not a way to export private keys or something else that can touch the keys.

Post by Dan Libby via bitcoin-dev

Post by Jonas Schnelli via bitcoin-dev
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?

The answer is probably: No (for now). But working towards this should be the focus.
---
/jonas
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
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

[Sjors Provoost via bitcoin-dev]

Post by Jonas Schnelli via bitcoin-dev

Paper wallets are a safety hazard, insecure, and generally not advisable.

I have to agree with Luke.
And I would also extend those concerns to BIP39 plaintext paper backups.
IMO, private keys should be generated and used (signing) on a trusted, minimal and offline hardware/os. 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).

I believe BIP39 does an excellent job at reducing the amount of bitcoin permanently lost. Stolen funds can at least in theory be retrieved at some future date. There's a trade-off between having a backup process that is secure and one that people actually use. I don't know the right answer, and tend to agree it's better left to individual wallets to decide.

Sjors

[Aymeric Vitte via bitcoin-dev]

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

Post by Jonas Schnelli via bitcoin-dev
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

Post by Jonas Schnelli via bitcoin-dev
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

Post by Jonas Schnelli via bitcoin-dev
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