<p>You are on the right track. Alice using <code>SIGHASH_ALL | SIGHASH_ANYONECANPAY</code> allows any other user to add additional inputs to the transaction. However, since Alice’s signature committed to all outputs (due to the <code>SIGHASH_ALL</code> part), the additional payers cannot change the outputs of the transaction, and their entire input will only contribute to the transaction fees.</p>
<p>Assuming that this new transaction increases the feerate and absolute fee sufficiently to displace the original transaction including any potential descendant transactions, it would invalidate the descendant transaction. Inputs commit to a specific UTXO explicitly per the <em>outpoint</em> (<code>txid:vout</code>). Since the addition of an input would create a new transaction that has a new TXID, the input to the original’s descendant transaction would cease to be expected to exist and as the original transaction is dropped from the mempool, the descendant would become invalid and be evicted alongside.</p>
<p>Since an input has to commit to exactly one specific UTXO it is spending, there are not &quot;two choices of UTXOs to reference&quot; for the descendant transaction. The recipient of the original/replacement transaction has to recreate the descendant transaction with the new input.</p>
<p>This rule would get an exception if the proposed <a href="https://anyprevout.xyz/" rel="nofollow noreferrer"><code>SIGHASH_ANYPREVOUT</code></a> were activated, which allows to identify UTXOs per their output script rather than their outpoint and would allow the recipient to create a descendant transaction that could spend the output of either the original or the replacement transaction.</p>
<hr />
<p>Follow-up question: How do nodes know which transaction to drop? Why does the descendant transaction not have two different choices what to use as input?</p>
<p>When the original transaction is created, it might have a txid <code>tx_orig</code>¹. It’s first output (at position 0) then has the outpoint <code>tx_orig:0</code>. The descendant transaction input spends explicitly spends the UTXO with the outpoint <code>tx_orig:0</code>. When the replacement transaction with additional inputs is created, it has a different <em>unique</em> txid which might be <code>tx_replace</code>. Its first output would have the outpoint <code>tx_replace:0</code>. Therefore, the descendant transaction becomes invalid due to the original transaction becoming replaced.</p>
<p>Transactions are in conflict when at least one UTXO is spent by both transactions. Let’s say there was another previous transaction that created <code>tx_ancient:1</code> and both the <code>tx_orig</code> and <code>tx_replace</code> try to spend that UTXO. The UTXO can only be spent once, so naturally including either transaction excludes the other from ever getting confirmed. Since only one transaction can be picked, miners pick the one that maximizes their reward. They hereby follow the <em>replace-by-fee</em> rules that require the replacement to exceed both the feerate of the original transaction and the absolute fees of all displaced transactions.</p>
<h2><a href="https://i.sstatic.net/yrOhtzU0.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/yrOhtzU0.png" alt="Transaction graph demonstrating the exclusivity of conflicting transactions." /></a></h2>
<p>¹ In reality txids created by hashing the transaction data with SHA-256, so they are usually presented as 64-character hex strings.</p>

CC BY-SA 4.0
2024-06-24T20:26:49.890Z
First off, thankyou for the edit, this is my first post and I'll keep the formatting in mind. "Since an input has to commit to exactly one specific UTXO it is spending, there are not "two choices of UTXOs to reference" for the descendant transaction. " - what I meant is now we have two `tx`s that have the same `tx_in1`. However it looks like this is solved by "dropping the original `tx` from the pool", but therein lies the question, how do nodes know which to drop? Its not like the original entry in the mempool will be queried by using the same `txid`, since as you mentioned, it changes.
b01001
CC BY-SA 4.0
2024-06-24T20:41:30.623Z
If I'm a node and have received a `tx` message with id `a72f…b1c9` it isnt immediately obvious to me how I should know to replace specifically the `tx` with id `1234…ab1e`. I'll have a look at the BIP though.
b01001
CC BY-SA 4.0
2024-06-24T20:53:00.743Z
Got it. Thanks alot!
b01001
CC BY-SA 4.0
2024-06-24T21:09:35.070Z
I added the relevant parts of the comments to the answer and included a quick graphic to illustrate the exclusivity of the conflicting txs.
Murch
CC BY-SA 4.0
2024-06-24T14:03:55.510Z
2024-06-25T19:06:19.347Z
2024-06-25T19:06:19.347Z
Murch
<p>With SIGHASH_ALL, Alice’s signature commits to ALL outputs, which means if Bob changes or adds outputs to the tx, Alice’s signature will become invalid. This means Bob has no incentive to add an input to this transaction (unless Bob wants to send some sats to miners).</p>
<p>For the rest of the answer, I’ll assume you meant SIGHASH_NONE or SIGHASH_SINGLE, i.e. Bob is able to re-use Alice’s signature while changing or adding outputs.</p>
<blockquote>
<p>Does this new transaction replace the old one in the mempool? Is it added separately?</p>
</blockquote>
<p>By adding a new input, the hash of the serialized transaction will change (i.e. the transaction id), which means it will be a new transaction on the mempool. At this time, nodes will identify two transactions spending the same UTXO (Alice’s input) and will select one of them (in principle the one which pays more fees to the miners). The other one will be discarded.</p>
<blockquote>
<p>Also what does that mean for spenders of the original tx_out1 Alice constructed if the latter is the case?</p>
</blockquote>
<p>Depends on the SIGHASH used by Alice in her signature:</p>
<ul>
<li>SIGHASH_NONE: the output can be changed or removed</li>
<li>SIGHASH_SINGLE: the output must remain as is in the transaction</li>
</ul>
<blockquote>
<p>Wouldn’t that second transaction create another UTXO meaning the spender can create a tx_in that would have two choices of UTXOs to reference?</p>
</blockquote>
<p>No, an UTXO can only be spent once, so you cannot have 2 transactions spending the same UTXO.</p>

CC BY-SA 4.0
2024-06-24T13:53:24.273Z
`SIGHASH_ALL | SIGHASH_ANYONECANPAY` commits to all outputs but only to the one input the signature is on. See e.g. here: https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash/
Murch
CC BY-SA 4.0
2024-06-23T09:28:27.807Z
2024-06-23T09:28:27.807Z
bordalix
<p>If Alice broadcasts a tx with an input <code>tx_in1</code> and output <code>tx_out1</code> signed with <code>SIGHASH_ALL | SIGHASH_ANYONECANPAY</code>, it lives temporarily in the mempool. Bob chooses to be a part of the crowdfunding and he adds an input <code>tx_in2</code> to the transaction, but then what? Does this new transaction replace the old one in the mempool? Is it added separately? Also what does that mean for spenders of the original <code>tx_out1</code> Alice constructed if the latter is the case? Wouldn’t that second transaction create another UTXO meaning the spender can create a <code>tx_in</code> that would have two choices of UTXOs to reference?</p>
<p>Edit: the specific output <code>SIGHASH</code> flag (in this case <code>SIGHASH_ALL</code>) isn't too important, the point was the creation of two <code>tx</code>s with the same <code>tx_in1</code>. It seems to me that a UTXO might have two possible <code>vout</code>s and <code>txid</code>s to choose from when holding the value of <code>tx_in1</code>, the first one being the UTXO that is created from Alice's <code>tx</code> and the second being the one created from Bob's. It seems to me only one of these <code>tx</code>s can be added to the blockchain.</p>

CC BY-SA 4.0
2024-06-24T20:42:11.337Z
I think your confusion stems from you thinking of the original and the replacement transaction as the same transaction. However, they have different txids which uniquely identifies the outputs they create. These posts might help clarify: https://bitcoin.stackexchange.com/q/61613/5406, https://bitcoin.stackexchange.com/a/20855/5406
Murch
<transactions><mempool><replace-by-fee><transaction-malleability><sighash>
SIGHASH_ANYONECANPAY mediated tx modification
b01001
# SIGHASH_ANYONECANPAY mediated tx modification

(Asked by: username_0 on 2024-06-23)

If Alice broadcasts a tx with an input `tx_in1` and output `tx_out1` signed with `SIGHASH_ALL | SIGHASH_ANYONECANPAY`, it lives temporarily in the mempool. Bob chooses to be a part of the crowdfunding and he adds an input `tx_in2` to the transaction, but then what? Does this new transaction replace the old one in the mempool? Is it added separately? Also what does that mean for spenders of the original `tx_out1` Alice constructed if the latter is the case? Wouldn’t that second transaction create another UTXO meaning the spender can create a `tx_in` that would have two choices of UTXOs to reference?

Edit: the specific output `SIGHASH` flag (in this case `SIGHASH_ALL`) isn't too important, the point was the creation of two `tx`s with the same `tx_in1`. It seems to me that a UTXO might have two possible `vout`s and `txid`s to choose from when holding the value of `tx_in1`, the first one being the UTXO that is created from Alice's `tx` and the second being the one created from Bob's. It seems to me only one of these `tx`s can be added to the blockchain.

**Tags:** transactions, mempool, replace-by-fee, transaction-malleability, sighash

> **Comments:**
> **username_1**: I think your confusion stems from you thinking of the original and the replacement transaction as the same transaction. However, they have different txids which uniquely identifies the outputs they create. These posts might help clarify: https://bitcoin.stackexchange.com/q/61613/5406, https://bitcoin.stackexchange.com/a/20855/5406  

---

## 2 answers

### Answer by username_1 on 2024-06-24. Score: 1 | Accepted answer

You are on the right track. Alice using `SIGHASH_ALL | SIGHASH_ANYONECANPAY` allows any other user to add additional inputs to the transaction. However, since Alice’s signature committed to all outputs (due to the `SIGHASH_ALL` part), the additional payers cannot change the outputs of the transaction, and their entire input will only contribute to the transaction fees.

Assuming that this new transaction increases the feerate and absolute fee sufficiently to displace the original transaction including any potential descendant transactions, it would invalidate the descendant transaction. Inputs commit to a specific UTXO explicitly per the *outpoint* (`txid:vout`). Since the addition of an input would create a new transaction that has a new TXID, the input to the original’s descendant transaction would cease to be expected to exist and as the original transaction is dropped from the mempool, the descendant would become invalid and be evicted alongside.

Since an input has to commit to exactly one specific UTXO it is spending, there are not "two choices of UTXOs to reference" for the descendant transaction. The recipient of the original/replacement transaction has to recreate the descendant transaction with the new input.

This rule would get an exception if the proposed [`SIGHASH_ANYPREVOUT`](https://anyprevout.xyz/) were activated, which allows to identify UTXOs per their output script rather than their outpoint and would allow the recipient to create a descendant transaction that could spend the output of either the original or the replacement transaction.

---

Follow-up question: How do nodes know which transaction to drop? Why does the descendant transaction not have two different choices what to use as input?

When the original transaction is created, it might have a txid `tx_orig`¹. It’s first output (at position 0) then has the outpoint `tx_orig:0`. The descendant transaction input spends explicitly spends the UTXO with the outpoint `tx_orig:0`. When the replacement transaction with additional inputs is created, it has a different *unique* txid which might be `tx_replace`. Its first output would have the outpoint `tx_replace:0`. Therefore, the descendant transaction becomes invalid due to the original transaction becoming replaced.

Transactions are in conflict when at least one UTXO is spent by both transactions. Let’s say there was another previous transaction that created `tx_ancient:1` and both the `tx_orig` and `tx_replace` try to spend that UTXO. The UTXO can only be spent once, so naturally including either transaction excludes the other from ever getting confirmed. Since only one transaction can be picked, miners pick the one that maximizes their reward. They hereby follow the *replace-by-fee* rules that require the replacement to exceed both the feerate of the original transaction and the absolute fees of all displaced transactions.

## [Transaction graph demonstrating the exclusivity of conflicting transactions.](https://i.sstatic.net/yrOhtzU0.png)

¹ In reality txids created by hashing the transaction data with SHA-256, so they are usually presented as 64-character hex strings.

> **Comments:**
> **username_0**: First off, thankyou for the edit, this is my first post and I'll keep the formatting in mind. "Since an input has to commit to exactly one specific UTXO it is spending, there are not "two choices of UTXOs to reference" for the descendant transaction. " - what I meant is now we have two `tx`s that have the same `tx_in1`. However it looks like this is solved by "dropping the original `tx` from the pool", but therein lies the question, how do nodes know which to drop? Its not like the original entry in the mempool will be queried by using the same `txid`, since as you mentioned, it changes.  
> **username_0**: If I'm a node and have received a `tx` message with id `a72f…b1c9` it isnt immediately obvious to me how I should know to replace specifically the `tx` with id `1234…ab1e`. I'll have a look at the BIP though.  
> **username_0**: Got it. Thanks alot!  
> **username_1**: I added the relevant parts of the comments to the answer and included a quick graphic to illustrate the exclusivity of the conflicting txs.  

---

### Answer by username_2 on 2024-06-23. Score: 0

With SIGHASH\_ALL, Alice’s signature commits to ALL outputs, which means if Bob changes or adds outputs to the tx, Alice’s signature will become invalid. This means Bob has no incentive to add an input to this transaction (unless Bob wants to send some sats to miners).

For the rest of the answer, I’ll assume you meant SIGHASH\_NONE or SIGHASH\_SINGLE, i.e. Bob is able to re-use Alice’s signature while changing or adding outputs.

> Does this new transaction replace the old one in the mempool? Is it added separately?

By adding a new input, the hash of the serialized transaction will change (i.e. the transaction id), which means it will be a new transaction on the mempool. At this time, nodes will identify two transactions spending the same UTXO (Alice’s input) and will select one of them (in principle the one which pays more fees to the miners). The other one will be discarded.

> Also what does that mean for spenders of the original tx\_out1 Alice constructed if the latter is the case?

Depends on the SIGHASH used by Alice in her signature:

* SIGHASH\_NONE: the output can be changed or removed
* SIGHASH\_SINGLE: the output must remain as is in the transaction

> Wouldn’t that second transaction create another UTXO meaning the spender can create a tx\_in that would have two choices of UTXOs to reference?

No, an UTXO can only be spent once, so you cannot have 2 transactions spending the same UTXO.

> **Comments:**
> **username_1**: `SIGHASH_ALL | SIGHASH_ANYONECANPAY` commits to all outputs but only to the one input the signature is on. See e.g. here: https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash/  

---

