coinosv3.git/tools/ln-receive-twin-test.js, branch master

Spending: one coin, one "Received" row — across devices. The Daniel still saw four "Received 1,000" rows and "Payment received! 4,000" for what the ASP shows is a single 1,000 sat coin (and two rows for his 1,005). A receive movement is recorded by every device or tab that sees the coin arrive, each under its own id, and the cross-device merge unions movements by id — so each kept its own row, and the registrar-receipt tagging marked some ⚡. lnFoldedIds now also folds receives of the same coin: the ⚡-tagged one stays (its icon is right), else the earliest. Same read-time derivation as the claim twins (history, celebration, arkMovements, LN tagging), so nothing is deleted and no synced copy brings a twin back.

2026-10-09T23:45:22Z

Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01Vps2H27rhbG9ZqseGfMrc3

Spending: a Lightning receive is one row. The ASP settles it as an arkoor the wallet claims — recorded as ln-receive, without its coin's id — and the same coin can reach the mailbox too, which (seeing no movement for that coin) recorded a plain receive as well: two "Received 1,005" rows and a "Payment received! 2,010" (The Daniel). The claim now stamps its coins' ids on the ln-receive, the mailbox backfill counts them, and lnFoldedIds leaves a receive of a claimed coin out of history, the celebration, the arkMovements hook and the LN tagging — derived at read time, never deleted, so a synced copy can't bring the twin back. Claims recorded before the stamp match by amount within ten minutes. tools/ln-receive-twin-test.js

2026-10-09T23:24:58Z

Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01Vps2H27rhbG9ZqseGfMrc3