From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UKEKm-0005y9-St for bitcoin-development@lists.sourceforge.net; Mon, 25 Mar 2013 20:49:36 +0000 Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1UKEKk-0007Pq-LG for bitcoin-development@lists.sourceforge.net; Mon, 25 Mar 2013 20:49:36 +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 r2PKnCUJ081186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Mar 2013 20:49:17 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 r2PKnCkW081185; Mon, 25 Mar 2013 20:49:12 GMT (envelope-from roy) Date: Mon, 25 Mar 2013 20:49:11 +0000 From: Roy Badami To: Andrew Poelstra Message-ID: <20130325204911.GD65880@giles.gnomon.org.uk> References: <20130222230851.GO2030@giles.gnomon.org.uk> <20130225172353.GA7782@malakian.dd-wrt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130225172353.GA7782@malakian.dd-wrt> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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: 1UKEKk-0007Pq-LG Cc: bitcoin-development@lists.sourceforge.net 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:49:37 -0000 On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote: > What would be really nice is for bitcoin to have a big key compromise > button, which would automatically transfer all coins to newly > generated addresses (optionally with a pause between generation and > transaction - to allow for a new wallet backup). Optionally, too, the > compromised/retired addresses could be marked with a flag such that if > someone sends coins to that address bitcoind immediately generates a > transaction to transfer the coins to address(es) which are good. On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote: > The problem with automatic transactions would be: by repeatedly sending > money to an address and seeing if it always moves quickly, an attacker > can identify (a) that an address is in use, (b) which public key it has > (if this isn't already public), and (c) that the key is believed to be > compromised. I realise on reflection that what I really want is not automatic transmissions, but a means to revoke an address. The problem is that after transfering the coins from the compromised addresses to a new, hopefully safe address, what to do about the fact that third parties might still try to send me coins to an old, compromised address. So what I think I'm suggesting is that there should be an address revocation protocol, such that clients will give an error if their user tries to send coins to a revoked address. Unless we think that direct payments to addresses will become completely obsolete once the payment protocol is in use, in which case (maybe) this functionality belongs in the payment protocol instead - but I remain unconvinced of that. 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. Thoughts? roy