From: Peter Todd <pete@petertodd•org>
To: Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
Date: Thu, 26 Mar 2015 14:33:15 -0700 [thread overview]
Message-ID: <20150326213315.GA9362@muck> (raw)
In-Reply-To: <551479A3.9010104@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-03-26 21:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 1:57 Tom Harding
2015-03-25 10:09 ` Matt Whitlock
2015-03-25 16:34 ` Gregory Maxwell
2015-03-25 18:44 ` Tom Harding
2015-03-25 19:22 ` Gregory Maxwell
2015-03-26 20:38 ` Tom Harding
2015-03-26 20:42 ` Gregory Maxwell
2015-03-26 21:26 ` Tom Harding
2015-03-26 21:33 ` Peter Todd [this message]
2015-03-26 21:44 ` Gregory Maxwell
2015-03-26 22:23 ` Tom Harding
2015-03-26 22:28 ` s7r
2015-03-26 23:00 ` Gregory Maxwell
2015-06-13 4:52 ` odinn
2015-03-27 1:51 Thy Shizzle
2015-03-27 3:13 ` Gregory Maxwell
2015-03-27 4:31 Thy Shizzle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150326213315.GA9362@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tomh@thinlink$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox