<h1>These things cannot change:</h1>
<p>Usually* a bitcoin transaction includes a signature to confirm the following things:</p>
<ol>
<li>Input</li>
<li>Output</li>
</ol>
<p>An input or output specifies both an address and an amount. If either of these things change, then a new signature will be needed, which can only be created by someone who has the private key. Changing the input or the output will invalidate the signature. Only the owner of the private key can make such a change, being the only one who can create the new signature. Even then, this would create an entirely new transaction which could not be mistaken for the original.</p>
<p>The <a href="https://en.bitcoin.it/wiki/Transaction_Malleability" rel="nofollow noreferrer">thing which <strong>can</strong> be changed</a> prior to the transaction being included in the blockchain is the transaction id. Changing this can cause confusion for anyone who accepts unconfirmed transactions, but it cannot change the input or output - it is just a label. For people who only accept confirmed transactions, the transaction will already be in the blockchain, where nothing can be altered so there is no opportunity for confusion.</p>
<h1>In conclusion:</h1>
<ul>
<li>Your transaction which hasn't been included in the blockchain yet is safe from having its input or output changed. Neither addresses nor amounts can be changed or added to.</li>
<li>Once your transaction is included in the blockchain** it is safe from having <strong>anything</strong> changed, so you can safely refer to it by its transaction id without any potential for confusion.</li>
</ul>
<hr />
<h1>Extra info</h1>
<p>I was aiming for a simple explanation so I have not included detail of transactions with multiple inputs with different private keys, but the same applies. No third party can make alterations other than the transaction id, which does not affect what bitcoin amount is transferred or where it is transferred from and to.</p>
<p>The explanation above applies to standard transactions. Producing a transaction to which these protections do not apply would require either specialist software or an in depth understanding. For further detail on transactions see the following:</p>
<ul>
<li><a href="https://en.bitcoin.it/wiki/Transactions" rel="nofollow noreferrer">Bitcoin Wiki page on transactions</a> (technical detail on how the signing process works)</li>
<li>[Bitcoin Wiki page on CHECKSIG](<a href="https://en.bitcoin.it/wiki/OP_CHECKSIG" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/OP_CHECKSIG</a> (inner workings of a signature)</li>
</ul>
<p>*<em>While it is possible to deliberately create a transaction which does not specify inputs, or even one which does not specify outputs, I am assuming that the question concerns the usual process of creating a transaction from specified input(s) to specified output(s).</em></p>
<p>**<em>By &quot;included in the blockchain&quot; I mean included with however many confirmations you consider sufficient for your purposes. If a transaction has only one confirmation then it is still possible that the block it has been included in will become orphaned later. With each additional confirmation the risk of this happening decreases considerably.</em></p>

CC BY-SA 3.0
2014-03-16T16:22:26.040Z
2014-03-16T17:02:26.940Z
2020-06-16T11:10:03.350Z
trichoplax is on Codidact now
<p>You can't, it would create a completely different transaction and the other would get invalidated as soon as one makes it to a miner and into a block. </p>

CC BY-SA 3.0
2014-03-12T20:23:18.237Z
I'm confused, are you saying this isn't possible, or are you saying that it is possible and it would simply make the first transaction invalid?
bvpx
CC BY-SA 3.0
2014-03-12T20:48:36.410Z
My bad, the second paragraph was confusing. I'm saying the second transaction will be invalid because of conflicting inputs.
John T
CC BY-SA 3.0
2014-03-12T21:40:40.930Z
I was under the impression that transaction malleability was possible due to there being no order of transactions enforced (before a block is mined with that transaction in it). Is it possible for the second larger transaction to be put in a block?
bvpx
CC BY-SA 3.0
2014-03-12T23:05:36.773Z
Once a transaction is in a block or even in a miner's memory pool, all conflicting transactions are invalid. There are no input duplicates ever in the blockchain. Transaction malleability creates two TXIDs that point to the same transaction, but only one can be valid and placed in a block. Accepting both as valid is where exchanges lose money.
John T
CC BY-SA 3.0
2014-03-14T19:33:32.153Z
My question specifically references transactions that are not mined yet. The question is whether or not it is possible to edit the raw transaction to add inputs and outputs before the transaction is mined because each input is signed individually. I am not asking about duplicate inputs, I'm asking whether or not it's possible to add inputs and outputs to a transaction that hasn't been mined yet, with the hopes of re-broadcasting it to pools to have it mined before the "host" transaction is mined. I can't find anything in the protocol that would technically stop this from happening.
bvpx
CC BY-SA 3.0
2014-03-12T19:35:17.257Z
2014-03-12T20:47:49.187Z
2014-03-12T20:47:49.187Z
John T
<p>Short answer: no, this is impossible.</p>

<p>Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead.</p>

<p>Typically, when normal SIGHaSH_ALL signatures are used, pretty much everything of a transaction is signed (which input coins are used (and in which order), what output scripts are created, what value to assign to them, ... Everything except the signatures themselves really (which is what causes involuntary malleability).</p>

<p>If an input signature is marked ANYONECANPAY, it does not sign the other input coins being used. This means you can create a transaction meaning "i want x and y to be paid, but i don't care who provides the funds to do so". If all signatures in a transactioon are ANYONECANPAY, you could add extra inputs (or remove existing inputs. Just increasing the input funds would just burn them as fee, though.</p>

<p>On the other side, there is SIGHASH_NONE, which makes a signature not sign the transaction's outputs. This may seem to allow what you want to, but in case every signature is SIGHASH_NONE, the treansaction is completely unsafe, as anyone could replace where the outputs go.</p>

<p>So, even if a combination of those would in theory allow what you suggest, it is not true for typical tramsactions, amd would in fact be completely unsafe.</p>

CC BY-SA 3.0
2014-03-22T10:30:53.887Z
Thanks. I have looked at the code for over an hour and I still don't see where the outputs are signed, though. I am specifically looking here: https://github.com/bitcoin/bitcoin/blob/master/src/rpcrawtransaction.cpp#L703 ... it seems only inputs are signed? Can you point to a line of code that makes it clear that transaction outputs are signed as well?
bvpx
CC BY-SA 3.0
2014-03-22T10:35:20.200Z
Also, I can "just believe you", but I don't see anything in the code that prevents the type of behavior I am asking about. Specifically, **what** is preventing someone from adding an input to an un-mined SIGHASH_ALL transaction? Saying "everything is signed" doesn't fully answer my question, I feel like I am missing something important. Are all inputs signed with every private key that is listed in the transaction? From what I can tell, each input is signed individually and the data of that signature is stored independently from the other input signatures.
bvpx
CC BY-SA 3.0
2014-03-23T01:18:40.723Z
Every input is contains a signature, using the key needed by the script of the output being spent by that input. However the data being signed is (a modified version of) the entire transaction. Adding an extra input to a transaction would invalidate any SIGHASH_ALL inputs to it, as the data being signed changes.
Pieter Wuille
CC BY-SA 3.0
2014-03-16T16:07:30.970Z
2014-03-16T16:07:30.970Z
Pieter Wuille
<p>Is it possible to add an input to a transaction that is in the mempool?</p>

<p>For example, if someone is paying 1 BTC to their friend, I can get the raw hex data of this transaction from the mempool before it is mined.</p>

<p>I can then sign an unspent transaction (Let's say 3 BTC) with my own private key, list it as an input, and get the raw hex data for this. Then, I can add a 3 BTC output to someone else's address (who I want to pay), and re-broadcast this new transaction to the network.</p>

<p>What is stopping this from happening?</p>

<transactions><signature><transaction-verification><transaction-malleability><mempool>
Is it possible to add a transaction input to a transaction in the mempool?
bvpx
# Is it possible to add a transaction input to a transaction in the mempool?

(Asked by: username_0 on 2014-03-12)

Is it possible to add an input to a transaction that is in the mempool?

For example, if someone is paying 1 BTC to their friend, I can get the raw hex data of this transaction from the mempool before it is mined.

I can then sign an unspent transaction (Let's say 3 BTC) with my own private key, list it as an input, and get the raw hex data for this. Then, I can add a 3 BTC output to someone else's address (who I want to pay), and re-broadcast this new transaction to the network.

What is stopping this from happening?

**Tags:** transactions, signature, transaction-verification, transaction-malleability, mempool


---

## 3 answers

### Answer by username_3 on 2014-03-16. Score: 5 | Accepted answer

Short answer: no, this is impossible.

Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH\_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead.

Typically, when normal SIGHaSH\_ALL signatures are used, pretty much everything of a transaction is signed (which input coins are used (and in which order), what output scripts are created, what value to assign to them, ... Everything except the signatures themselves really (which is what causes involuntary malleability).

If an input signature is marked ANYONECANPAY, it does not sign the other input coins being used. This means you can create a transaction meaning "i want x and y to be paid, but i don't care who provides the funds to do so". If all signatures in a transactioon are ANYONECANPAY, you could add extra inputs (or remove existing inputs. Just increasing the input funds would just burn them as fee, though.

On the other side, there is SIGHASH\_NONE, which makes a signature not sign the transaction's outputs. This may seem to allow what you want to, but in case every signature is SIGHASH\_NONE, the treansaction is completely unsafe, as anyone could replace where the outputs go.

So, even if a combination of those would in theory allow what you suggest, it is not true for typical tramsactions, amd would in fact be completely unsafe.

> **Comments:**
> **username_0**: Thanks. I have looked at the code for over an hour and I still don't see where the outputs are signed, though. I am specifically looking here: https://github.com/bitcoin/bitcoin/blob/master/src/rpcrawtransaction.cpp#L703 ... it seems only inputs are signed? Can you point to a line of code that makes it clear that transaction outputs are signed as well?  
> **username_0**: Also, I can "just believe you", but I don't see anything in the code that prevents the type of behavior I am asking about. Specifically, **what** is preventing someone from adding an input to an un-mined SIGHASH_ALL transaction? Saying "everything is signed" doesn't fully answer my question, I feel like I am missing something important. Are all inputs signed with every private key that is listed in the transaction? From what I can tell, each input is signed individually and the data of that signature is stored independently from the other input signatures.  
> **username_3**: Every input is contains a signature, using the key needed by the script of the output being spent by that input. However the data being signed is (a modified version of) the entire transaction. Adding an extra input to a transaction would invalidate any SIGHASH_ALL inputs to it, as the data being signed changes.  

---

### Answer by username_1 on 2014-03-16. Score: 0

# These things cannot change:

Usually\* a bitcoin transaction includes a signature to confirm the following things:

1. Input
2. Output

An input or output specifies both an address and an amount. If either of these things change, then a new signature will be needed, which can only be created by someone who has the private key. Changing the input or the output will invalidate the signature. Only the owner of the private key can make such a change, being the only one who can create the new signature. Even then, this would create an entirely new transaction which could not be mistaken for the original.

The [thing which **can** be changed](https://en.bitcoin.it/wiki/Transaction_Malleability) prior to the transaction being included in the blockchain is the transaction id. Changing this can cause confusion for anyone who accepts unconfirmed transactions, but it cannot change the input or output - it is just a label. For people who only accept confirmed transactions, the transaction will already be in the blockchain, where nothing can be altered so there is no opportunity for confusion.

# In conclusion:

* Your transaction which hasn't been included in the blockchain yet is safe from having its input or output changed. Neither addresses nor amounts can be changed or added to.
* Once your transaction is included in the blockchain\*\* it is safe from having **anything** changed, so you can safely refer to it by its transaction id without any potential for confusion.

---

# Extra info

I was aiming for a simple explanation so I have not included detail of transactions with multiple inputs with different private keys, but the same applies. No third party can make alterations other than the transaction id, which does not affect what bitcoin amount is transferred or where it is transferred from and to.

The explanation above applies to standard transactions. Producing a transaction to which these protections do not apply would require either specialist software or an in depth understanding. For further detail on transactions see the following:

* [Bitcoin Wiki page on transactions](https://en.bitcoin.it/wiki/Transactions) (technical detail on how the signing process works)
* [Bitcoin Wiki page on CHECKSIG](<https://en.bitcoin.it/wiki/OP_CHECKSIG> (inner workings of a signature)

\**While it is possible to deliberately create a transaction which does not specify inputs, or even one which does not specify outputs, I am assuming that the question concerns the usual process of creating a transaction from specified input(s) to specified output(s).*

\*\**By "included in the blockchain" I mean included with however many confirmations you consider sufficient for your purposes. If a transaction has only one confirmation then it is still possible that the block it has been included in will become orphaned later. With each additional confirmation the risk of this happening decreases considerably.*


---

### Answer by username_2 on 2014-03-12. Score: 0

You can't, it would create a completely different transaction and the other would get invalidated as soon as one makes it to a miner and into a block.

> **Comments:**
> **username_0**: I'm confused, are you saying this isn't possible, or are you saying that it is possible and it would simply make the first transaction invalid?  
> **username_2**: My bad, the second paragraph was confusing. I'm saying the second transaction will be invalid because of conflicting inputs.  
> **username_0**: I was under the impression that transaction malleability was possible due to there being no order of transactions enforced (before a block is mined with that transaction in it). Is it possible for the second larger transaction to be put in a block?  
> **username_2**: Once a transaction is in a block or even in a miner's memory pool, all conflicting transactions are invalid. There are no input duplicates ever in the blockchain. Transaction malleability creates two TXIDs that point to the same transaction, but only one can be valid and placed in a block. Accepting both as valid is where exchanges lose money.  
> **username_0**: My question specifically references transactions that are not mined yet. The question is whether or not it is possible to edit the raw transaction to add inputs and outputs before the transaction is mined because each input is signed individually. I am not asking about duplicate inputs, I'm asking whether or not it's possible to add inputs and outputs to a transaction that hasn't been mined yet, with the hopes of re-broadcasting it to pools to have it mined before the "host" transaction is mined. I can't find anything in the protocol that would technically stop this from happening.  

---

