summaryrefslogtreecommitdiff
path: root/b7/dfe3f21fa00eb3dd19502c642b68e764bc23a4
blob: 945740e497d418856b089dc2b285b85d83a7f088 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <roy@gnomon.org.uk>) id 1UKF3s-0005ko-Hh
	for bitcoin-development@lists.sourceforge.net;
	Mon, 25 Mar 2013 21:36:12 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gnomon.org.uk
	designates 93.93.131.22 as permitted sender)
	client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
	helo=darla.gnomon.org.uk; 
Received: from darla.gnomon.org.uk ([93.93.131.22])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1UKF3q-00005D-IZ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 25 Mar 2013 21:36:12 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
	by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r2PLZk1v081670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 25 Mar 2013 21:35:51 GMT (envelope-from roy@darla.gnomon.org.uk)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk
Received: (from roy@localhost)
	by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r2PLZjmH081669;
	Mon, 25 Mar 2013 21:35:45 GMT (envelope-from roy)
Date: Mon, 25 Mar 2013 21:35:45 +0000
From: Roy Badami <roy@gnomon.org.uk>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20130325213545.GE65880@giles.gnomon.org.uk>
References: <20130222230851.GO2030@giles.gnomon.org.uk>
	<20130225172353.GA7782@malakian.dd-wrt>
	<20130325204911.GD65880@giles.gnomon.org.uk>
	<CAAS2fgQSMvCwmeoFSJUyrcikj0wV_r_hLRDrE_v5sA4xt48PDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgQSMvCwmeoFSJUyrcikj0wV_r_hLRDrE_v5sA4xt48PDQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -2.8 (--)
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 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1UKF3q-00005D-IZ
Cc: bitcoin-development@lists.sourceforge.net, Andrew Poelstra <asp11@sfu.ca>
Subject: Re: [Bitcoin-development] Key retirement and key compromise
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: Mon, 25 Mar 2013 21:36:12 -0000

On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:
> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami <roy@gnomon.org.uk> wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> > Although to be useful such a protocol would have to be pretty much
> > universally implemented by clients.
> 
> That is quite drastic enough, as it requires adding more perpetual
> data that must remain in fast lookup for all validating nodes (the set
> of revoked 'addresses').

Maybe it should be possible for addresses to contain expiry dates, so
that revocation lists don't need to hang around forever.

> Keep in mind that this is only improvement for what is a usually
> inadvisable usage of Bitcoin to begin with... you should not be
> reusing addresses.

It may be inadvisable but in many cases it is pretty much unavoidable
as Bitcoin stands today.  Granted, the payment protocol will help with
that in many use cases...

roy