summaryrefslogtreecommitdiff
path: root/ec/fff7ab8a51c43ad2114f047f50e0523b479f77
blob: 11a61ad5945fdb9980e0153ffaeeefe169353380 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <kanzure@gmail.com>) id 1YW8TS-000726-RP
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 19:08:50 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.48 as permitted sender)
	client-ip=209.85.218.48; envelope-from=kanzure@gmail.com;
	helo=mail-oi0-f48.google.com; 
Received: from mail-oi0-f48.google.com ([209.85.218.48])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YW8TR-0006uu-43
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 19:08:50 +0000
Received: by oiba3 with SMTP id a3so4974827oib.0
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 12 Mar 2015 12:08:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.120.3 with SMTP id ky3mr374799obb.33.1426187323713; Thu,
	12 Mar 2015 12:08:43 -0700 (PDT)
Received: by 10.60.60.41 with HTTP; Thu, 12 Mar 2015 12:08:43 -0700 (PDT)
In-Reply-To: <CAAS2fgSesKYwn1B=o1uxXG7hkGKF8f5e0jZ1eRWQpMSkMBp1EA@mail.gmail.com>
References: <54F32EED.6040103@electrum.org>
	<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
	<550057FD.6030402@electrum.org>
	<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
	<1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com>
	<CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com>
	<CAAS2fgRuBwn6HXeZeth+x-R8DAdsVZmYy4nMA3kN+oJaURftgw@mail.gmail.com>
	<CACq0ZD64rZAQs1mWQdwgx1WJq2btAVs3GbegPpkO-Wh49SoGeA@mail.gmail.com>
	<CANEZrP3ri6QDqomWKMnLqj_ZJxVDOY4QRvWa=L4RzdKFzz+WsQ@mail.gmail.com>
	<5500D4C3.4090207@niftybox.net>
	<CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com>
	<5500FCDA.8050407@niftybox.net>
	<CAAS2fgSesKYwn1B=o1uxXG7hkGKF8f5e0jZ1eRWQpMSkMBp1EA@mail.gmail.com>
Date: Thu, 12 Mar 2015 14:08:43 -0500
Message-ID: <CABaSBaw6v=1Oz=G3d6SN2e_1P4bkn9qN0p85oT3kgYedmfanhw@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>, Bryan Bishop <kanzure@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(kanzure[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YW8TR-0006uu-43
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 19:08:50 -0000

On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> For an emergency transition the user is probably better off with an
> explicit unstructured mass private key export, and a sweep function;
> and guaranteeing compatibility with that is much easier; and because
> it moves funds in one direction there is much less chance of going
> from secure to insecure.

I haven't looked at the existing sweep implementations, but it would
be unfortunate if sweep functions were not available that create at
least the same number of keys, or possibly more, for the purposes of
sweeping. I suppose there are different levels of emergency, where
perhaps you want to sweep all at once in a single transaction and lose
out on (already nebulous) privacy benefits. I say nebulous because
broadcasting a bunch of transactions all at the same time during the
sweep can compromise privacy even when the transactions have no common
ancestor outputs.

- Bryan
http://heybryan.org/
1 512 203 0507