Re: [Bitcoin-development] Address Expiration to Prevent Reuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm way late to this one, I guess, but adding some thoughts here... it seems that anything which mitigates the problem of reuse should be to the maximum extent possible, the user's option... if a person wants to have an address that lasts forever they should be able to have it... if they want to have an address that expires they should be able to have it. The reuse problem is, I think, better solved by the presentation of stealth address proposals, and would be handled by a stealth BIP (BIP 63) which has been recently re-discussed here: https://bitcointalk.org/index.php?topic=1083961.0 On 03/26/2015 02:44 PM, Gregory Maxwell wrote: On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@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 - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVe7cJAAoJEGxwq/inSG8C2uwH/2UfTX+6CEssv5ZhiwwqVNWk bmlODZulsJK0FIIcz2oVtMvnMR7L8DX/XtFOdiVTk/wOn7vc7X/DZ9UVKSixKCLJ IJLzBKEzFzMmNhxXv9fPsefuMsMlTkhifykl2BOp0T2gMEr5GweKSqn9XpQuo9mb LhS5vqNCRw0X3eQ5sIalSfmK3ghP5yaU+orhFjvb3QJ/JN3mxgXyl3xLx9diPVdu 2I1QoxzCyE/tlEnxZGPrCtGe3d93mPhEFGGeiP+7eW8TkJa5AGCg3QWbzniC3Nsv gjg6rCbLKtj300hH0glbPT96YO+r9l5itox+aArkCtNnR+/HlUb6zubgqebzPuc= =KZQe -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
Indeed, and with things like BIP32 it would be pointless to use one address, and I agree it is silly to reuse addresses, some for the privacy aspect, some for the revealing the pubkey on a spend aspect. But just because it is silly, doesn't mean it's necessarily required for devs to disallow it. I mean if a business doesn't care who can see their bitcoin takings and they are willing to keep shifting the bitcoin and live woth the exposed pubkey let them yea? http://www.forexminute.com/bitcoin/australian-association-asks-voluntary-bitcoin-register-individuals-companies-51183 From: Gregory Maxwellmailto:gmaxw...@gmail.com Sent: 27/03/2015 2:13 PM To: Thy Shizzlemailto:thyshiz...@outlook.com Cc: s...@sky-ip.orgmailto:s...@sky-ip.org; Tom Hardingmailto:t...@thinlink.com; Bitcoin Developmentmailto:bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote: 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 :( I hope you're mistaken, because that would be a serious attack on the design of bitcoin, which obtains privacy and fungibility, both essential properties of any money like good, almost exclusively through avoiding reuse. [What business would use a money where all their competition can see their sales and identify their customers, where their customers can track their margins and suppliers? What individuals would use a system where their inlaws could criticize their spending? Where their landlord knows they got a raise, or where thieves know their net worth?] Though no one here is currently suggesting blocking reuse as a network rule, the reasonable and expected response to what you're suggesting would be to do so. If some community wishes to choose not to use Bitcoin, great, but they don't get to simply choose to screw up its utility for all the other users. You should advise this country specific bitcoin group that they shouldn't speak for the users of a system which they clearly do not understand. -- 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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote: 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 :( I hope you're mistaken, because that would be a serious attack on the design of bitcoin, which obtains privacy and fungibility, both essential properties of any money like good, almost exclusively through avoiding reuse. [What business would use a money where all their competition can see their sales and identify their customers, where their customers can track their margins and suppliers? What individuals would use a system where their inlaws could criticize their spending? Where their landlord knows they got a raise, or where thieves know their net worth?] Though no one here is currently suggesting blocking reuse as a network rule, the reasonable and expected response to what you're suggesting would be to do so. If some community wishes to choose not to use Bitcoin, great, but they don't get to simply choose to screw up its utility for all the other users. You should advise this country specific bitcoin group that they shouldn't speak for the users of a system which they clearly do not understand. -- 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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding t...@thinlink.com wrote: I addressed that by limiting the duplicate check to an X-block segment. X is hard-coded in this simple scheme (X=144 = 1-day addresses). You could picture a selectable expiration duration too. If its to be heuristic in any case why not make it a client feature instead of a consensus rule? If someone wants to bypass anything they always can, thats what I mean by hide their payment under a rock E.g. I can take your pubkey, add G to it (adding 1 to the private key), strip off the time limits, and send the funds. What do you mean I didn't pay you? I wrote a check. locked it in a safe, and burred it in your back garden. The answer to this can only be that payment is only tendered when its made _exactly_ to the payee's specifications. If someone violates the specifications all they're doing is destroying coins. Nothing can stop people from destroying coins... 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. -- 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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@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
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 t...@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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Thu, Mar 26, 2015 at 10:28 PM, s7r s...@sky-ip.org wrote: This should not be enforced by default. No one suggested _anything_ like that. Please save the concern for someplace its actually applicable. I know it's not recommended to use the same pubkey more than once, but the protocol was not designed this way. For a point of pedantry, the protocol actually was designed that way and in the initial versions of the software there was actually no user exposed mechanism to reuse a scriptPubkey no matter how hard you tried. -- 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
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Tuesday, 24 March 2015, at 6:57 pm, Tom Harding wrote: It appears that a limited-lifetime address, such as the fanciful address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366 where 349366 is the last valid block for a transaction paying this address, could be made reuse-proof with bounded resource requirements, The core devs seem not to like ideas such as this because a transaction that was once valid can become invalid due to a chain reorganization. -- 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
