A Litecoin signature can be valid even when the address has no coins, the message has expired and somebody has copied the response from an earlier request. We tested all three conditions in an isolated Litecoin Core experiment. The signatures still verified where the address, exact text and signature matched.
That does not make message signing useless. It makes the question precise: are you checking a signature, or deciding what that signature permits? Those are separate jobs. A readable, newly issued challenge can help demonstrate control of a particular address. An old signature, shown without its original purpose, can be misleading.
This beginner guide explains what to inspect before signing, how to check somebody else’s proof and where the evidence stops. Our downloadable experiment used fresh, zero-funded regtest wallets. It did not test a real account, login, identity or reserve claim.
Read the request before opening a signing screen
First establish who is asking and what they intend to do with your response. “Prove your wallet” is too vague. Ask for the specific address, the signing format they support and a plain-language explanation of the action the proof will allow. Use the service’s official authenticated channel rather than following an unexpected private message.
A useful challenge identifies the requesting service or site, the purpose, the exact address, a newly issued one-use nonce and an expiry with its timezone. A nonce is a value that distinguishes this request from another. Our experiment uses public, deterministic 64-character hexadecimal fixture nonces; a real application must generate its own unpredictable challenges and remember which ones it has accepted.
- Read the entire message. It should describe the request you agreed to. If it contains an unfamiliar action, approval or opaque payload, stop and ask what is being authorized.
- Check the signing feature. Use your wallet’s documented message-signing function and a compatible address format. A transaction, PSBT or spending approval is a different operation. A page calling everything a “signature” is not enough information.
- Check the context. Compare the service, purpose, address, nonce and expiry against the actual request. A date written in the message does not enforce itself.
- Keep secrets inside the wallet. A verifier needs the public address, exact message and signature. It does not need your seed, private key, wallet password or backup.
You can decline a request you do not understand. A valid signature can be used as an off-chain statement or application permission even though this particular Core message-signing operation does not create a Litecoin payment.
What the signature establishes is narrower than “ownership”
For the tested legacy format, verification connects the exact message to the key associated with a specified address. The underlying signature demonstrates that the corresponding signing key was usable to produce it. Verification alone does not identify the person who operated that key, establish when they signed or show that only one person has a copy.
| Question | What a valid signature supports | What it does not establish alone |
|---|---|---|
| Does this exact text match this address’s signing key? | The matching signature verifies under the selected format. | The signer’s legal identity or rightful ownership. |
| Is this a fresh response to my request? | The signed text contains a particular challenge. | Freshness without checking that you issued it and have not accepted it before. |
| Does the signer hold a claimed balance? | Nothing about a balance is needed for this signature. | Current funds, reserves, liabilities or control of every address in a wallet. |
| Did Litecoin move? | This message-signing result is a public proof about text. | A payment, confirmation or recipient credit. |
A copied response can carry a valid signature. An attacker who obtained a signing key could also create one. A person might ask a custodian or another key holder to sign. These possibilities are why a signature should answer a specific request, rather than stand in for a broad identity or financial claim.
We tested a zero-funded address, exact text and a replay
Our experiment ran on 15 October 2026 at 22:53 UTC, which was already 16 October in Warsaw. It used the pinned Litecoin Core 0.21.5.8 binaries, one fresh regtest node and two fresh wallets: a signer and a wallet with private keys disabled. Peer networking was disabled, RPC stayed on loopback and no blocks were mined.
The signer created a legacy address with no funds. We signed a readable challenge naming litecoin.watch, its purpose, that address, a fixture nonce and an expiry of 2026-10-15T00:00:00Z. The expiry was already in the past. The exact signature verified; submitting the identical address, text and signature again also verified.
The signer’s recorded balance was zero before and after. The node remained at block height zero with an empty mempool, and the signer’s transaction history remained empty. No payment or miner fee was created by these message-signing operations. That is a controlled software observation, not evidence that an arbitrary website’s approval screen is safe.
One invisible change can turn true into false
We recorded eleven verifier calls. Each one supplied a specific address, message and signature to Core. When text was changed without a new signature, we preserved the original signature rather than signing the edited text. A separate UTF-8 message and a new future-dated challenge were signed deliberately for their exact-text tests.
| Case | Input supplied to the verifier | Observed result |
|---|---|---|
| S01 | Exact original legacy address, message and signature | True |
| S02 | One purpose word changed | False |
| S03 | Another legacy address, original text and signature | False |
| S04 | Identical original triple replayed | True |
| S05 | Another nonce substituted, original signature | False |
| S06 | A trailing newline appended | False |
| S07 | LF line endings changed to CRLF | False |
| S08 | A trailing space appended | False |
| S09 | Exact UTF-8 message containing café and zażółć | True |
| S10 | That UTF-8 text normalized to visually similar NFD characters | False |
| S11 | A newly signed readable challenge | True |
Text that looks the same is not necessarily the same sequence of bytes. For example, an accented character can be represented as one character or as a base letter followed by a combining mark. Our S10 test changed that representation. S07 changed the bytes used for line endings.
If verification fails, obtain the original exact text rather than trying to fix its punctuation, spacing or line breaks by eye. Copying a screenshot into a text editor can introduce changes. A failure can mean an altered message or a format mismatch; it is not automatically proof of fraud.
Expiry and one-use rules belong to the application
Our expired message did not fail Core’s cryptographic check because the date was simply part of the signed text. The verifier did not interpret it as a deadline. Likewise, a second verification of identical inputs did not consume the signature. It returned true again.
We therefore built a separate, explicitly fictional application-policy model. It requires a valid signature, compares the expected service, purpose, address and nonce, checks the deadline and rejects a nonce already recorded as used. It illustrates additional checks; it is not a tested login service or a complete authentication implementation.
| Model case | Cryptographic input | Declared application condition | Model result |
|---|---|---|---|
| M01 | Valid signature | Expected fresh challenge, unused nonce | Accept once |
| M02 | Same valid signature | Nonce already used | Reject replay |
| M03 | Valid original signature | Deadline already passed | Reject expired |
| M04 | Valid signature | Different service expected | Reject context |
| M05 | Valid signature | Different nonce expected | Reject context |
| M06 | Failed signature check | Other checks cannot rescue it | Reject signature |
The model uses frozen checking times and explicit previously used nonce lists. It does not operate a live account or store a real user session. Its future-dated fixture was fresh when created; it is not an active challenge for readers.
If somebody sends you an old “proof of ownership,” issue a new request for your own purpose and verify the response independently. Adding a fresh nonce to an already signed message will invalidate the old signature, as S05 showed. You need a response signed over the new exact message.
A signing error and an empty balance mean different things
The funded status of an address did not determine whether our signer could sign. It had the key but no coins, and signing succeeded. Our second wallet knew the public legacy address but had private keys disabled. Its signing attempt returned -4, “Private key not available.” Knowing or watching an address is different from being able to sign for it.
We also asked this Core version’s legacy signmessage RPC to sign for an ordinary native-SegWit address. It returned -3, “Address does not refer to key.” That is a limitation of the particular utility and format we tested. It does not establish that every wallet or message-signing protocol rejects SegWit addresses.
Do not move funds or export a private key just to work around a proof-request format. Ask the requester and your wallet’s documentation which proof method they both support. An unsupported operation is not evidence that your wallet has lost its keys.
Checking this legacy message signature does not require downloading the whole blockchain; our independent verifier works offline. Determining current balances is another problem that requires appropriate chain information. The companion guide on whether a wallet needs the whole Litecoin blockchain explains that distinction.
Check a proof without trusting its screenshot
Ask for three public items: the exact address, the exact signed message and the signature, plus the signing format used. Verify them with a compatible tool you trust. Do not accept a screenshot of somebody else’s green checkmark as a substitute for the actual inputs.
Then compare the message with the challenge you issued. Was it intended for your service and purpose? Is it the expected address and nonce? Is it still within the stated validity period? Has your system already accepted that challenge? A cryptographic true result does not answer those application questions.
Keep a private record of the request and response where appropriate. Addresses and signatures are public proof material rather than spending secrets, but publishing them can link an address to a person, a service or a particular statement. A request for a seed or private-key export is not normal message verification.
The printable challenge checklist and blank request template help record those questions. They contain no live challenge, account approval or payment instruction. Our wallet directory can help you find the wallet’s official documentation; message-signing support must be checked for the exact wallet and format.
Inspect the original evidence and reproduce the checks
Download the version 1 research package and run python verify.py.txt with Python 3.10 or later. It needs no wallet, Core binary, private material or network connection, and writes nothing to the package.
The verifier independently recovers public keys from the compact signatures, computes the legacy Litecoin message hash and compares the address. It checks all eleven exact-message cases, UTF-8 bytes, CSV results and the separate application model. The original Core experiment passed 32 assertions. The offline program checks the recorded cleanup flags; it cannot inspect the former remote process or filesystem.
This small pure-Python verifier is educational, not an audited authentication library. Fresh reproduction is a separate program that requires the pinned Core binaries and creates new disposable wallets. It never accepts an existing data directory or wallet. New keys, signatures and future expiry times can differ from our frozen run.
Individual files: measured results, eleven-case CSV, exact original message, separate model cases, method and limits and checksums.
Primary references: the tagged Core wallet signing implementation, verification RPC and message-hash and public-key recovery code, compared with help from the tested runtime. The package contains generated public fixtures and public wallet metadata, not seeds, private keys, wallet files or private descriptors. It makes no identity, reserve, mainnet, hardware-wallet or security-audit claim.
