Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YbGC1-0001uu-PL for bitcoin-development@lists.sourceforge.net; Thu, 26 Mar 2015 22:24:01 +0000 X-ACL-Warn: Received: from mail-pd0-f177.google.com ([209.85.192.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YbGBz-0004no-Qp for bitcoin-development@lists.sourceforge.net; Thu, 26 Mar 2015 22:24:01 +0000 Received: by pdbop1 with SMTP id op1so75974656pdb.2 for ; Thu, 26 Mar 2015 15:23:53 -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=P/SMrYQ8pUEl8vq/A1YRsmzjfRJ29yg4DAtcwvOXJWY=; b=kaMuLLBGWQu51BIbiir+jdzTgK3Y7o9re8ZI2ZcLwAvaW+CiaAeA4cZEiYte3HOXfY tZ/dSTfKHlpk3GCIOv6iArutre03irPE9T+uGcq7t7akhMOTMRd8QuK06xVkI3U/r7VG 9HVn9Bo1v//2IeGNN7Yd39zK1L61NRX9n6ILbHlul/dSoJA6qv2XWH/87hRYrxGYiIej S+O6ps5g5TniGPnRen9Yp3lgNlevWyyVHUT4SBsDJ0gpZzN8h/ZCVKZ6hATg2+37hOKJ ngu8rL5IWTxwzm/PSBEzvyvZ23jYnWVtBqIp+AmDIgpbg+Vo2UYlwGM0ObP4beFN9+Xt /AMQ== X-Gm-Message-State: ALoCoQnpN9stlVm9ZrLAciPbjdyiPW1dPq3mr6VW9AtZM7mchrg8lHa4nRGIfO/G5lBcYOlUZtX8 X-Received: by 10.66.182.201 with SMTP id eg9mr25116920pac.68.1427408633894; Thu, 26 Mar 2015 15:23:53 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by mx.google.com with ESMTPSA id rj6sm63923pbc.62.2015.03.26.15.23.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 15:23:53 -0700 (PDT) Message-ID: <551486DC.4080700@thinlink.com> Date: Thu, 26 Mar 2015 15:23:24 -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> <551479A3.9010104@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: 1YbGBz-0004no-Qp 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 22:24:01 -0000 On 3/26/2015 2:44 PM, Gregory Maxwell wrote: > On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding wrote: >> 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. > Great, that can be accomplished by simply encoding an expiration into > the address people are using and specifying that clients enforce it. Another way to look at it: is the benefit of the bitcoin network providing this service sufficiently greater than the cost? The main cost is that a reorganization has a chance of invalidating a payment made at or just before expiration (if the payment isn't early enough in the new chain). Would that increase recommended confirmations above their current levels, which are centered around the possibility of a malicious double-spend? Unclear to me.