path: root/5c/907398145e0ced93af7aae1d6a9af1e1d1685f

Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FE4B3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 23:51:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com
	[209.85.128.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 469A6FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 23:51:55 +0000 (UTC)
Received: by mail-wr0-f182.google.com with SMTP id k62so1695747wrc.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 16:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-language;
	bh=2jtw30zaWNOm+D2cgRt++mk255XG2YSbWbyO3X2pPUM=;
	b=qh7O1DhR3SBUa/TBAT92+4LO+fW3mHy1eOFa8WfJb3KasRDjVTtKzvGiUFbNAgoXiu
	Qg4+PQqybTdOCft7HiW9QbMiwfNnaUdf7dKDq3H7SDtW6vGnPolumMdB43tsbqGOT2na
	soli+dw9p5LQR7hJbDjoRXLVsMrMSSNlQhpYapzXNfC8fgGkaAQ8+9QGJPgY1CuJ/YyV
	rbhDHumR9/1iH0NSRSl8FK+5wYTz5EndQ/F/NkPdygVT42b4+jEtFN6MuCU10Kkco0UD
	bVdi/ORqyB8ZO6ItAIs0BXaEY4fqmg3dSMXnVVhXL+UsfIWzxJ4C4dpLQBEOsjRsoPrA
	Ks6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-language;
	bh=2jtw30zaWNOm+D2cgRt++mk255XG2YSbWbyO3X2pPUM=;
	b=BYeiGOhb9KCmvssOdWoWkDecPUPKgo5nmw+5aMQWTN3OHa7maXK8c/zTrjpEEAWJ30
	kj6Y8FKgx+BrOsRypqwLcwP4utu0YHnSrVwKo7Wr3+632p9IcR2294Yrwm2xU1RyFEr1
	yb9xz9KKYvRRhm1up0M4tMLeZbThKElAidZpn/cq20CbvJvA+La1Xf2p15tXQuQDdDSW
	VEN4S6qPniBS7np5c+qWfxM94oprkkyL+8rb4UgSf3eiZm4xfB9IwFVuoq2WEAX5lJX5
	KmUFQqlcAMPm+81trV1NHFO08KJTv86g3AzChhNdx3Kfz9y3NHzNzZpTIJ7TwEC2IpJz
	/W/A==
X-Gm-Message-State: AHPjjUgnl6f7CQk1GUPXlkRPueCi7+LzwTvegu11xWCoKVDLYrPpfW4s
	W/CpkHvqmRhdWiHndaWlO/CyNw==
X-Google-Smtp-Source: AOwi7QDVGSB9eZ7M9ApUdYETRvo6o0Ta/CTpqFZFxm5RwktwbF2P/pDtKT+RrF4mWQOj6aDWcwt/Cg==
X-Received: by 10.223.156.203 with SMTP id h11mr10136456wre.178.1506815513795; 
	Sat, 30 Sep 2017 16:51:53 -0700 (PDT)
Received: from ?IPv6:2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17?
	([2a01:cb1d:5c:1600:9d6d:71b2:cb71:cb17])
	by smtp.googlemail.com with ESMTPSA id
	b89sm18569135wrd.42.2017.09.30.16.51.52
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 30 Sep 2017 16:51:52 -0700 (PDT)
To: Jonas Schnelli <dev@jonasschnelli.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	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>
	<19DF6343-462D-4C99-A526-B3A5A10E8F37@jonasschnelli.ch>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <0f7f32a1-5d42-292a-bdbd-e57218ef3cbd@gmail.com>
Date: Sun, 1 Oct 2017 01:51:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101
	Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19DF6343-462D-4C99-A526-B3A5A10E8F37@jonasschnelli.ch>
Content-Type: multipart/alternative;
	boundary="------------F0FBFBED2B33961632D23CF7"
Content-Language: fr
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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 23:51:57 -0000

This is a multi-part message in MIME format.
--------------F0FBFBED2B33961632D23CF7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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


--------------F0FBFBED2B33961632D23CF7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>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</p>
    <p>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</p>
    <p>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<br>
    </p>
    <p>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<br>
    </p>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 30/09/2017 à 23:14, Jonas Schnelli
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:19DF6343-462D-4C99-A526-B3A5A10E8F37@jonasschnelli.ch">
      <blockquote type="cite">
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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?
</pre>
      </blockquote>
      <pre wrap="">
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.).

</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">Users should have no way to view or export the private keys (expect for
the seed backup).
</pre>
        </blockquote>
        <pre wrap="">
I suppose that in your view then, dumpprivkey and dumpwallet RPCs should
be removed from bitcoin-core to fit this paradigm?
</pre>
      </blockquote>
      <pre wrap="">
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“.

</pre>
      <blockquote type="cite">
        <pre wrap="">(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)
</pre>
      </blockquote>
      <pre wrap="">
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.


</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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).
</pre>
        </blockquote>
        <pre wrap="">
Is there really nothing existing yet to address all of this?
</pre>
      </blockquote>
      <pre wrap="">
The answer is probably: No (for now). But working towards this should be the focus.


---
/jonas

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
  </body>
</html>

--------------F0FBFBED2B33961632D23CF7--