public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Thy Shizzle <thyshizzle@outlook•com>
To: <s7r@sky-ip•org>, Gregory Maxwell <gmaxwell@gmail•com>,
	Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
Date: Fri, 27 Mar 2015 12:51:46 +1100	[thread overview]
Message-ID: <BAY403-EAS3839ED2940DD1447E1C0277C2090@phx.gbl> (raw)

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

Yes I agree, also there is talks about a government body I know of warming to bitcoin by issuing addresses for use by a business and then all transactions can be tracked for that business entity. This is one proposal I saw put forward by a country specific bitcoin group to their government and so not allowing address reuse would neuter that :(
________________________________
From: s7r<mailto:s7r@sky-ip•org>
Sent: ‎27/‎03/‎2015 9:29 AM
To: Gregory Maxwell<mailto:gmaxwell@gmail•com>; Tom Harding<mailto:tomh@thinlink•com>
Cc: Bitcoin Development<mailto:bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse

This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).

I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.

On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com>
> 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.
>
> ----------------------------------------------------------------------
--------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 5302 bytes --]

             reply	other threads:[~2015-03-27  1:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-27  1:51 Thy Shizzle [this message]
2015-03-27  3:13 ` Gregory Maxwell
  -- strict thread matches above, loose matches on Subject: below --
2015-03-27  4:31 Thy Shizzle
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
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

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=BAY403-EAS3839ED2940DD1447E1C0277C2090@phx.gbl \
    --to=thyshizzle@outlook$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gmaxwell@gmail$(echo .)com \
    --cc=s7r@sky-ip$(echo .)org \
    --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