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

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

[Dan Libby]

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.

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

[Andrew Johnson]

[-- Attachment #1: Type: text/plain, Size: 4964 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> 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
>



-- 
Andrew Johnson

[-- Attachment #2: Type: text/html, Size: 6283 bytes --]

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

[Dan Libby]

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.

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

[Sjors Provoost]

[-- Attachment #1.1: Type: text/plain, Size: 5528 bytes --]

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

> Op 29 sep. 2017, om 20:07 heeft Andrew Johnson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
> 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.
> 
> 
> On Fri, Sep 29, 2017 at 12:29 PM, Dan Libby via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 <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
> 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.


[-- Attachment #1.2: Type: text/html, Size: 8146 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dan Libby]

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


    Examples:
    > bitcoin-cli genexternalmultisigaddress 2 3

-----



On 09/29/2017 10:29 AM, 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.

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

[Dan Libby]

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

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

[Dan Libby]

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

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

[Jonas Schnelli]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]


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


> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> 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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Dan Libby]

On 09/29/2017 09:49 PM, Jonas Schnelli wrote:

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

> I have to agree with Luke.

thanks for your feedback.

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

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

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

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

[Jonas Schnelli]

[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]

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

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

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

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

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


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


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aymeric Vitte]

[-- Attachment #1: Type: text/plain, Size: 6405 bytes --]

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



Le 30/09/2017 à 23:14, Jonas Schnelli via bitcoin-dev a écrit :
>> 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.
>
>> 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.
>
>> 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.).
>
>>> 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“.
>
>> (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.
>
>
>>> 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
> bitcoin-dev@lists.linuxfoundation.org
> 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


[-- Attachment #2: Type: text/html, Size: 8677 bytes --]

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

[Sjors Provoost]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]



> Op 30 sep. 2017, om 06:49 heeft Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> 
>> On 09/29/2017 02:03 PM, Luke Dashjr wrote:
>> 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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Adam Ritter]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> 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].
> >
>
> 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.
>
>
> > On 09/29/2017 02:03 PM, Luke Dashjr wrote:
> > 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2638 bytes --]

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

[Aymeric Vitte]

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