From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-Id: <19DF6343-462D-4C99-A526-B3A5A10E8F37@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5C4E2050-A438-4E4D-8A4E-1CEED51744F7";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 30 Sep 2017 14:14:44 -0700
In-Reply-To: <05caf783-cba2-b37a-0f28-2d0020386279@osc.co.cr>
To: Dan Libby <dan@osc.co.cr>
References: <e43c6e06-0bdc-360e-eb5c-a3726e4f0fc8@osc.co.cr>
	<96328209-9249-44BC-957A-4EF8DE014E2D@jonasschnelli.ch>
	<05caf783-cba2-b37a-0f28-2d0020386279@osc.co.cr>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
Precedence: list


--Apple-Mail=_5C4E2050-A438-4E4D-8A4E-1CEED51744F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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

>=20
> 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=E2=80=99s =
MME, etc.).

>=20
>> Users should have no way to view or export the private keys (expect =
for
>> the seed backup).
>=20
> 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=E2=80=9C on IRC where attackers told =
victims they must enter =E2=80=9Edumpprivkey=E2=80=9C in the Console and =
give them the output in order =E2=80=9Eto fix the problem=E2=80=9C.

> (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 =E2=80=93 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).
>=20
> 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


--Apple-Mail=_5C4E2050-A438-4E4D-8A4E-1CEED51744F7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlnQCUQACgkQHrd2uwPH
ki0pDQ/6Auc67iHoPgx5UNQU5peWJxPnMFsL37G8bE6sq476nzMZ9Vs8Q0GkJX/1
b4Y5KO3mSCLL6XKzdo57qODQc1918JWxD2FFQ3SWKFY6fFsaYYkgpVLPIURTq8bu
I3zrsQohRboFQwpgYD0swLLF4V33WdQbCvW+n26CA7qPg20VqHwJwO01UtCYklQF
7abGaR+gc5hSWKOLz1gz4juq5nBJfkmRg+sNZsjKT35dwfB3UQtVzvKotYxOaGDj
vLEmRkMBSQMwZ3G8aWxFCB/d80EG6oCbcrTJaVf7/pYIimAmKf14J1TbFP1m4aq1
Xi7WNp2V0N1MrxqFYrozFnTrEbq1pirp00VeEQ+AGKh4+9z46bLcvdDAFYGeHM6l
UVSKVySObITsKIIp+qNHB//Nsaro+fCIzPB87Q9++8pD//2S6NYtUPqApVnKPDfV
74Sc8EyMazwKSM6zc5tKM0hgGNkTH3SRcomxp1WxMhqrjhqQtESka+oM5kj15/sa
1vio3le9zfHPAH4D/efmUjnJ4bHiM9W3TrYUfwjuSMQNDJqr9Y/qTuE7tI7eeLmZ
Hzavc5ERjBJBe7zaS/iJ5qMeymClZEtdGc+9s7fwqoaPCNvguIRWbOniVdvBf4q8
aKyKEg8Gopans4UbbPrgqtY3j8KPh3ADLWhyFDjN+ja0p365NEs=
=BVoM
-----END PGP SIGNATURE-----

--Apple-Mail=_5C4E2050-A438-4E4D-8A4E-1CEED51744F7--