aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mintdemux: transparent two-mint proxy for mint.coinos.ioAdam Soltys2026-07-311-63/+118
| | | | | | | | | | | | | Front the current mint (fresh keys, normal ops) as primary, and transparently route pre-shutdown ecash melts to the retired panic-mode mint so wallets can melt old ecash at mint.coinos.io without changing their URL: - /v1/keysets is the union of both mints' keysets - /v1/keys/<id> and melt execute route by the keyset owner - a melt quote is taken on the primary and the invoice remembered, so an old-keyset melt is re-quoted and executed on the recovery mint (where panic mode gates blacklisted funds) - /v1/checkstate is merged across both; CORS added for web wallets The recovery mint also stands alone at mintrecovery.coinos.io.
* zaps: stop spurious "failed to handle zap" warnings on non-zap invoicesAdam Soltys2026-07-301-10/+21
| | | | | | | | | | | The zap dispatch parsed the invoice description and, when it wasn't JSON, suppressed the error only if the message contained "Unexpected" — V8's parse- error wording. On Bun the message is "Unable to parse JSON string", so every paid invoice with a non-JSON memo logged a warning. Parse-then-check instead: a non-JSON description is simply not a zap and is skipped silently; warn only when an actual kind-9734 zap request fails to process. Co-Authored-By: Claude Opus 4.8 <[email protected]>
* nwc: guard missing app record in the notification loopAdam Soltys2026-07-301-2/+7
| | | | | | | | | A pubkey can be in `${uid}:apps` before its `app:<pubkey>` record is written (NWC-connection creation race) or can outlive its record. Destructuring `notify` off the null lookup threw, and since the catch wraps the whole loop it aborted notifications for ALL of the user's apps. Skip null/absent apps and continue. Co-Authored-By: Claude Opus 4.8 <[email protected]>
* mint-recovery: add meltguard + mintdemux proxies; ignore local *.bakAdam Soltys2026-07-303-0/+179
| | | | | | | | | | - meltguard: out-of-band CLNRest spend limiter (per-melt cap + cumulative hard-freeze) that sits between the panic-mode mint and the node - mintdemux: fronts the mint hostname, routing between the retired and current mint instances after the hostname swap - gitignore *.bak / *.bak-* so local backups (some hold secrets) never commit Co-Authored-By: Claude Opus 4.8 <[email protected]>
* mint/lightning: refuse caller-supplied invoices, tiered fees, log hygieneAdam Soltys2026-07-305-44/+158
| | | | | | | | | | | | | | | - invoices: reject caller-supplied bolt11/bolt12; the server always mints its own. Closes the invoice-registration path behind the shared-node credit and payment-hijack vectors. - lightning: skip mint-owned invoices (lbl* label) in the paid-invoice listener. - payments: lightning free-tier fee credit, withheld for flagged high-throughput (ln:nofree) accounts which pay an elevated rate; the failed-send reversal restores credit at the same rate. freezeCheck made crash-resilient. Lightning and bolt12 sends stay pending until the preimage settles. - payments (route): validate payment-request / invoice input types. - logging: collapse repeated xpay failure lines into one. Co-Authored-By: Claude Opus 4.8 <[email protected]>
* bolt12 payer proofs: disclose zap fields, lightningd v26.06.2 in sampleAdam Soltys2026-07-302-12/+19
| | | | | | | | | | | createproof's default proof omits invreq_payer_note, and passing include replaces the default disclosure set — so for zap payments request both invreq_payer_note and invoice_amount, which NIP-177 verification requires. Verified end to end on v26.06.2: NWC pay over nip44 returns a proof that decodes valid with note + amount disclosed and preimage matching the payment hash. Co-Authored-By: Claude Fable 5 <[email protected]>
* bolt12 zaps: pay offers, NWC pay/receive, per-user offers, NIP-44Adam Soltys2026-07-309-106/+500
| | | | | | | | | | | | | | | | - sendLightning fetches an invoice from lno1 offers (payer_note passthrough for NIP-177 zap intents) and pays it through the existing bolt12 path - NWC: new nwc#2 pay/receive methods (BIP-321 URIs, payer proofs stubbed until CLN 26.06 createproof), nip44_v2 alongside nip04 with per-request scheme detection, dual 23196/23197 notifications, 13194 refreshed when its content or encryption tag goes stale - standing per-user bolt12 offer via GET /offer; incoming bolt12 payments record invreq_payer_note as memo - parse/fetchinvoice routes handle offers; zap display parses kind 9736 receipts (amount tag + embedded intent) and drops a call to a sync() helper that never existed Co-Authored-By: Claude Fable 5 <[email protected]>
* preimages: support fiat prices, converted at invoice-creation timeAdam Soltys2026-07-142-14/+49
| | | | | | | | | | | | | | POST /preimages now accepts fiat + optional currency (defaults to the merchant's) as an alternative to a sat price. The fiat amount is stored per entry and converted to sats at the moment a usePreimage invoice is created, so the price tracks the exchange rate instead of freezing at upload time. The invoice also takes on the entry's currency and rate so receipts display the fiat price exactly as the merchant set it. If no rate is available for the entry's currency, the preimage is pushed back onto the queue and creation fails rather than issuing an any-amount invoice. Co-Authored-By: Claude Fable 5 <[email protected]>
* preimages: enforce a merchant-set price per preimage batchAdam Soltys2026-07-133-19/+56
| | | | | | | | | | | | | Invoice creation is unauthenticated, so buyers could name their own price for a queued preimage (create the usePreimage invoice with amount: 1). POST /preimages now takes an optional price (sats) that is stored per entry and overrides the requested amount when the preimage is consumed; omitting it keeps the old any-amount behavior. Also gate the stored-preimage reveal in credit() on the invoice being fully paid, since internal sends can settle partial amounts. Bare-hex entries queued before this change still parse (treated as priceless). Co-Authored-By: Claude Fable 5 <[email protected]>
* Merge remote-tracking branch 'origin/master'Adam Soltys2026-07-114-2/+131
|\ | | | | | | | | # Conflicts: # lib/payments.ts
| * invoices: sell merchant-supplied preimages via a usePreimage queueAdam Soltys2026-07-104-2/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merchants POST /preimages (auth) to pre-load 32-byte hex preimages into a FIFO queue; creating an invoice with usePreimage: true consumes the next one so the invoice's payment hash is sha256(preimage). Paying the invoice reveals the merchant-chosen secret to the buyer — via their own wallet on external settlements, and via GET /invoice/:id once settled — enabling backend-less digital download stores (encrypted files on static hosting, preimage + public string = decryption key). - GET /preimages lists the queue with payment hashes so the merchant can map files to future invoices; POST /preimages/delete clears it - empty queue fails invoice creation rather than issuing a random preimage the buyer would pay for but couldn't decrypt with - preimages cln rejects as already used are discarded and the next tried - consumed preimages persist at preimage:${payment_hash} (TTL = invoice expiry) and credit() prefers them as the settlement ref, so internal coinos-to-coinos payments reveal the real preimage instead of the sender's uid Co-Authored-By: Claude Fable 5 <[email protected]>
* | rates: source Iranian IRR/IRT from Wallex, decoupled from the tick loopAdam Soltys2026-07-101-19/+44
| | | | | | | | | | | | | | | | | | | | | | apiv2.nobitex.ir became unreachable from our egress, and it was fetched inline on every binance tick, so it failed and logged on every tick. Move the Iranian market-rate fetch onto its own 60s timer with a request timeout, cache the last-good value (falling back to the fixer rate after an hour), and throttle failure logging. Switch the source to Wallex (api.wallex.ir BTCTMN), which is reachable. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* | invoices: reject sub-300-sat on-chain invoice amountsAdam Soltys2026-07-101-0/+12
| | | | | | | | | | | | | | | | | | | | On-chain deposits below 300 sats are dropped by the dust filter in the confirm/credit path, so a specific-amount bitcoin/liquid invoice under that threshold can never be credited. Reject creating one at generation time and point the user at lightning. Any-amount (0) addresses are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* | invoices: rate-limit invoice create and update per IPAdam Soltys2026-07-101-2/+2
| | | | | | | | | | | | | | | | Add a per-IP rate limit (30/10s) to POST /invoice and POST /invoice/:id, matching the existing GET /invoice/:id limit, to throttle automated invoice-creation floods. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* | logging: redact password fields from the request logAdam Soltys2026-07-101-1/+12
| | | | | | | | | | | | | | | | The preHandler request logger wrote the full request body, which included plaintext passwords on auth requests. Redact password/confirm fields before logging. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* | payments: use the debited tip when crediting internal transfersAdam Soltys2026-07-103-7/+25
|/ | | | | | | | | | | | | | | | credit() now credits the tip the sender was actually debited (passed in by the internal-transfer callers) instead of independently re-reading the invoice. This closes a time-of-check/time-of-use gap where an invoice's tip could be changed between the sender debit and the receiver credit, letting a payer be credited a tip they were never charged. External receipts (lightning/ecash) keep reading the invoice tip, since there is no paired coinos debit to diverge from. Also harden POST /invoice/:id: validate the tip is a sane non-negative integer and reject tip changes on an already-settled invoice. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* lightningd: upgrade Core Lightning to v26.06.2Adam Soltys2026-07-041-1/+1
| | | | Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* rates: fix Iranian IRR/IRT feed after nobitex API host moveAdam Soltys2026-07-041-6/+19
| | | | | | | | | | The nobitex endpoint host changed (old host now NXDOMAIN) and the fetch was swallowed by an empty catch, silently blanking Iranian rates. Point at the current host, and since the API quotes in Rial despite the IRT pair name, set IRR from lastTradePrice and IRT = Rial/10. Log fetch failures instead of ignoring them. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* nwc: confirm 13194 info-event publish so it cannot be silently droppedAdam Soltys2026-06-281-3/+47
| | | | | | | | | | | | | | | | publishInfo sent the kind-13194 info event over the long-lived NWC socket fire-and-forget. The nostr lib Relay.send is async (await wait_connected; ws.send) but was called without await, and success was logged immediately. A send that rejected (e.g. ws in CLOSING state during a strfry reconnect) was silently dropped while the log claimed success, leaving NWC clients with "no info event" until a manual republish. Publish over a fresh short-lived socket and wait for the relay OK, retrying up to 3x with honest logging (warn on unconfirmed, err on give-up). ensureInfos receive-based detection is unchanged. Verified on prod: deleted both info events, restarted, both republished within seconds. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* auth: log evicted-account auth attempts with source IPAdam Soltys2026-06-281-1/+7
| | | | | | | | Emit a greppable EVICTED_AUTH line (username + cf-connecting-ip) when an evicted account's JWT is used, so the real-time auto-banner can block the source IP at the edge immediately rather than waiting for the hourly scan. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* auth: hard-evict banned accounts at the JWT layerAdam Soltys2026-06-271-0/+14
| | | | | | | | | | Add an `evicted` set check in the JWT strategy: an evicted account fails authentication on every request and every endpoint, regardless of source IP. The existing blacklist only blocks sends, so a compromised/abusive JWT could still authenticate and read/probe; eviction kills it outright. Matches on uid or username so a rename can't evade it. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* users: return generic 404 from /reset for non-adminsAdam Soltys2026-06-271-1/+10
| | | | | | | | | The admin-only password-reset endpoint returned "disabled" to non-admin callers, which confirmed both that the endpoint exists and that it is admin-gated. Return a generic 404 identical to an unregistered route instead; still log the rejected attempt server-side for monitoring. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* payments: normalize bolt11 to lowercase so failed uppercase sends get reconciledAdam Soltys2026-06-181-1/+12
| | | | | | | | | | | | | | | BOLT11 is case-insensitive, but an uppercase-pasted invoice was stored as the payment hash and the pending-set entry verbatim. check()'s startsWith("ln") test is case-sensitive, so it treated such pending entries as non-lightning and evicted them without reversing — a failed send would never be auto-refunded. - sendLightning: lowercase the invoice up front so the stored hash, the pending entry, and xpay all use the same form. - check(): lowercase before the startsWith("ln") test (defensive; also rescues any already-stored uppercase entries). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* payments: don't let check() reverse an in-flight lightning sendAdam Soltys2026-06-181-2/+19
| | | | | | | | | | | | | | | | check() skipped pending payments younger than 10s, but xpay retries for 30s (retry_for: 30). During that window listpays can transiently show all parts failed before the winning part lands, so check() could reverse a payment sendLightning was still driving; the part then completed and finalize() ran against an already-removed record. - check(): raise the skip threshold 10s -> 60s so sendLightning finishes finalize()/reverse() and removes the payment from `pending` before check() ever touches it. - finalize(): if the record is gone, raise a clear error instead of a cryptic null-deref. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* scripts: add dedup-invoices cleanup for already-duplicated :invoicesAdam Soltys2026-06-181-0/+86
| | | | | | | | | | The source fix (LPOS guard in generate()) stops NEW duplicate entries but doesn't remove the ones already accumulated. This one-time script scrubs them: scans every <id>:invoices list and removes duplicate ids, keeping each id's original creation-order position. Dry-run by default; pass --apply to write. Idempotent. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* invoices: don't re-list an invoice id on update (dedupe :invoices)Adam Soltys2026-06-181-1/+7
| | | | | | | | | | | generate() unconditionally lPush'd the invoice id to `${aid}:invoices`, but it's also called from the update() handler (tip/webhook changes, and repeated bolt12 offer creation) re-using the existing id — so each update re-appended the same id and the user's :invoices accumulated duplicate entries, rendering the same offer/invoice multiple times. Only push when the id isn't already in the list (LPOS guard). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* lnurl: SSRF-guard user-supplied URL fetches + validate zap eventsAdam Soltys2026-06-152-5/+97
| | | | | | | | | | | | | | | | The /lnurl/proxy, /decode and /encode handlers fetched an arbitrary user-supplied URL via got() and returned the body — an unauthenticated SSRF reaching internal services. Route those fetches through a new safeGot() that rejects hosts resolving to loopback/private/link-local/ CGNAT/metadata ranges, re-validates on each redirect hop, restricts the scheme to http(s), and caps timeout + response size. Also validate the NIP-57 zap request (kind 9734 + signature) before storing it, instead of trusting the client-supplied event. These endpoints can't be removed — they back lightning-address/LNURL parsing and resolution in the wallet UI. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Push broadcast txs directly to public explorersAdam Soltys2026-06-151-0/+16
| | | | | | | | | 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) <[email protected]>
* setup override warningAdam Soltys2026-06-141-0/+14
|
* scripts: add wiped-history audit and rebalance-economics modelAdam Soltys2026-06-132-0/+181
| | | | | | | | | audit-wiped-history.ts (read-only) finds accounts whose :payments index was wiped by the changeid bug — balance>0 with empty history in both db and arc. rebalance-economics.ts models whether the lightning->liquid bridge throughput is fee-positive against on-chain rebalance cost. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* users: add authenticated self-delete endpointAdam Soltys2026-06-132-0/+104
| | | | | | | | | | POST /delete (auth) wipes every key tied to the calling user, mirroring scripts/delall-legacy.ts: user records, payments/invoices, sub-accounts, NWC apps, nostr follow graph + nip5. Gated by typing the username and refuses while balance+pending > 10k sats so funds can't be destroyed by accident. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* payments: guard /replay double-credit race with SET NX idempotencyAdam Soltys2026-06-132-1/+16
| | | | | | | | | | 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> (ref = preimage) and bail if already claimed. Also disable the /replay route that triggered it. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* payments: freeze matches uid as well as username (rename-proof)Adam Soltys2026-06-131-4/+6
| | | | | | | | | 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) <[email protected]>
* deps: bump file-type 18->21 and uuid 8->11 (Dependabot)Adam Soltys2026-06-072-2/+2
| | | | | | | | | | | | | | | | | | | | Clears two Dependabot alerts: - file-type (medium): infinite loop in ASF parser on malformed input — reachable via avatar/image upload (fileTypeFromBuffer in lib/upload.ts). -> 21.3.4 - uuid (medium): missing buffer bounds check in v3/v5/v6 when buf is provided — we only ever call v4() with no buffer so not actually exposed, bumped anyway. -> 11.1.1 Both are major bumps but drop-in for our usage: project is already ESM ("type":"module") so file-type's ESM-only requirement is fine, and we use the stable named exports (fileTypeFromBuffer, v4). Verified live: v4() and fileTypeFromBuffer JPEG detection both work; full app compiles + healthy. Installed inside the app container (node_modules is root-owned, volume-mounted). The 4 remaining fastify-family alerts (incl. the critical http-proxy one) need a fastify 4->5 + 8 plugins lockstep upgrade — deferred to a dedicated window; real exposure is low behind Cloudflare/Caddy with localhost binding. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* lightning: watchdog only recycles on real backlog, not normal idleAdam Soltys2026-06-061-17/+24
| | | | | | | | | | | | | | | | | The zombie-listener watchdog (bd1ece38) treated "waitanyinvoice blocked > 5min while cl is alive" as a stall — but that's NORMAL during quiet periods, so it false-fired and needlessly recycled the cl listen socket every few minutes (~26x in 6h on 2026-06-07). Receives still worked, but it was churn + noise and would mask a genuine zombie. Fix: a blocked long-poll is only a zombie if cl actually has a paid invoice the listener isn't picking up. When blocked past the threshold, probe cl on the MAIN socket with waitanyinvoice(pay_index, 2s server-side timeout): if it returns an invoice there's a real backlog the wedged listener missed -> recycle; if it times out (CLN code 904 = nothing waiting) the listener is just idle and healthy -> leave it alone. Only recycle on a confirmed backlog. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* nwc: keep notifications opt-in (revert default-on)Adam Soltys2026-06-061-6/+5
| | | | | | | | | | Reverting the notify default-on from 8cb18821 — most users don't consume notifications and defaulting on would flood the relay with payment_sent/ payment_received for ~3k apps. Notifications stay opt-in: clients enable by sending notify:"true" when creating the NWC connection. The pay_invoice reply-reliability and rate-limit fixes from 8cb18821 are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* nwc: fix pay_invoice reply reliability, rate-limit drops, notificationsAdam Soltys2026-06-062-37/+87
| | | | | | | | | | | | | | | | | | | | | | | | | Three issues reported by an NWC client integrator (refs #80): (a) pay_invoice sync reply: the handler polled listpays for ~20s then returned a misleading "Payment timed out" error on slow routes even though the payment settled — client never got the preimage. sendLightning already runs xpay to completion and finalize() sets p.ref = preimage, so return that directly; keep a longer listpays loop only as a fallback, and on still-in-flight return an explicit "check with lookup_invoice" rather than implying failure. (b) rate limiting: raised per-pubkey cap 5/min -> 60/min (normal usage — a balance check + payment + a few lookup_invoice reconciles — trivially exceeded 5), and over-limit requests now get a NIP-47 RATE_LIMITED error reply instead of a silent drop that looked exactly like a lost reply. Also: every request path now always sends a 23195 reply (success, error, or handler-returned- nothing) so a client never hangs waiting. (c) notifications: payment_received/payment_sent are advertised in the info event but app.notify defaulted to false unless the client sent notify:"true" (only ~1% of apps had it on), so they never fired. Default notify ON; only disable when explicitly "false". (Existing apps still false — backfill TBD.) Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* payments: clarify deposit log (pending vs confirmed) to stop phantom ↵Adam Soltys2026-06-041-1/+9
| | | | | | | | | | | | | | double-receive 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) <[email protected]>
* nwc: pay_invoice honors request amount for amountless bolt11Adam Soltys2026-06-041-2/+14
| | | | | | | | | | | | | | | | pay_invoice derived the amount solely from the decoded invoice, so an amountless bolt11 yielded amount = round(undefined/1000) = NaN and sendLightning rejected it with "Invalid amount". NIP-47 allows the client to specify the amount (msat) in the request for exactly this case (AlbyHub supports it; Alby Go and others hit the error). Fall back to the request's `amount` field when the invoice carries none; invoice amount still takes precedence when present, and a still-missing amount returns a clear error instead of NaN. sendLightning/sendInternal already handle amountless invoices given a valid amount — the bug was only the handler dropping it. Fixes #83 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* nwc: fix make_invoice timestamps (ms -> seconds) breaking NWC clientsAdam Soltys2026-06-041-5/+8
| | | | | | | | | | | | | | | | | | generate() stores `created` in milliseconds (Date.now()), but the NWC make_invoice response returned it directly as created_at and computed expires_at = created_at + expiry. NWC timestamps are Unix SECONDS (NIP-47), so clients parsed a ~1.78e12 expires_at that overflowed their date types — e.g. ptcpay's .NET DateTimeOffset, whose max is 253402300799 (issue #84: "creating lightning invoices via NWC fails ... Valid values are between -62135596800 and 253402300799"). Convert created to seconds before use. The other NWC handlers were already correct (lookup_invoice reads seconds straight from cln; list_transactions divides p.created by 1000). Only make_invoice leaked milliseconds. Fixes #84 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* ln/lightning: watchdog recycles zombie receive-listener socketAdam Soltys2026-06-042-1/+81
| | | | | | | | | | | | | | | | | | | | | On 2026-06-04 cl restarted (autoheal, after its 15s healthcheck timed out), and the app's waitanyinvoice long-poll hung on the now-dead listen socket. listenerActive stayed true forever, so ensureListenerAlive never restarted it, and incoming lightning payments stopped crediting for ~2h until a manual app restart. The per-call RPC timeout in ln.ts can't catch this: waitanyinvoice is intentionally in NO_TIMEOUT (it's meant to block). Fix: ensureListenerAlive (runs every 120s) now also detects a stalled listener — active but blocked in waitanyinvoice for >5min. It probes cl via the main ln socket (getinfo); only if cl is actually alive does it treat the listen socket as a zombie, call lnListen.reset() (new: drops the proxy's socket so the next call reconnects), and re-arm. A listenerEpoch guard makes the wedged invocation bow out when its waitanyinvoice finally rejects, so we never run two listeners concurrently and never double-credit. Verified with a state-machine test covering normal receive, quiet-but-healthy (left alone), stall+cl-alive (recycled), stall+cl-down (left alone), and the no-double-listener race. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* analytics: missing-history audit + lightning->liquid arb finderAdam Soltys2026-06-042-0/+232
| | | | | | | | | | | | | | | | | audit-missing-history.ts: read-only audit classifying every user's payment history as clean / recoverable (record in arc not db) / lost (gone from both). Full-scan finding: of 6,330 users with history, 77% are "arc-only" which is the NORMAL archived state — the payments route reads via gf() (archive fallback) so those render fine in the app. True loss is 58 users / 59 records (0.02%). So there is no widespread history loss; "missing history" reports are almost always either dropped receive-callbacks (record never written, like apk403's 1100 sats) or one of the rare 59. ln-liquid-arb.ts: finds users funding via lightning and withdrawing via liquid (the pattern draining the liquid hot wallet / forcing threshold cuts). Reports per-user through-flow + net liquid drainers. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* analytics: --csv flag for month-over-month trend trackingAdam Soltys2026-06-041-1/+50
| | | | | | | | | | Appends one metrics row per run to a CSV (header written if file is new): date, users, MAU/WAU, payments, volume, custody, fee revenue, bolt12 recipients, and per-type volume/txn columns. Notice goes to stderr so it doesn't pollute the saved stdout report or --json output. Drives the new monthly snapshot cron (~/scripts/analytics-cron.sh). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* analytics: monthly insight reports + signup instrumentationAdam Soltys2026-06-033-0/+377
| | | | | | | | | | | | | | | | | | | | | scripts/analytics.ts — streams live db (SCAN, never KEYS) and reports for a trailing window (default 30d): MAU/WAU, new users, custody total + top holders, network volume by type (lightning/liquid/bitcoin/internal/bolt12/ fund), most-active and highest-volume users, and bolt12 recipients with a "regular" flag for the Ocean mining-reward stream. scripts/analytics-geo.ts — top countries from the request log. Counts only /login + /register events tied to a username (raw cf-ipcountry volume is dominated by datacenter/nostr traffic). Surfaces a distinct-IP-per-country column so proxy/VPN egress is visible, and filters a known credential-test bot IP. Honest result: US #1, then GB/CA/JP/DE/ES/BR. lib/register.ts — stamp `created` (ms epoch) and store `country` (CF/ ipregistry code) on new users, so future reports get real signup timing and geography from the db directly instead of log archaeology. Existing users predate this; backfill is out of scope. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* nwc: publish 13194 info event only when missing, recheck hourlyAdam Soltys2026-06-021-26/+65
| | | | | | | | | | | | | | | | | | NWC clients (Alby Go, Lightning Piggies) fetch the kind 13194 info event (capability advertisement) before they'll talk to the wallet; without it they report "no info event" and show an unknown balance. The events went missing after strfry restarted on 2026-05-29 and stayed gone for days, because the app only published them once in the relay's on-open handler and nothing re-asserted them. 13194 is a replaceable event meant to persist, so instead of blindly republishing, query the relay on connect and publish only the server pubkeys whose info event is actually missing (ensureInfo). Re-check hourly so a relay restart that leaves our socket intact also self-heals. Interval is cleared on close/reconnect alongside the heartbeat to avoid leaks. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* ln: time out short-lived RPCs so a hung cl reconnects without restartAdam Soltys2026-05-311-2/+64
| | | | | | | | | | | | | | | | | | A unix-domain RPC socket has no TCP keepalive, so if cl goes unresponsive while the socket stays open (zombie/half-open), an awaited call hangs forever — the "stuck spinner past /pay/bob, no error" symptom. Nothing threw, so the existing reconnect-on-error path never fired and only an app restart recovered it. Wrap short-lived calls in a 30s Promise.race timeout (matching health.ts). A timeout rejects with ETIMEDOUT, now part of isSocketDied, so the client is dropped and the next call reconnects — no process restart. Long-polls (waitanyinvoice et al), in-flight payments (pay/xpay/sendpay/keysend), and bolt12 round-trips (fetchinvoice/ sendinvoice/offer) are exempt: timing those out client-side would risk leaked debits or break intentional blocking. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* debit: exempt internal sends from server liquidity limitAdam Soltys2026-05-311-8/+16
| | | | | | | | | | | | 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) <[email protected]>
* sendLightning / finalize: drop chatty per-send INFO logsAdam Soltys2026-05-251-5/+7
| | | | | | | | | | | | | | | | | | Each successful lightning send was emitting 5 INFO lines: "<user> sent lightning <amount>" (debit, KEEP) "paying lightning invoice <pr> <amt> <fee>" (drop — redundant) "payment completed <id> <preimage>" (drop — implicit from absence of warns) "refunding fee <maxfee> <fee> <delta> <ref>" (drop — the warn for non-integer delta already covers anomalies) "sendLightning outcome <id> = finalized" (drop for "finalized" only — keep for the recovery-via-fallback variants since those are diagnostic) Net: only the "<user> sent lightning <amount>" 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) <[email protected]>
* sendLightning: stop warning on healthy multi-path paymentsAdam Soltys2026-05-251-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <id> = finalized-via-listpays-after-failed_parts" info line instead of 3 WARN lines. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
* finalize: don't crash on non-integer fee delta (db.incrBy NaN)Adam Soltys2026-05-251-5/+25
| | | | | | | | | | | | | | | | | | | | 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:<uid>, 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) <[email protected]>
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-21 11:26:09 +0000