On Thu, Mar 26, 2015 at 02:26:59PM -0700, Tom Harding wrote:
> 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.

Again, along the lines of what Gregory Maxwell is saying, if the payment
instructions you have given to the sender say "don't make funds
spendable with scriptPubKey after this date" why are you scanning those
"old" bitcoin addresses for future payments? That makes no more sense
than taking your p2pkh addresses and scanning for the same scriptPubKey
embedded within a p2sh address - you haven't told anyone to pay you via
that method so why expect anyone to do so?

> 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.

The sender is free to bury their Bitcoins in a safe in your neighbors
front yard; you have no reason to accept such silly behavior as payment
and every reason to ignore it.

-- 
'peter'[:-1]@petertodd.org
00000000000000000b48023e9c98038c50b9a2044975bbdf9f43313400a156b6