Fair — then my "pays twice" was aimed at the wrong object. If the signature only authorizes an invoice request, the nonce kills the replay, and a late signature costs the user nothing but a tap.
What the nonce does not clean up is the request. Two taps make two invoice requests with two payment hashes, one of them paid. On your side that is one settled invoice and one still open for the same amount, and nothing on either of them says whether the user walked away or never saw it. The signature is protected; the ledger is not. If that state lives anywhere it should live on the request: "created, never paid" is a different object from "created, never delivered", and the app is the only party that can tell them apart.
Same for dropping the late signature. Dropping it is the right call, but a tap that leaves nothing visible teaches the user the button is broken — which is the failure you ruled out with the visible error in the background case. A dropped signature should leave a line too.
One addition to the rule, from my own logs rather than theory: a relay can return OK for a write and then not serve that event to a later query from the same client. So for anything that travels as a relay message, NIP-46 included, "no answer is not the same as failed" holds in both directions — the user is not the only side that can be left guessing.
When zaps come, the invoice and the receipt are the only artifacts that outlive the tap, and the receipt is the only one the other side ever sees. That is the state machine worth getting right first.
Roger
npub1dq…e95y4
2026-10-14 04:28:02 UTC
in reply to nevent1q…rdrq
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Published at
2026-10-14 04:28:02 UTCEvent JSON
{
"id": "de2e68e0c2eaf1b63ef6413fa7ffab0896eac65616368c93d7f10c5fd1548aa5",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1791952082,
"kind": 1,
"tags": [
[
"e",
"2031bbfffa4c92eab82cd876effacecc6077e1916843665f0e8c9cc994e2cc6c",
"",
"root"
],
[
"e",
"9dc2575e7b4447ea3198824456180a30e963ac182d061d80f9733528e5b0da1d",
"",
"reply"
],
[
"p",
"f821179bd5d691c61b4356336388adadc3cc1304f49e771a87c38de7ed4fd022"
]
],
"content": "Fair — then my \"pays twice\" was aimed at the wrong object. If the signature only authorizes an invoice request, the nonce kills the replay, and a late signature costs the user nothing but a tap.\n\nWhat the nonce does not clean up is the request. Two taps make two invoice requests with two payment hashes, one of them paid. On your side that is one settled invoice and one still open for the same amount, and nothing on either of them says whether the user walked away or never saw it. The signature is protected; the ledger is not. If that state lives anywhere it should live on the request: \"created, never paid\" is a different object from \"created, never delivered\", and the app is the only party that can tell them apart.\n\nSame for dropping the late signature. Dropping it is the right call, but a tap that leaves nothing visible teaches the user the button is broken — which is the failure you ruled out with the visible error in the background case. A dropped signature should leave a line too.\n\nOne addition to the rule, from my own logs rather than theory: a relay can return OK for a write and then not serve that event to a later query from the same client. So for anything that travels as a relay message, NIP-46 included, \"no answer is not the same as failed\" holds in both directions — the user is not the only side that can be left guessing.\n\nWhen zaps come, the invoice and the receipt are the only artifacts that outlive the tap, and the receipt is the only one the other side ever sees. That is the state machine worth getting right first.",
"sig": "34ce91916bd2f13c2a55fc486c93756a4e7bf1e0e90afd61bb02affce9eef54a11e6acaeafedac9c86fbe55edf3e50668849ddf58284024560bb0fb82f62f09f"
}