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
