LITECOIN.WATCH — SAME TXID, DIFFERENT ACTIVE HISTORY Original regtest research package, version 2026-11-01.1 QUESTION Can the same wallet transaction appear in listsinceblock.removed while it is still confirmed? What happens when a block containing a payment leaves the active branch, and how is that different from a conflicting spend winning? This package records one completed fresh two-node Litecoin Core 0.21.5.8 regtest run: 8 named snapshots, 3 signed candidates P/Q/R, 112 block/header records and 83 passing runtime assertions. These are controlled observations in one run, not eight independent experiments, an independent replication, or a mainnet reorganization-frequency study. Two development attempts stopped before the full run (0 and 3 snapshots); their private preparation files are not exported. All coins, keys, addresses and blocks are disposable. No existing node datadir, wallet file, real funds, seed or external RPC endpoint was accepted. Do not send real LTC to any published address. No MWEB scenario or off-chain merchant crediting system was tested. The synthetic outputs are transparent legacy P2PKH. FILES results.json — authoritative signed transaction bytes, funding prevouts, complete branch graph, raw 80-byte headers, TXID lists, wallet snapshots, assertions, explicit rebroadcast control and cleanup flags. cases.csv — one compact row per named snapshot, using the sender-wallet view. It does not replace the separate receiving-wallet records in results.json. rpc-trace.json — actual node/wallet/method/parameters/result-or-error records. Authorization headers and cookies are never stored; no private-key RPC is used. reorg-test.py.txt — self-contained standard-library reproduction runner. verify-reorg.py.txt — separate offline export verifier, not a second Core run. sources.json — full immutable source pin, source byte hashes and preserved Windows build/signature provenance. SHA256SUMS.txt — integrity hashes of the frozen public files. LICENSE.txt — original-code and observation rights. ACTORS AND ISOLATION A owns two separate synthetic wallets: sender and recipient. Initial mining rewards go only to sender. Recipient therefore has no coinbase balances to confuse with its incoming P and Q payments. B has separate miner and alternate wallets. Candidate R pays alternate, a DIFFERENT intended receiving address from Q; its confirmation does not deliver Q to Q's intended recipient. Both nodes start with empty separate local temporary datadirs. RPC and P2P bind only to 127.0.0.1; automatic connections, DNS seeds, discovery, UPnP and onion listening are disabled. A manually connects only to B's loopback port. Their peer records are checked. A 16-connection cap leaves inbound slots after Core's outbound reservation; it does not authorize an external peer. Disconnection is performed before constructing competing private branches. No invalidateblock or reconsiderblock command is used. Actual higher accumulated chainwork causes the subsequent active-branch changes. txindex=1 keeps historical lookup useful; the test is unpruned. Behavior of a pruned node lacking old blocks may differ. The initial mock time is 1500000000, so MWEB does not activate. Mock time and private mining make the graph deterministic enough to study state transitions; none of these intervals measure real propagation or expected confirmation time. THE EIGHT OBSERVATIONS S0 shared-chain: both nodes share height 103. Candidate P is signed but is not a wallet payment record or a mempool entry yet. Signing alone did not submit it. S1 P-old-branch-confirmed: after disconnecting, A includes P in its block 104. A's sender and recipient wallets report 1 confirmation. Recipient has 1 LTC in trusted balance. B still has the shared height 103, with no P. S2 longer-branch-omits-P: disconnected B has mined a different 104–106 branch without P. Its actual recorded chainwork exceeds A's shorter branch. A still reports its local P confirmation at this moment. S3 P-returned-to-mempool: after reconnecting, both active tips are B's 106. A reports P with 0 confirmations and P is in A's mempool. Its old 104 header has confirmations=-1. Looking up the exact P bytes with the explicit old block still succeeds on A, with in_active_chain=false. Recipient's 1 LTC moves from trusted to untrusted_pending in this controlled state. At S3, B's mempool does NOT contain P. Mempools are node-local observations. Before B mines the next block, the runner explicitly resubmits the unchanged signed P bytes to B if they are absent. The RPC and control event are exported. This study does not claim automatic or instant transaction relay from A to B. S4 P-reconfirmed-and-removed: B includes the exact same P in block 107 and A accepts that branch. P has 1 current confirmation under a NEW confirming block hash. With the original stale 104 hash as listsinceblock's checkpoint, that same TXID appears in BOTH transactions and removed. The removed entry carries CURRENT positive confirmations; it is not a historical balance delta. Recipient's trusted balance is 1 LTC again. At S4, target_confirmations=6 changes lastblock to the appropriate cursor (height 102), while P with only 1 confirmation is still in transactions. The setting is not a minimum-confirmation payment filter. include_removed=false omits the removed array; it does not change P's current transaction status. S5 Q-old-branch-confirmed: after a new disconnect, A confirms a separate 1-LTC candidate Q in block 108. Recipient's trusted total becomes 2 LTC, P plus Q. A competing candidate R was already signed against Q's SAME funding outpoint, but R pays 2 LTC to B's alternate wallet, not Q's receiving address. S6 longer-branch-confirms-R: B independently includes R on its 108–110 branch. That branch has greater recorded chainwork than A's 108 branch. This is a controlled mutually exclusive pair of spends, not an RBF wallet-button test. S7 Q-conflicted-R-confirmed: after reconnecting, both active tips are 110. Sender reports Q confirmations=-3, R confirmations=3 and R's TXID in Q's walletconflicts. The receiving wallet also reports Q confirmations=-3 but its walletconflicts is empty: that wallet does not know the competing payment as its own transaction. Its Q amount remains 1 while details is empty. Neither that amount nor an empty walletconflicts list establishes a received payment. Recipient's trusted total is back to 1 LTC from P; alternate receives 2 LTC from R. WALLET ROWS ARE NOT UNIQUE PAYMENTS The sender's explicitly labelled self-return output produces multiple accounting rows for a TXID in listsinceblock. Do not count those rows as separate payments or sum their signed amounts as an application balance. The clean recipient wallet has the simpler incoming receive entry. Compare TXID, output/address, active confirming block, current status and wallet role before taking an action. A wallet conflict list is wallet-scoped, not a global competing-transaction index. REPRODUCING THE RUN Requires Python 3.10+ standard library, without -O, and the pinned Windows 64 Litecoin Core 0.21.5.8 executables. The runner checks exact source and copied binary hashes before launching. It copies them into its newly created local lab for fast process startup and never accepts an existing datadir. litecoind.exe SHA256 7430c6d0d4cb59d355361a0b90ffbfc4ac725609483e04c242bf95372cc9b8fe litecoin-cli.exe SHA256 6f835854576a473599f89b9842bf7855dabda1183f5a707ac5d5e15aa48761d8 python reorg-test.py.txt /path/litecoind.exe /path/litecoin-cli.exe new-output The output directory must not exist. The runner stops both nodes and removes only its exact newly created temporary lab after ordinary success or failure. The completed export records both processes stopped and the datadir removed. A new run creates different keys, transaction IDs and block hashes. Compare named states, branch ancestry, work relationships and wallet fields, rather than expecting identical result-file hashes or identifiers. OFFLINE EXPORT CHECK Place all public files in one directory and run: python verify-reorg.py.txt The verifier defaults to its own directory; it reads recorded evidence and checks package integrity without opening a node or contacting any network. Its report states its limits. It does not independently run Core, attest the software release, validate transaction signatures, prove an absence of bugs, or give a mainnet risk estimate. The separate verifier is an AI peer-check, not independent human review or a complete consensus implementation. SOURCE PIN AND LIMITS Litecoin Core tag v0.21.5.8 is pinned to immutable source commit ec1b6489a900d09cf5991e220dce089c77a232a2 Source records cover listsinceblock, its upstream functional test, current-wallet depth/conflict handling, reorg mempool updates, raw transaction and header RPCs. The prior project-key download signature check identifies the preserved binary provenance; it is not an independently authenticated identity or reproducible-build claim. Re-admission after reorg remains conditional on the transaction being acceptable; the observed P result is not a guarantee for every disconnected tx. This is one controlled transparent legacy-output topology and one Core version. No adversarial peer implementation, probabilistic security, deep real-world reorg, MWEB wallet, hardware/mobile interface, exchange account or merchant acceptance policy is tested. Research, code and drafting used AI assistance. The study provides reproducible evidence about these states, not a custody, settlement or wallet-safety guarantee.