š
Original date posted:2015-03-26
š Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
s7r [ARCHIVE] /
npub1j3ā¦cwg9h
2023-06-07 15:32:15
in reply to nevent1qā¦w0qv
Author Public Key
npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9hPublished at
2023-06-07 15:32:15Event JSON
{
"id": "a830f3ad34ee38ab66f31e4d48360360a97cd84cacfe782eb2ca6353330a06b3",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686151935,
"kind": 1,
"tags": [
[
"e",
"13ba2dac7eec5154e8f99682c168a8cede79e5ef5e0b1fe726762657ed73749d",
"",
"root"
],
[
"e",
"20923e218d5ce3ec804c9401c6c4629ac1326082ead1492e577d14c5990da14f",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "š
Original date posted:2015-03-26\nš Original message:This should not be enforced by default. There are some use cases where\naddress re-use is justified (a donation address spread on multiple\nstatic pages or even printed on papers/books?). For example, I offer\nsome services on the internet for free, and I only have a bitcoin\naddress for donations which is posted everywhere. Obviously this could\npossibly harm privacy, but not everyone who uses bitcoin wants to keep\nall transactions private. To the contrary, there are accounting cases\nwhen you need to archive all keys, hashes of transactions and\neverything (for example when using btc inside a company which is\nrequired by law to keep accounting registries).\n\nI know it's not recommended to use the same pubkey more than once, but\nthe protocol was not designed this way. Enforcing something as\ndescribed in this topic will undermine an user's rights to re-use his\naddresses, if a certain situation requires it.\n\nOn 3/26/2015 11:44 PM, Gregory Maxwell wrote:\n\u003e On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding \u003ctomh at thinlink.com\u003e \n\u003e wrote:\n\u003e\u003e I should have been clearer that the motivation for address \n\u003e\u003e expiration is to reduce the rate of increase of the massive pile \n\u003e\u003e of bitcoin addresses out there which have to be monitored\n\u003e\u003e forever for future payments. It could make a significant dent\n\u003e\u003e if something like this worked, and were used by default someday.\n\u003e \n\u003e Great, that can be accomplished by simply encoding an expiration \n\u003e into the address people are using and specifying that clients \n\u003e enforce it.\n\u003e \n\u003e ----------------------------------------------------------------------\n--------\n\u003e\n\u003e\n\u003e \nDive into the World of Parallel Programming The Go Parallel Website,\nsponsored\n\u003e by Intel and developed in partnership with Slashdot Media, is your \n\u003e hub for all things parallel software development, from weekly \n\u003e thought leadership blogs to news, videos, case studies, tutorials \n\u003e and more. Take a look and join the conversation now. \n\u003e http://goparallel.sourceforge.net/ \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net \n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "fee7efcc94c8606022325cfed442ea0cf9cd72f0f7370a3a7db1ba0aeb7351e547f835c008c585d073541296b5df9c9a90456f5c4360e3ece72ed9286b2025d9"
}