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 > 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 Maxwell<mailto:gmaxw...@gmail.com> Sent: 27/03/2015 2:13 PM To: Thy Shizzle<mailto:thyshiz...@outlook.com> Cc: s...@sky-ip.org<mailto:s...@sky-ip.org>; Tom Harding<mailto:t...@thinlink.com>; Bitcoin Development<mailto: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 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 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
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:s...@sky-ip.org> Sent: 27/03/2015 9:29 AM To: Gregory Maxwell<mailto:gmaxw...@gmail.com>; Tom Harding<mailto:t...@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 > 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 -- 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 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
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 > 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 3/26/2015 2:44 PM, Gregory Maxwell wrote: > On Thu, Mar 26, 2015 at 9:26 PM, 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, 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. Another way to look at it: is the benefit of the bitcoin network providing this service sufficiently greater than the cost? The main cost is that a reorganization has a chance of invalidating a payment made at or just before expiration (if the payment isn't early enough in the new chain). Would that increase recommended confirmations above their current levels, which are centered around the possibility of a malicious double-spend? Unclear to me. -- 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 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
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 0b48023e9c98038c50b9a2044975bbdf9f43313400a156b6 signature.asc Description: Digital signature -- 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 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. 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. -- 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 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 3/25/2015 12:22 PM, Gregory Maxwell wrote: > > Verification with duplicate elimination requires O(N) storage (with N > being the length of the history), since you need to track all the > duplicates to reject. > 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. -- 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 Wed, Mar 25, 2015 at 6:44 PM, Tom Harding wrote: > Is this assuming payment protocol? A major benefit of address > expiration, if it works, would be that it works without requiring > payment protocol. Not at all. > Are you suggesting there is no implementation of address expiration that > wouldn't allow the string to be trivially changed by the sender? The sender is always able to intentionally hide their payment under a rock-- There is no encoding that can prevent that. The defense against that is to not accept payments not made according to the payees specification. > I don't understand, explanation would be appreciated. To reject reused scriptPubKeys you must remember past scriptPubkeys in order to test against them. For illustration purposes imagine a bitcoin system where there is only a single base unit available for trade. Verification of that chain requires O(1) storage (the identity of the current chain tip, and the identity of the spendable coin.). Verification with duplicate elimination requires O(N) storage (with N being the length of the history), since you need to track all the duplicates to reject. (The same is true for actual Bitcoin as well, though the constant factors make the difference somewhat less stark.) -- 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 3/25/2015 9:34 AM, Gregory Maxwell wrote: > >> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366 > Assuming the sender is not an uncooperative idiot, you can simply > include expiration information and the sender can refuse to send after > that time. Is this assuming payment protocol? A major benefit of address expiration, if it works, would be that it works without requiring payment protocol. > If the sender is an uncooperative idiot, they can always change your > target and send anyways. Are you suggesting there is no implementation of address expiration that wouldn't allow the string to be trivially changed by the sender? >> Block containing tx invalid if a prior confirmed tx has paid address > Requires a unprunable verification state. I don't understand, explanation would be appreciated. -- 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 Wed, Mar 25, 2015 at 1:57 AM, Tom Harding wrote: > The idea of limited-lifetime addresses was discussed on 2014-07-15 in > > http://thread.gmane.org/gmane.comp.bitcoin.devel/5837 > > It appears that a limited-lifetime address, such as the fanciful > > address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366 Assuming the sender is not an uncooperative idiot, you can simply include expiration information and the sender can refuse to send after that time. If the sender is an uncooperative idiot, they can always change your target and send anyways. This would seem to work nearly as well as the non-reorg safe network impacting version, and yet has no cost beyond the extra size is communicating the limit. > Block containing tx invalid if a prior confirmed tx has paid address Requires a unprunable verification state. -- 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
[Bitcoin-development] Address Expiration to Prevent Reuse
The idea of limited-lifetime addresses was discussed on 2014-07-15 in http://thread.gmane.org/gmane.comp.bitcoin.devel/5837 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, if for locktime'd tx paying address, the following were enforced by consensus: - Expiration Block containing tx invalid at height > 349366 - Finality Block containing tx invalid if (349366 - locktime) > X (X is the address validity duration in blocks) - Uniqueness Block containing tx invalid if a prior confirmed tx has paid address Just an an idea, obviously not a concrete proposal. -- 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