path: root/98/c8583895b035b24a273b3e3f170daa33d42350

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CFD63EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 21:15:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
	[138.201.55.219])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3A69A43A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 21:15:02 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
	id 701DF15E15F3; Sat, 30 Sep 2017 23:15:01 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=RP_MATCHES_RCVD
	autolearn=disabled version=3.3.1
Received: from [10.0.1.11] (unknown [216.169.76.84])
	by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 97EE115E043F;
	Sat, 30 Sep 2017 23:15:00 +0200 (CEST)
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>
X-Mailer: Apple Mail (2.3273)
X-Virus-Scanned: clamav-milter 0.99.2 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Paper Wallet support in bitcoin-core
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Sep 2017 21:15:03 -0000


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