Why are the inputs of Bitcoin transactions signed?

Question

This is my understanding of what a transaction looks like:

inputs: 
  input0: 
    txid: <funding tx0 TXID>
    outputID: <output ID of UTXO in the funding tx0>
    scriptSig: <pkhash_redeemer> <sig0_redeemer>
  input1: 
    txid: <funding tx1 TXID>
    outputID: <output ID of UTXO in the funding tx1>
    scriptSig: <pkhash_redeemer> <sig1_redeemer>
  ...
outputs: 
  output0: 
    scriptPK: <scriptPK for new UTXO>
    amount: <amount for new UTXO> 

Where the signature <sig_redeemer0> is over:

• <funding tx0 TXID>
• <output ID of UTXO in the funding tx0>
• funding transaction's Pub Key Script
• <scriptPK for new UTXO>
• <amount for new UTXO>

I've read much that states things along the lines of: "the signature is over the entire transaction" or "the signature signs all the inputs and outputs". However, there are a few points of confusion I have:

1. Do multiple inputs necessitate multiple signatures? Or is my example wrong?

2. Why do we need to sign the inputs of the transaction?

If the inputs aren't signed, that means the following are left unsigned:

• txid of funding transaction
• <output ID of UTXO in the funding tx>
• sequence number (?)

If all outputs are signed, the amounts and scriptPubKeys of all UTXOs from funding transactions are fixed. An attacker might be able to change the inputs to the redeeming tx, but they are only unlockable if the inputs remain the same, so an attacker can't use an arbitrary input.

Any help would be appreciated! Thanks

Answer 1

There may be multiple utxos that the same script would unlock. The most common example is two transactions that both pay the same address. If inputs weren't signed, an attacker could replace one input utxo by a different utxo that pays the same address, and this would be bad.

Consider the following scenario. Alice has received two payments to her address 1Alice, both in the amount of 1 BTC: one with txid 234abc in the amount of 1 BTC, and another with txid 567def. She wishes to pay 0.5 BTC to Bob, so she creates and signs a transaction using the 234abc utxo as input, with the following outputs: 0.5 BTC to the address 1Bob, and 0.4999 BTC to some "change" address, 1AliceChange. (This leaves a transaction fee of 0.0001 BTC.)

After this transaction is broadcast and confirmed, Bob modifies the transaction so that the input is 567def instead. The scriptSig works equally well for every transaction that pays 1Alice (they all have the same scriptPubKey), so this new transaction is also valid. Bob broadcasts it and effectively steals an additional 0.5 BTC from Alice, which she never intended to give him.

This only works as long as 567def has the same value, or greater, than 234abc, but that's not much of a restriction. (If 567def has a greater value, say 10 BTC, then Bob's new transaction still only returns BTC 0.4999 to 1AliceChange, so it effectively has a transaction fee of BTC 9.0001. Any miner would be extremely happy to confirm this transaction; indeed, maybe a miner will perform this attack even if Bob doesn't care to.)