From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YbFJQ-0007S9-1s for bitcoin-development@lists.sourceforge.net; Thu, 26 Mar 2015 21:27:36 +0000 X-ACL-Warn: Received: from mail-pd0-f178.google.com ([209.85.192.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YbFJP-0007TE-2b for bitcoin-development@lists.sourceforge.net; Thu, 26 Mar 2015 21:27:36 +0000 Received: by pdbcz9 with SMTP id cz9so74686815pdb.3 for ; Thu, 26 Mar 2015 14:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kTYftPDUnNIJ6gdKyxbFVH7AE9bOQLvsggc7vbSHHEs=; b=GIc9/oHEALZE1ayqiHNEUdZoek8BQuXBsrDsK5W65t6vbPwdxJn441c8Cnr5TdspPF BNlnUCMvye/I5GM4p0Xj9ZBVEBM07+xo6UPuguwYkT+nbG+oqbXJlsjUX+Torfr5befQ /hlmUaL9UoCNdT9nsz5/6myd9pDJIFaX8dSBZERX2DdwG1+ay22VhrcRK82KSwk/DcBx sa01Gqve9B/tBHuDb6QWlauiPywoZ3rTot+R1k6PJqCNWcNz0lW8JeP9jDGjtbSxAbu/ q3+5O3BCrSTvE1DH32S7qL19N09uhwJggHabaK75i5AEhdKK1dqukzZkSK0yXLvr3Ihz yDYQ== X-Gm-Message-State: ALoCoQmGK4TEhmzwLuzPzUhNqW15Ixrill7m+AFGdAYbACGjdEK1JjIgfbsFvxLA7XqxTHmo5vHt X-Received: by 10.70.102.38 with SMTP id fl6mr2997966pdb.154.1427405248645; Thu, 26 Mar 2015 14:27:28 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by mx.google.com with ESMTPSA id fr13sm6555769pdb.55.2015.03.26.14.27.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 14:27:27 -0700 (PDT) Message-ID: <551479A3.9010104@thinlink.com> Date: Thu, 26 Mar 2015 14:26:59 -0700 From: Tom Harding 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 References: <55121611.1030104@thinlink.com> <551301F0.9020806@thinlink.com> <55146E2C.9020105@thinlink.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [204.58.254.99 listed in dnsbl.sorbs.net] X-Headers-End: 1YbFJP-0007TE-2b Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse 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: Thu, 26 Mar 2015 21:27:36 -0000 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.