📅 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.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:32:13
in reply to nevent1q…0g5v
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:32:13Event JSON
{
"id": "cf381cd4305221b0814ac5528490053d8f5056266e258abd5518ed9bcee2cc5c",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151933,
"kind": 1,
"tags": [
[
"e",
"13ba2dac7eec5154e8f99682c168a8cede79e5ef5e0b1fe726762657ed73749d",
"",
"root"
],
[
"e",
"0b34a8bb0354240a54ca96eb90a824e1ce402e6ef7738570e6353ed4034367b6",
"",
"reply"
],
[
"p",
"dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3"
]
],
"content": "📅 Original date posted:2015-03-26\n📝 Original message:On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding \u003ctomh at thinlink.com\u003e wrote:\n\u003e I addressed that by limiting the duplicate check to an X-block segment. X\n\u003e is hard-coded in this simple scheme (X=144 =\u003e \"1-day addresses\"). You\n\u003e could picture a selectable expiration duration too.\n\nIf its to be heuristic in any case why not make it a client feature\ninstead of a consensus rule?\n\nIf someone wants to bypass anything they always can, thats what I mean\nby \"hide their payment under a rock\"\n\nE.g. I can take your pubkey, add G to it (adding 1 to the private\nkey), strip off the time limits, and send the funds.\n\n\"What do you mean I didn't pay you? I wrote a check. locked it in a\nsafe, and burred it in your back garden.\"\n\nThe answer to this can only be that payment is only tendered when its\nmade _exactly_ to the payee's specifications.\n\nIf someone violates the specifications all they're doing is destroying\ncoins. Nothing can stop people from destroying coins...\n\nWhich is why a simpler, safer, client enforced behavior is probably\npreferable. Someone who wants to go hack their client to make a\npayment that isn't according to the payee will have to live with the\nresults, esp. as we can't prevent that in a strong sense.",
"sig": "47ac630a7a54941e41c5097a6c34c04717da5df28bad1e21d85f38ba35cc106155bc410d124f9f806c9c4650a11b7a8904a219832f0529e83e50c01511fbb760"
}