You pay a Litecoin invoice, type “Order 2048” in a note box and expect the seller to find it beside the incoming payment. The coins arrive, but the seller cannot match them to the order. Before sending again, check what that note box actually does.
In our Litecoin Core 0.21.5.8 experiment, the sender’s payment comments stayed in the sender’s wallet. The recipient received all four payments without acquiring those comments. The three nonempty pairs of notes survived a normal restart at the sender. Their tested text was absent from the serialized transactions.
That result answers a specific question about Core’s sendtoaddress comments. It does not establish how every mobile wallet, exchange or merchant system handles a field called “memo.” A payment-request message, a local contact label and a merchant reference can look similar on screen while travelling through different systems.
What we tested, and what reached the recipient
On 15 October 2026, we started one new Core regtest node with two fresh wallet databases: sender and recipient. They shared the same local chain, while keeping separate wallet records. Automatic peer connections and P2P listening were disabled. No existing wallet, real customer information or real LTC was used.
The sender generated 101 blocks for valueless test funding, then submitted four payments and generated a block after each. For every payment we inspected both wallets’ gettransaction results, decoded the transaction and searched its actual bytes. We then assigned different local address labels, stopped the daemon, restarted it and checked the records again.
The recipient ended with exactly 0.11500000 test LTC: 11,500,000 litoshis. Its four payments had confirmation depths of 4, 3, 2 and 1 at the final height of 105. Those generated blocks are not a measurement of mainnet confirmation speed.
Four notes, four payments, no delivered comment fields
Core accepts an optional comment and an optional comment_to with sendtoaddress. The second is a note naming the recipient; it is not the destination address. In the returned sender record, Core exposed that second value under the key to.
| Case | Note bytes | Received LTC | Recipient comment / to | Tested text in raw bytes |
|---|---|---|---|---|
| N01: empty control | 0 / 0 | 0.01375 | Both absent | Not applicable |
| N02: ASCII invoice markers | 17 / 19 | 0.02125 | Both absent | Neither string found |
| N03: accented text, Japanese and symbols | 35 / 29 | 0.0325 | Both absent | Neither string found |
| N04: long repeated markers | 832 / 608 | 0.0475 | Both absent | Neither string found |
The Unicode case matters because visible characters and stored bytes are different counts. Its main comment had 22 characters but occupied 35 UTF-8 bytes. The long case carried 1,440 bytes across the two local notes. These were deliberately artificial markers, not customer details.
All four generated transactions happened to be 222 bytes and 141 virtual bytes. Their measured sizes did not grow with the long note. That is an observation about these four ordinary Core transactions, not a promise about future transaction sizes, fees or another application’s metadata features.
Where the words were stored
For the ASCII case, the sender’s transaction record included these two fields:
{
"comment": "LW-NOTE-DEMO-2048",
"to": "LW-TO-DEMO-ACCOUNTS"
}They were wallet-record fields alongside information returned by gettransaction. They were not fields inside its hex transaction string. The recipient’s record contained the received output and chain information, but neither of these keys.
The pinned Core wallet source treats the two inputs as wallet metadata. Our downloaded help text from the tested binary describes their scope. The experiment checked the distinction in actual wallet records and serialized bytes rather than inferring delivery from a successful send command.
A useful question for any wallet is therefore: “Who receives this particular field?” A name such as “note” alone does not answer it. Check that wallet’s documentation and the final payment flow, especially when a business depends on the text reaching its system.
Changing a contact label left the payment untouched
We took the ASCII payment’s recipient address and gave it two different labels: LOCAL-SENDER-CONTACT-2048 in the sender wallet and LOCAL-RECIPIENT-ORDER-2048 in the recipient wallet. Each wallet reported its own label for exactly the same address.
The transaction hex remained byte-for-byte identical before and after relabelling. Its transaction ID did not change. The sender’s original comment remained intact, and the recipient still did not acquire it. Both local labels persisted through the daemon restart.
This gives a beginner a practical check: changing a contact name in your own address book is not an instruction to rename somebody else’s incoming payment. A convincing local label also does not prove who controls the destination. Compare the actual address with the authenticated invoice or the person you intend to pay.
The restart result concerns the two existing wallet databases. We did not restore them from a backup, move them to another application or test cloud synchronisation. Do not treat restart persistence as evidence that every export or recovery method preserves the notes.
How to pay an invoice that needs a reference
Suppose a merchant asks for both a Litecoin payment and order reference 2048. Treat those as two things to reconcile unless the merchant documents a payment flow that connects them.
- Read the invoice first. Record the requested asset and network, destination, exact LTC amount and reference. Check whether the merchant expects the reference on its checkout page, through an account or in a separate message.
- Identify your wallet’s field. A Core
commentis not a delivery channel for the merchant’s order number. If another wallet or service requires a memo, tag or payment ID, ask what that field means for the exact asset and network. Do not substitute a local note for a documented service requirement. - Approve the destination and amount. Verify them on the trusted send screen against the invoice. The words you typed beside an address cannot correct a different destination or amount.
- Keep the transaction evidence. After submission, save the transaction ID and identify the merchant’s actual output. Its amount can differ from the transaction’s total output value because another output may return change to you. Our transaction checker helps inspect a published payment.
- Submit the reference where the merchant expects it. Use the invoice page or its normal authenticated support channel to associate order 2048 with that transaction. Check the merchant’s credit status separately from chain confirmation.
If the payment is already confirmed but the order is unmatched, start with the existing transaction ID, recipient output and order reference. A second payment with a more descriptive local comment will not deliver the missing reference through Core’s comment field. Ask the merchant to reconcile the first payment before deciding what to do next.
You can download a blank payment-reference record or its CSV worksheet. It keeps payment evidence and business correspondence together without pretending that the worksheet is transmitted on chain. The receiving-payment checklist covers the wider invoice workflow.
A payment-request message is a different object
A QR code or payment link can contain readable text before any transaction exists. For example, message=invoice%202048 is text in a request’s query string. Anyone with the complete request can inspect that text, even if the eventual transaction does not contain it.
That does not establish where a particular wallet will display, save or forward the field. Our earlier Electrum-LTC and Cake parser study measured how selected request fields were parsed, without executing their complete send flows. It answers a separate question from this Core send-and-restart experiment.
| Text surface | What to establish | Evidence here |
|---|---|---|
| Core send comment | Whether it enters transaction bytes or another wallet record | Three nonempty pairs stayed with the sender; tested strings absent from raw bytes |
| Local address label | Which wallet’s address book changed | Two separate labels; same transaction bytes |
| Payment-request message | Who can read the shared request and what the receiving app does with it | Not executed in this experiment |
| Merchant reference | How the merchant associates a payment with its order | No merchant account or credit system tested |
The QR inspector can help you inspect a request’s contents. It cannot prove that a merchant received an order number or credited a payment.
Local does not mean that nobody else can learn the note
Our byte searches are not a general privacy guarantee. They show that these exact nonempty note strings and their prefixes were absent from these ordinary transaction bytes. Other software can deliberately attach data or transmit information through a separate service; neither behaviour was tested here.
A note might also be exposed through a screenshot, shared wallet record, export or backup. A merchant can store the reference submitted through its own website. We did not audit those systems, their encryption or their retention. Avoid putting recovery secrets, passwords or unnecessary customer information in a payment note.
Nor does the missing note hide the payment’s ordinary transparent outputs. Someone can still inspect transaction amounts and scripts or associate an address with information learned elsewhere. This experiment makes no claim about MWEB, complete wallet privacy or who can identify a payer.
Verify the records and repeat the test
Download the complete version 1 research package to run the offline check with all its input files. Individual files include the results JSON, case table CSV, RPC transcript, experiment runner and method and limitations. The run recorded 92 passing assertions.
The separate export verifier checks the frozen records offline. Without running Core or contacting a network, it reconstructs transaction IDs and witness IDs, calculates virtual sizes, checks recipient outputs in integer litoshis and searches the note strings. It also compares the metadata with the recorded RPC calls.
python verify.py.txt .File hashes are in SHA256SUMS.txt. The verifier checks the supplied records and arithmetic; it does not verify signatures or provide an independent witness to execution. Reproduction needs the pinned Core binaries and a fresh output directory. All published addresses and transaction IDs belong to regtest, not mainnet.
The primary implementation references are the Core 0.21.5.8 release, its wallet RPC implementation and raw-transaction RPC implementation. Source snapshots and their hashes accompany the downloads.
Measured 15 October 2026. AI-assisted research, code and drafting; no independent human review or funded-account test claimed. Only ordinary transparent Core payments were exercised, with one isolated node and two fresh wallet databases.
