A signed Litecoin payment can be ready to send without having been sent. In our Core test, an unsigned proposal became a signed file, then an extracted raw transaction. The sender’s balances did not change, the selected input remained unspent and the recipient had received nothing. Even a successful local acceptance test left the mempool empty.
The payment appeared only after an explicit submission. A second result matters just as much: another signed file still reported complete signatures after its input had been spent elsewhere. That old file was no longer acceptable to the node.
These are different questions: what did I approve, did anyone submit it, and can it still spend its inputs? This guide shows how to keep them separate. The downloadable evidence uses disposable regtest coins. It is not a test of a physically air-gapped device, a hardware wallet or a real payment service.
Know whether the button approves a file or sends a payment
Before approving anything, identify the operation. A transaction signature authorizes a proposed spend under its signing rules. A plain message signature is a different operation; our message-signing experiment covers that distinction. A screen using the word “sign” does not tell you which kind it means.
A wallet may combine several steps behind one button. Another workflow may prepare on one device, sign on another and submit later. Ask which step your wallet performs, where the signed result goes and who is expected to submit it. Do not infer that the payment was sent just because a progress bar reached “signed.”
Review the full destination, amount, change and miner fee using your wallet’s documented review process. A familiar file name, merchant label or earlier screenshot does not establish that the current transaction contains the intended outputs. If there is an unfamiliar output or an unexplained fee, resolve it before signing.
The hardware-wallet protection guide explains why approving the wrong payment remains a problem even when keys are isolated. Our experiment below tests transaction states, not the trustworthiness of a screen or device.
A PSBT carries a proposal and the information needed to sign it
The format’s full name is Partially Signed Bitcoin Transaction (PSBT); the tested Litecoin Core release uses it for its Litecoin transaction workflow. It is a format for passing an unfinished transaction together with relevant information between tools or signing roles. It can carry the previous outputs being spent, public keys, derivation information and signatures. It is not a wallet backup and does not supply a missing recovery seed.
A raw transaction is the network-serialized transaction that a node can be asked to accept. Getting that raw transaction out of a completed PSBT is extraction. Submission is a later operation. The tagged Core PSBT workflow describes those roles separately, while noting that implementations can combine roles.
| Result you have | What it can establish | What it does not establish alone |
|---|---|---|
| Prepared unsigned PSBT | A proposed transaction plus supplied signing metadata. | Approval, submission or receipt. |
| Completed signed PSBT | The tool found the required signatures for its supported workflow. | That the input remains unspent or anyone sent the payment. |
| Extracted signed raw transaction | A serialized candidate that can be submitted. | Mempool presence, confirmation or service credit. |
| Successful local acceptance test | The candidate passed that node’s current test. | Insertion into its mempool or acceptance by every other node. |
| Submission followed by confirmation | Separate evidence of local acceptance and inclusion in a block. | The recipient service’s private accounting decision. |
In the tested Core 0.21.5.8 release, walletprocesspsbt also finalized our single input while signing it. We therefore describe that as a combined signed/finalized-PSBT step.
We recorded each stage before allowing submission
The successful run took place on 20 October 2026 at 22:26 UTC, already 21 October at 00:26 in Warsaw. One fresh Core 0.21.5.8 regtest node hosted two newly created wallet roles. Peer networking was disabled and RPC was bound to loopback. Calling those roles “sender” and “recipient” does not make them separate physical devices.
We mined 102 fixture blocks to obtain two mature funding outputs. The approved payment spent one 50 LTC test output, assigned 0.25 LTC to the recipient and returned 49.74999000 LTC as change. The difference was a 0.00001000 LTC miner fee: 1,000 litoshi. Its signed virtual size was 141 vB.
We then recorded balances, input availability, mempool contents and recipient receipt after preparation, signing, extraction and policy testing. Those observations remained unchanged before submission. The experiment made no mainnet connection and measured no propagation or confirmation waiting time.
| Recorded stage | Height | Mempool transactions | Recipient receipt |
|---|---|---|---|
| Funding prepared | 102 | 0 | 0 LTC |
| Unsigned PSBT prepared | 102 | 0 | 0 LTC |
| Signed/finalized PSBT returned | 102 | 0 | 0 LTC |
| Signed raw transaction extracted | 102 | 0 | 0 LTC |
| Local acceptance test passed | 102 | 0 | 0 LTC |
| Explicit submission succeeded | 102 | 1 | 0.25 LTC unconfirmed |
| One fixture block added | 103 | 0 | 0.25 LTC confirmed |
The full eight-stage CSV includes the later stale-input control. The first five snapshots also record identical sender balances and an unspent selected input. Creating a proposal did not reserve that output on the chain. A wallet may offer local input-locking features, but that is a separate mechanism.
A transaction ID is not proof that the transaction was sent
Our prepared native-SegWit proposal already had the same transaction ID as the final signed transaction. The input scripts stayed empty and signing added witness data. The identifier was therefore available while the node’s mempool was still empty and the recipient had received zero.
This is a useful check when somebody presents a transaction ID as a receipt. Obtain the actual transaction and current status from an appropriate trusted source, then verify the intended recipient output and amount. An identifier copied from a proposal does not establish submission or confirmation.
Likewise, “allowed” from testmempoolaccept described a test, not a send. In the captured run, the exact candidate passed that test and a subsequent snapshot still showed zero mempool entries. The result was conditional on that node’s current inputs and rules; it was not a promise about a future state.
Changing an output did not preserve our approval
We signed with the default ALL mode, retained the original witness and made two byte-level changes to copies of the final transaction. One replaced the recipient’s output script. The other moved exactly one litoshi from change to the recipient, preserving the total output value and the 1,000-litoshi fee.
Both altered candidates failed the node’s acceptance test with a signature-related script error. The offline verifier also rejects their ECDSA signatures under the altered transaction digests. It verifies the original candidate successfully. The result was not caused by adding another fee or spending an input between tests.
This is deliberately a narrow claim about these ordinary P2WPKH ALL signatures. Other signing modes can commit to different parts of a transaction and were not tested. Do not approve an unfamiliar signing mode on the assumption that this particular demonstration covers it.
| Case | Candidate and current condition | Observed acceptance test |
|---|---|---|
| P01 | Exact approved payment; its input is available | Allowed |
| P02 | Recipient changed; original signature | Rejected: signature-related script check |
| P03 | Recipient +1 litoshi, change −1; original signature | Rejected: signature-related script check |
| P04 | Separate held signed payment before its input is spent | Allowed |
| P05 | Alternative controlled self-spend of the held input | Allowed; then submitted and confirmed |
| P06 | Identical held payment after that confirmed input spend | Rejected: missing inputs |
Complete signatures do not keep an input available
The held candidate was a different proposed payment from a second funding output. It would have paid the recipient 0.10 LTC and passed the local acceptance test before anything spent that output. We kept the signed file without submitting it.
For a separate control, we signed an alternative transaction spending that exact input back to the sender. We submitted and confirmed the self-spend. The old 0.10 LTC candidate then failed with missing-inputs; its explicit submission also returned an error. Nevertheless, extracting it from the old PSBT still returned complete: true.
The signatures had not become mathematically wrong. The original input was no longer available. The recipient’s confirmed total remained 0.25 LTC because the held payment never succeeded. This control is not a recommendation for cancelling a real payment: replacement policy, peers and competing transactions were not tested. See the separate guide to cancellation limits for that question.
Handle a signed file as an authorization, not a harmless receipt
A person holding a complete signed transaction may be able to submit it without obtaining another signature from you, provided the transaction is still valid and its inputs are available. Deleting your local copy does not revoke copies already given to somebody else. Before handing over the file, know whether submission is part of what you intend.
Do not post a real PSBT or signed transaction publicly just to ask why it is stuck. Our prepared PSBT included both previous-transaction information and public BIP32 derivation metadata. That is useful signing context, but it can reveal relationships and wallet structure when it belongs to a real person. Even an unsigned file deserves a disclosure decision.
Use the smallest information needed for a support request and an authenticated channel. Never provide a seed, private key or wallet password. A support discussion does not need a fresh spending authorization merely to identify an already submitted transaction.
Check the actual state before approving a second payment
If the wallet says “signed” but a recipient sees nothing, first check whether submission was intended and whether it happened. Look for the exact approved transaction, its recipient output and its current status. Do not assume the missing display means a second Send action is harmless.
If you intentionally kept a signed file for later, recheck the payment instructions, fee assumptions and input availability before submission. Time passing does not make the file a fresh approval. Rebuilding a proposal may require a new signature; do not splice an old signature into newly edited outputs.
The duplicate-payment experiment explains why a new payment and rebroadcasting the same bytes are different. Our blank payment-review checklist helps record approval, handoff and submission as separate decisions.
Inspect the evidence without connecting a wallet
Download the version 1 research package and run python verify.py.txt with Python 3.10 or later. It needs no node, wallet, network connection or additional library. The package contains fresh public regtest fixtures, never payment instructions. Do not fund its addresses.
The verifier parses transaction and PSBT bytes, recalculates identifiers, sizes and fees, and checks witness-v0 ECDSA signatures. It also compares the six policy cases, eight recorded stages, CSV copies, RPC ordering and recorded cleanup. This small educational verifier is not an audited wallet library or a complete consensus validator.
The original Core run passed 43 assertions. Its process exited with code zero and its cleanup record states that the fresh directory was removed. An offline reader checks those records, not the former remote process. Fresh reproduction is separate: it requires the pinned Core binaries and creates its own disposable directory and wallets.
Individual files: complete results and PSBTs, five raw candidates, six policy cases, method and limits, source provenance and checksums.
Primary implementation references are Core’s tagged PSBT wallet processing and submission and local acceptance test, with BIP 174 for the container and BIP 143 for the witness signature digest. These sources support the format and operation boundaries; the measurements above come from the published fixture run.
