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

[Dan Libby <dan@osc.co.cr>]

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.