How to avoid paying twice with Litecoin — research package v1.0.0
Experiment completed 15 October 2026 UTC; all amounts are disposable regtest LTC.

QUESTION
Does rebroadcasting identical signed transaction data create a second payment,
and does another sendtoaddress call with the same destination, amount and local
invoice comment behave differently?

WHAT WAS ACTUALLY RUN
One fresh Litecoin Core 0.21.5.8 regtest node with two fresh wallets. Peer
networking was disabled; every recorded stage had zero peers. RPC was bound
only to loopback. 101 blocks supplied mature test coins. P1 sent 0.125 LTC
without subtracting the fee from the recipient. We submitted the exact saved
raw P1 bytes while P1 was in the mempool, generated one block, and submitted
the same bytes again. A second sendtoaddress used the identical destination,
amount, comment and fee-subtraction setting. We generated one more block.

OBSERVATIONS
The pending rebroadcast returned P1's original transaction ID. The confirmed
rebroadcast returned code−27: Transaction already in block chain. Neither
created another recipient output or another mined fee payment. The second
Send produced a distinct transaction and a second 0.125 LTC recipient output.
Both paid 0.00001410 LTC in miner fees in this configuration. Final receipts
total 0.25000000 LTC and the two fees total 0.00002820 LTC. 38 experiment
assertions passed. The node exited0; its fresh temporary data directory was
removed. All stages, raw bytes, RPC calls and help text are included.

OFFLINE VERIFICATION
Python 3.10 or later; no external package or network access:
  python verify.py.txt
It checks SHA256SUMS.txt, independently decodes the transparent raw transaction
bytes, recomputes transaction IDs without witness data, checks input prevouts
and outputs with integer litoshi arithmetic, derives both fees, and compares
the JSON ledger, RPC trace and CSV stages. It does not rerun Core or claim
to validate scripts, proof of work, consensus, mainnet status or ownership.

FRESH REPRODUCTION
Only in your own disposable environment, with the pinned Linux binaries:
  python reproduce.py.txt /path/litecoind /path/litecoin-cli new-output-directory
Binary SHA256 pins:
litecoind 63fb440cdc5e2e7d46144b8e3a47dab4725fa9c056a77b8b12b11854504f4838
litecoin-cli d185011cc0dbb5d2dd20611e9dc060dbb0a5d9be31a03f57da5dbd3dad4c3769
The reproducer refuses other bytes and never accepts an existing data directory
or wallet. Its work alarm is 75 seconds, followed by bounded shutdown. The private
runner additionally bounded the entire process group to at most 90 seconds.
Fresh key generation and coin selection mean transaction IDs, output order,
signatures, timestamps and possibly fees may differ on a new run. The offline
verifier is deliberately for the frozen result, including its measured fees.
Do not replace the frozen result files with a new run and expect identical hashes.

METHOD BOUNDARIES
This is a software experiment, not a speed benchmark, test of an exchange,
mobile-wallet test, invoice processor, recovery service or mainnet payment.
Blocks were generated on demand. Receipt counts are transparent native-SegWit
outputs known to the local recipient wallet. It does not test MWEB, payment
URI parsing, replacements, conflicts, reorganizations or altered transactions
with a different txid. A different txid is a reason to inspect inputs/outputs,
not proof that two independent payments can both confirm. P2 here spends P1's
sender change output; it does not spend P1's recipient output. The two payments
do not conflict. A repeated webhook is an off-chain event; deduplicating it
does not deduplicate newly created blockchain transactions.

PROVENANCE
reproduce.py.txt is the exact successful experiment program. rpc-help.json
contains help returned by this pinned runtime. sources.json identifies the
official tagged source files and their SHA256. Those sources are used for
RPC semantics; original results are supported by our own raw evidence.
The published source/binary hashes identify bytes, not an independent audit
or reproducible-build attestation. No private keys, seeds, wallet files, private
descriptors, authentication cookies or production-wallet material are included.
The trace includes generated regtest public output descriptors.
All transaction IDs and addresses in the data are generated regtest fixtures.
Do not search for them on mainnet or send real funds to them.

FILES
results.json: complete measured outcomes, assertion list and cleanup status.
transactions.json: both raw transactions and input prevouts used to derive fees.
stages.csv: seven recorded wallet/mempool/confirmation states.
rpc-trace.json: actual RPC commands and returned data from the successful run.
rpc-help.json: actual runtime help for the methods used by the guide.
cleanup.json: final process/directory cleanup result.
reproduce.py.txt: fresh isolated experiment program; requires Core binaries.
verify.py.txt: independent offline frozen-evidence verification.
retry-checklist.txt: printable payment investigation checklist.
payment-ledger-template.csv: blank private record template; no secrets required.
scenario-cases.csv: four explicitly fictional teaching scenarios, not test results.
sources.json: versioned primary-source provenance.
SHA256SUMS.txt: public-file checksums; integrity, not authenticity certification.

EDITORIAL DISTINCTION
The guide's four named service scenarios are fictional. No provider contact,
refund, crediting delay or support response was tested. The experiment measures
only the exact Core operations recorded in the trace.