From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YbJRH-0001VN-KG for bitcoin-development@lists.sourceforge.net; Fri, 27 Mar 2015 01:51:59 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of outlook.com designates 65.54.190.210 as permitted sender) client-ip=65.54.190.210; envelope-from=thyshizzle@outlook.com; helo=BAY004-OMC4S8.hotmail.com; Received: from bay004-omc4s8.hotmail.com ([65.54.190.210]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YbJRF-0001J6-QX for bitcoin-development@lists.sourceforge.net; Fri, 27 Mar 2015 01:51:59 +0000 Received: from BAY403-EAS383 ([65.54.190.199]) by BAY004-OMC4S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 26 Mar 2015 18:51:52 -0700 X-TMN: [m21QdvbwpKMpbf9DkSnGzyrV9OHsYbaH] X-Originating-Email: [thyshizzle@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_967b8518-997e-4cec-a737-a9560f8581db_" MIME-Version: 1.0 To: , Gregory Maxwell , Tom Harding From: Thy Shizzle Date: Fri, 27 Mar 2015 12:51:46 +1100 X-OriginalArrivalTime: 27 Mar 2015 01:51:52.0399 (UTC) FILETIME=[98BD0DF0:01D06830] X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (thyshizzle[at]outlook.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [65.54.190.210 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails X-Headers-End: 1YbJRF-0001J6-QX 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: Fri, 27 Mar 2015 01:51:59 -0000 --_967b8518-997e-4cec-a737-a9560f8581db_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes I agree=2C also there is talks about a government body I know of warmin= g to bitcoin by issuing addresses for use by a business and then all transa= ctions 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 Sent: =E2=80=8E27/=E2=80=8E03/=E2=80=8E2015 9:29 AM To: Gregory Maxwell=3B Tom Harding Cc: Bitcoin Development 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=2C I offer some services on the internet for free=2C and I only have a bitcoin address for donations which is posted everywhere. Obviously this could possibly harm privacy=2C but not everyone who uses bitcoin wants to keep all transactions private. To the contrary=2C there are accounting cases when you need to archive all keys=2C 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=2C 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=2C if a certain situation requires it. On 3/26/2015 11:44 PM=2C Gregory Maxwell wrote: > On Thu=2C Mar 26=2C 2015 at 9:26 PM=2C 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=2C and were used by default someday. > > Great=2C 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=2C sponsored > by Intel and developed in partnership with Slashdot Media=2C is your > hub for all things parallel software development=2C from weekly > thought leadership blogs to news=2C videos=2C case studies=2C 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=2C spon= sored by Intel and developed in partnership with Slashdot Media=2C is your hub fo= r all things parallel software development=2C from weekly thought leadership blog= s to news=2C videos=2C case studies=2C 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 --_967b8518-997e-4cec-a737-a9560f8581db_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes = I agree=2C 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 transactio= ns 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
Sent: =E2=80=8E27/=E2=80=8E03/=E2=80=8E2015 9:29 AM
To: Gregory Maxwell=3B Tom Harding
Cc: Bitcoin D= evelopment
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=2C I offer
some services on the internet for free=2C and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy=2C but not everyone who uses bitcoin wants to keep all transactions private. To the contrary=2C there are accounting cases
when you need to archive all keys=2C 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=2C 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=2C if a certain situation requires it.

On 3/26/2015 11:44 PM=2C Gregory Maxwell wrote:
>=3B On Thu=2C Mar 26=2C 2015 at 9:26 PM=2C Tom Harding <=3Btomh@thinli= nk.com>=3B
>=3B wrote:
>=3B>=3B I should have been clearer that the motivation for address >=3B>=3B expiration is to reduce the rate of increase of the massive pi= le
>=3B>=3B of bitcoin addresses out there which have to be monitored
>=3B>=3B forever for future payments. =3B It could make a significa= nt dent
>=3B>=3B if something like this worked=2C and were used by default some= day.
>=3B
>=3B Great=2C that can be accomplished by simply encoding an expiration <= br> >=3B into the address people are using and specifying that clients
>=3B enforce it.
>=3B
>=3B --------------------------------------------------------------------= --
--------
>=3B
>=3B
>=3B
Dive into the World of Parallel Programming The Go Parallel Website=2C
sponsored
>=3B by Intel and developed in partnership with Slashdot Media=2C is your=
>=3B hub for all things parallel software development=2C from weekly
>=3B thought leadership blogs to news=2C videos=2C case studies=2C tutori= als
>=3B and more. Take a look and join the conversation now.
>=3B http://goparallel.sou= rceforge.net/
>=3B _______________________________________________
>=3B Bitcoin-development mailing list
>=3B Bitcoin-development@lists.sourceforge.net
>=3B https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=3B

---------------------------------------------------------------------------= ---
Dive into the World of Parallel Programming The Go Parallel Website=2C spon= sored
by Intel and developed in partnership with Slashdot Media=2C is your hub fo= r all
things parallel software development=2C from weekly thought leadership blog= s to
news=2C videos=2C case studies=2C tutorials and more. Take a look and join = the
conversation now. http://gop= arallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--_967b8518-997e-4cec-a737-a9560f8581db_--