<p>For standard pre-Segwit transaction patterns (e.g. <code>P2PK</code>,<code>P2PKH</code>,<code>P2MS</code>), the typical procedure is that Alice would sign a transaction template that includes the new transaction's exact output(s). For the signature to be verifiable, those outputs must be included as they are. So Charlie's new transaction with different outputs would not have a verifiable signature, and thus would be invalid.</p>
<p>There are ways to construct signatures in which the outputs are left open, however. Which of the <a href="https://bitcoin.stackexchange.com/questions/122893/hashtypecode-sighash-flag-example-byte-arrays-for-each-type">six possible</a> configurations of inputs and outputs that are signed can be set using the <a href="https://bitcoin.stackexchange.com/a/122882/34190">hashTypeCode</a> (a.k.a SigHash flag). If Alice decided to use the <code>SIGHASH_NONE</code> flag, for example, the outputs would not be signed and Charlie (or anyone) could spend the new outputs.</p>
<p><a href="https://bitcoin.stackexchange.com/a/93836/34190">For Segwit transactions (e.g. <code>P2WPKH</code>) a refined version of the procedure is used</a>. See <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">BIP143</a>.</p>

CC BY-SA 4.0
2024-05-05T08:34:23.150Z
2024-05-05T09:00:04.690Z
2024-05-05T09:00:04.690Z
Lee
<p>A cryptographic signature is only verifiable and valid in the context of the message that is being signed. In Bitcoin, the signed message is the <em>transaction commitment</em> (aka <em>sighash</em>). You can think of the transaction commitment as a fingerprint of the complete transaction. Generally, it commits to the entire transaction including all inputs and all outputs. If an output on the transaction is changed, its transaction commitment no longer matches the signed transaction commitment, and the signature is invalid in the context.</p>
<p>Due to the transaction commitment, generally, no third party can change the outcome of the transaction. For advanced transactions, sometimes signers will only commit to less than the complete transaction to allow other users to fill in parts of the transaction, but you can rely on your wallet software to always commit to the entire transaction unless you specifically instruct it otherwise.</p>

CC BY-SA 4.0
2024-05-06T12:47:58.500Z
2024-05-06T12:47:58.500Z
Murch
<p>New to Bitcoin. Looking at a tx structure, the input is signed to &quot;unlock&quot; it. What prevents an attacker from taking this and then spending as they wish? That is, Alice wants to send 1 BTC to Bob out of 2 BTC she has (the output of some other tx), so she creates a tx with her signature on the 2 BTC and 2 outputs: 1 to Bob, 1 to herself (neglecting fee here). Just before transmitting the tx, Charlie sniffs the signature, creates a new tx referencing those 2 BTC and with Alice's signature, and where the output is to him and sends it. What prevents him from doing so?</p>

<transactions><signature>
Security of spending
IttayD
# Security of spending

(Asked by: username_0 on 2024-05-05)

New to Bitcoin. Looking at a tx structure, the input is signed to "unlock" it. What prevents an attacker from taking this and then spending as they wish? That is, Alice wants to send 1 BTC to Bob out of 2 BTC she has (the output of some other tx), so she creates a tx with her signature on the 2 BTC and 2 outputs: 1 to Bob, 1 to herself (neglecting fee here). Just before transmitting the tx, Charlie sniffs the signature, creates a new tx referencing those 2 BTC and with Alice's signature, and where the output is to him and sends it. What prevents him from doing so?

**Tags:** transactions, signature


---

## 2 answers

### Answer by username_1 on 2024-05-05. Score: 2 | Accepted answer

For standard pre-Segwit transaction patterns (e.g. `P2PK`,`P2PKH`,`P2MS`), the typical procedure is that Alice would sign a transaction template that includes the new transaction's exact output(s). For the signature to be verifiable, those outputs must be included as they are. So Charlie's new transaction with different outputs would not have a verifiable signature, and thus would be invalid.

There are ways to construct signatures in which the outputs are left open, however. Which of the [six possible](https://bitcoin.stackexchange.com/questions/122893/hashtypecode-sighash-flag-example-byte-arrays-for-each-type) configurations of inputs and outputs that are signed can be set using the [hashTypeCode](https://bitcoin.stackexchange.com/a/122882/34190) (a.k.a SigHash flag). If Alice decided to use the `SIGHASH_NONE` flag, for example, the outputs would not be signed and Charlie (or anyone) could spend the new outputs.

[For Segwit transactions (e.g. `P2WPKH`) a refined version of the procedure is used](https://bitcoin.stackexchange.com/a/93836/34190). See [BIP143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki).


---

### Answer by username_2 on 2024-05-06. Score: 1

A cryptographic signature is only verifiable and valid in the context of the message that is being signed. In Bitcoin, the signed message is the *transaction commitment* (aka *sighash*). You can think of the transaction commitment as a fingerprint of the complete transaction. Generally, it commits to the entire transaction including all inputs and all outputs. If an output on the transaction is changed, its transaction commitment no longer matches the signed transaction commitment, and the signature is invalid in the context.

Due to the transaction commitment, generally, no third party can change the outcome of the transaction. For advanced transactions, sometimes signers will only commit to less than the complete transaction to allow other users to fill in parts of the transaction, but you can rely on your wallet software to always commit to the entire transaction unless you specifically instruct it otherwise.


---

