Theft BTC via a test transaction
First, a simple explanation; then, a technical analysis
You're told, "The transfer is on hold. Pay the fee, and the money will be transferred." You're expecting a small payment, click "Confirm," and then realize that a completely different amount has been deducted from your wallet.
In one variation of this scam, the scammer sets up a transaction in advance—a transfer of your BTC to their address. They present it to you as a “commission payment” or “unlock fee.” If you confirm and sign that specific transfer, you’re giving permission to send the money yourself. The network executes the signed transaction, not the promise made by the person who sent it.
Simply put: you think you’re only paying a fee, but in reality, you may be authorizing a transfer of your BTC. The catch is in what you’re actually confirming. The button label and the small amount shown on the website don’t necessarily mean that your wallet is authorizing only a small payment.
There is another possibility: the required signature has already been obtained, or the scammer already knows the wallet key. In that case, the prepared transfer may be sent later. Paying an additional fee sometimes simply serves to confirm a debit that has already been authorized.
But without a signature or some other valid authorization to spend your BTC, this scheme doesn't work. If you simply pay for a single transaction from your secure wallet, the recipient does not gain access to the rest of your balance. Therefore, the story about “someone paid the fee—and everything was automatically debited from someone else’s account” misses the key point: where the authorization to debit the funds came from.
Now let’s break down what might be behind this story: PSBT, change swapping, SIGHASH mode, a nonce error, and a key leak. These are different possible mechanisms, not necessarily the stages of a single attack. The specific scenario is determined based on the transactions and the owner’s actions.
The balance Bitcoin consists of unspent transaction outputs (UTXOs). A new transaction spends specific UTXOs and creates new outputs. The difference between the sum of inputs and the sum of outputs is the transaction fee. A low transaction fee may delay confirmation but does not grant permission to spend other funds.
It is important to distinguish between a prepared file, a signed transaction, a transaction in the mempool, and a transaction included in a block. A PSBT with an incomplete set of signatures is not necessarily ready to be sent. The “pending” status on the website does not, in and of itself, prove that the transaction exists on the network.
A fully signed transaction can be broadcast to the network at a later time. Therefore, spendability sometimes occurs long before the transaction appears to be debited. The disappearance of a record from the mempool or the deletion of a file from the interface does not mean that another participant no longer has a copy of the signature.
Fraud in the Signing of the PSBT
PSBT is a standard data exchange format for partially signed Bitcoin transactions. It allows the preparation of a transaction and the generation of signatures to be separated, including when working with a hardware wallet. The format itself is not malicious. The risk arises if a user signs a transaction prepared by a third party without verifying its contents.
Before confirming a transaction, it is essential to verify the recipients, amounts, fees, and change destination. BIP 174 describes input validation, SIGHASH validity checks, and change destination verification. A hardware device is only useful when used in conjunction with data verification on its trusted display.
Change of Drop-off Address
When an UTXO is spent, its full value is used. If the payment amount is less than that value, the remainder is typically returned to the owner as a separate change output. For example, with an input of 1 BTC, a payment of 0.01 BTC, and a fee of 0.0001 BTC, the change is 0.9899 BTC.
If, in a prepared transaction, this balance is sent to an unauthorized party and the owner confirms the transfer, the owner loses the bulk of the amount, even though the expected small payment also goes through. This is a hypothetical example, not a description of an actual incident.
With a standard signature that records all outputs, you cannot simply change the delivery address after signing and still keep the same signature valid. The change must be included in the data being signed or require a new confirmation. For a signature with a different scope, the result depends on its mode and the other signatures.
Why the SIGHASH mode matters
SIGHASH specifies which parts of a transaction the signature protects against modification. Different modes are available for classic and SegWit v0 transactions. These are defined by the protocol, so the term “non-standard” here refers to something unusual for a specific user action, not something that is automatically invalid.
| Mode | What You Need to Understand |
| SIGHASH_ALL | Records all outgoing transactions, including recipients and amounts. |
| SIGHASH_NONE | It does not secure the outputs. They may be protected by other signatures. |
| SIGHASH_SINGLE | Locks the corresponding output; protection of the others depends on other signatures. |
| ANYONECANPAY | Restricts the binding to inputs to the signed input. Output protection depends on the base mode. |
The source for the table is BIP 143 and the Bitcoin Developer Guide.
A signature with a limited scope of protection does not grant access to the entire wallet; it applies only to a specific transaction. However, the owner’s expectations may extend beyond the guarantees provided by this signature. Therefore, any unusual behavior during a routine payment requires a clear explanation. For Taproot, signature rules must be verified separately.
Nonce Generation Error in ECDSA
A secret nonce value k is used when creating an ECDSA signature. This is neither a commission nor a transaction counter. Reusing the same k for different messages signed with the same key, disclosing it, or certain generation errors could allow the private key to be recovered. The mere existence of public signatures does not, in and of itself, create such a possibility.
Once the key has been recovered, new signatures may be generated to spend the funds it protects. In this case, the cause of the loss is a defect in the signing software, not the actions of the person paying the fee. A single vulnerable signature does not necessarily reveal all keys derived from the seed phrase.
RFC 6979 describes deterministic nonce generation; the libsecp256k1 library supports this approach. In a correct deterministic implementation, re-signing the same message cannot automatically be equated with a dangerous repetition of the nonce for different messages.
ECDSA does not cover all modern Bitcoin transactions. Taproot uses Schnorr signatures as defined in BIP 340. Nonce security remains significant, but it is not possible to apply the description of a specific ECDSA vulnerability to any address without verifying the spending type.
A wallet that has already been compromised
If a private key or seed phrase is already known to a third party, that party does not need to obtain the owner’s signature again. An example of this is importing a seed phrase provided by someone else: such a wallet cannot be considered to be under the sole control of the recipient. A similar risk arises if a backup is leaked or if a fake wallet is used.
Transferring funds to such a wallet may precede their spending by another key holder. In this case, the request to “top up for the fee” serves as an explanation for the user, and the ability to deduct the fee existed previously. In Bitcoin, the fee is included in the BTC transaction; there is no separate mandatory gas token for a standard BTC transfer.
Knowing a single private key and knowing the entire seed phrase have different levels of impact. In the first case, the funds whose spending conditions allow the use of that key are at risk. In the second case, potentially many derived wallet keys are at risk. The statement “all the money will be stolen” requires verification of the UTXO structure and the permissions available to the attacker.
What roles do RBF and CPFP play?
RBF allows an unconfirmed transaction to be replaced with a conflicting transaction that satisfies the node's rules, typically in exchange for a higher fee. The replacement must also be valid: increasing the fee does not waive the signature and spending requirements.
CPFP uses a child transaction that spends an output from an unconfirmed parent transaction. Its fee can make confirming the associated block more attractive to a miner. The participant must have the right to spend the selected output; creating a child transaction does not authorize them to arbitrarily alter a transfer from someone else’s wallet.
Consequently, acceleration can help confirm an unwanted transaction that has already been approved. However, it does not create the approval itself. A confirmation delay and a theft of funds are different events, even if the user perceives them as a single transaction involving a fee.
What to Check in a Specific Case
The term “Retention Address” or “Retention Attack” does not, in and of itself, define the spending conditions in Bitcoin. “Retention Address” may be an internal term used by the service. You need to examine the script, the transaction, and the participants’ permissions, not the name of the address. Without this information, it is incorrect to associate “Retention” with a specific vulnerability.
To determine the cause, you’ll need the TXIDs of the original and subsequent transactions, the list of inputs and outputs, the amounts, the addresses, the wallet name, and the confirmation sequence. If a PSBT was transmitted, a copy of it prior to signing is helpful. A screenshot showing the balance or the word “Retention” does not substitute for this data.
The main question is: where did the spending authorization come from? If the owner signed the file, the signed data and the SIGHASH are verified. If there was no signature, a key leak, the origin of the seed phrase, and the application’s behavior are investigated. A transaction substitution requires verification of the recipient of the balance. A nonce error requires analysis of the relevant signatures and implementation, rather than speculation about the delay.
Before confirming the transaction again, check the total amounts, fees, recipients, and change in your trusted wallet. Never enter your seed phrase or private keys on “activation” websites. If you suspect that your seed phrase has been compromised, protecting your remaining funds requires creating a new wallet with a new seed phrase on a trusted device. For investigation purposes, save your chat history, files, and transaction details without revealing your private keys.
Technical conclusion: The theft is explained by the ability to create or use a valid spending authorization. The Commission influences the conditions for confirmation but does not provide control over others’ BTC. Until transactions are verified, the mechanisms listed remain alternative explanations, and “Retention” remains an undefined term.
Sources
Documentation Bitcoin and primary technical materials
https://Bitcoin.org/en/how-it-works
https://developer.Bitcoin.org/devguide/transactions.html
https://www.rfc-editor.org/rfc/rfc6979
https://github.com/Bitcoin-core/secp256k1/blob/master/README.md
https://github.com/Bitcoin/Bitcoin/blob/master/doc/policy/mempool-replacements.md
https://Bitcoincore.reviews/24152