Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2015-03-26 📝 Original message:On Thu, Mar 26, 2015 at ...
📅 Original date posted:2015-03-26
📝 Original message:On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding <tomh at 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.
📝 Original message:On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding <tomh at 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.