coinos-server.git/lib/payments.ts, branch regtest-fulcrum

Push broadcast txs directly to public explorers

2026-06-15T20:01:41Z

After broadcasting an on-chain send via bitcoind, also POST the raw tx to mempool.space and blockstream (fire-and-forget, non-blocking) so those explorers see it immediately instead of waiting ~8s for p2p propagation. Skipped on regtest/testnet. Co-Authored-By: Claude Opus 4.8 (1M context)

payments: guard /replay double-credit race with SET NX idempotency

2026-06-13T21:21:44Z

getPayment() pre-check in the lightning listener/replay isn't atomic, so concurrent re-credits of the same settlement each ran incrBy. Claim each lightning/bolt12 settlement with an atomic SET NX on credited: (ref = preimage) and bail if already claimed. Also disable the /replay route that triggered it. Co-Authored-By: Claude Opus 4.8 (1M context)

payments: freeze matches uid as well as username (rename-proof)

2026-06-13T21:21:39Z

The blacklist (send freeze) only matched the current username, so a compromised account could shake the freeze by renaming itself. Match on either the lowercased username OR the immutable uid; add the uid to the `blacklist` set to freeze durably. Co-Authored-By: Claude Opus 4.8 (1M context)

payments: clarify deposit log (pending vs confirmed) to stop phantom double-receive

2026-06-05T06:38:32Z

completePayment logs once when an on-chain deposit is first seen (pending) and again from /confirm when it confirms, both as bare "received" — so a single liquid/bitcoin deposit appeared twice in the logs and looked like a double credit. It never was (the /confirm p.confirmed guard and the seen set prevent double-crediting); purely misleading log noise. Now logs "receiving (pending)" on first sight and "received" on confirmation. Instant lightning receives are confirmed=true so they still log a single "received". Co-Authored-By: Claude Opus 4.8 (1M context)

debit: exempt internal sends from server liquidity limit

2026-06-01T06:27:59Z

freezeCheck only populates ${type}:limit for external asset types (lightning/fund/ecash/bitcoin/liquid/bolt12), so internal:limit stays 0 forever. The atomic limit check added in 609fcebe applied to all types, so amount > 0 blocked every internal coinos-to-coinos payment with "serverLimit 0". Internal sends are pure ledger moves that never touch an external wallet — there's no hot-wallet liquidity to reserve — so exempt them, matching the existing soft-freeze and withdraw-lock gates. Co-Authored-By: Claude Opus 4.8 (1M context)

sendLightning / finalize: drop chatty per-send INFO logs

2026-05-25T19:59:00Z

Each successful lightning send was emitting 5 INFO lines: " sent lightning " (debit, KEEP) "paying lightning invoice " (drop — redundant) "payment completed " (drop — implicit from absence of warns) "refunding fee " (drop — the warn for non-integer delta already covers anomalies) "sendLightning outcome = finalized" (drop for "finalized" only — keep for the recovery-via-fallback variants since those are diagnostic) Net: only the " sent lightning " line fires per healthy send, matching the other asset types' style. Anything that needed a fallback path or threw still surfaces via the existing warn/err lines. Co-Authored-By: Claude Opus 4.7 (1M context)

sendLightning: stop warning on healthy multi-path payments

2026-05-25T19:56:16Z

Each xpay with failed_parts > 0 that ultimately settled (multi-path retry — common, not concerning) was firing 3 WARN lines: "xpay returned (abnormal)" "xpay returned failed_parts without throwing" "xpay failed_parts but listpays complete — finalizing" These are all the SAME successful payment. The presence of failed_parts just means CLN tried multiple paths before one succeeded. Adam was seeing noise. Now: - Only warn on actually-missing preimage (xpay silently failed). - Drop the unconditional "without throwing" warn — the failed_parts branch handles the recovery silently in the success case. - Drop the "listpays complete — finalizing" warn — that's the success path, not a concern. - KEEP warns for the genuinely interesting cases: listpays says failed (we're about to reverse), listpays says pending (debit left for check() to reconcile), or finalize itself throws. Net effect: a healthy multi-path payment now emits only the standard "sendLightning outcome = finalized-via-listpays-after-failed_parts" info line instead of 3 WARN lines. Co-Authored-By: Claude Opus 4.7 (1M context)

finalize: don't crash on non-integer fee delta (db.incrBy NaN)

2026-05-25T16:22:26Z

Triggered by a recurring "finalize threw despite no failed_parts: ERR value is not an integer or out of range" warning. Root cause: when xpay's response shape is unexpected (or invoice is zero-amount and decoded amount_msat is undefined), the computed p.fee becomes NaN. The subsequent db.incrBy(balance:, maxfee - NaN) throws because Redis can't increment by NaN. Symptom: leak guard fires "ref set in db despite throw" — payment is actually fine (p.ref persisted before the throw) but finalize never completes the fee refund. User loses up to maxfee sats (was already debited maxfee, gets nothing back). Fix: validate the computed fee is a finite integer; if not, keep the originally-reserved maxfee (zero refund, no balance corruption) and warn loudly. Same guard on the refund delta before db.incrBy. Co-Authored-By: Claude Opus 4.7 (1M context)

sendLightning: silence success-case xpay log, re-read db before leak guard

2026-05-21T14:35:42Z

Two cleanups based on a day of production data: 1. Only log the xpay response shape when something is abnormal (failed_parts > 0 or missing preimage). The success case (200+/day) was pure noise — answers Adam's "do we still need these xpay warnings". 2. Re-read the payment record from db before the leak guard fires. Several "LEAKED DEBIT" lines today were finalize() throwing on a late line (likely db.incrBy for the fee refund) AFTER db.set had already persisted p.ref. The payment is functionally settled in those cases — only flag as a real leak if ref is genuinely missing from the db record. Co-Authored-By: Claude Opus 4.7 (1M context)

tighten LEAKED DEBIT guard: don't false-alarm on successful-via-fallback paths

2026-05-21T05:29:35Z

The first deployment surfaced two LEAKED DEBIT lines that were actually clean finalizes via the new failed_parts listpays-fallback path — exactly the path that recovers payments that would have been stuck under the old code (joho33's case). The leak guard's `outcome !== "finalized"` check was too narrow: any path that finalizes the payment, regardless of how it got there, is a success. Bucket outcomes explicitly: - finalizedOutcomes — clean successes (finalize ran, ref set) - safeNonFinalized — reverse ran, OR debit left in pending for check() to reconcile (these aren't leaks) - anything else — actually stranded (finalize-threw-*, unknown) → err Co-Authored-By: Claude Opus 4.7 (1M context)