SIGHASH_ANYONECANPAY mediated tx modification

Question

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 txs with the same tx_in1. It seems to me that a UTXO might have two possible vouts and txids 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 txs can be added to the blockchain.

Answer 1

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 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.

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

Answer 2

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.