Message-ID: <551479A3.9010104@thinlink.com>
Date: Thu, 26 Mar 2015 14:26:59 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <55121611.1030104@thinlink.com>	<CAAS2fgRzskGcHjEhJLnyu-VMTR49i-Wo9TbOOqkHqEasxuO71A@mail.gmail.com>	<551301F0.9020806@thinlink.com>	<CAAS2fgQMW+Htqu0wonL7r-ZN_t0evRayDCGRMKYzRUaCm6wxjw@mail.gmail.com>	<55146E2C.9020105@thinlink.com>
	<CAAS2fgSSOQi4uL95S=GUdXGKZK_y4aNTUoOqkkaLFvzAVPnRig@mail.gmail.com>
In-Reply-To: <CAAS2fgSSOQi4uL95S=GUdXGKZK_y4aNTUoOqkkaLFvzAVPnRig@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
Precedence: list

On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> Which is why a simpler, safer, client enforced behavior is probably
> preferable. Someone who wants to go hack their client to make a
> payment that isn't according to the payee will have to live with the
> results, esp. as we can't prevent that in a strong sense.

I should have been clearer that the motivation for address expiration is 
to reduce the rate of increase of the massive pile of bitcoin addresses 
out there which have to be monitored forever for future payments.  It 
could make a significant dent if something like this worked, and were 
used by default someday.

Address expiration is not an enhancement to the payment experience and 
it doesn't stop sender from doing something weird.  Hacking a new 
address for the recipient would be just as weird as hacking their client 
IMHO.