Why are the inputs of Bitcoin transactions signed?

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:

Do multiple inputs necessitate multiple signatures? Or is my example wrong?
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

acnalb

Posted 2018-12-07T22:35:14.857

Reputation: 7

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. – Nate Eldredge – 2018-12-08T00:31:29.650

So if I understand correctly, if A creates a tx that pays B 1BTC (UTXO 1) and returns 1BTC of change back to A (UTXO 2), B could: (1) Redeem the 1BTC locked by UTXO1, (2) Redeem the 1BTC locked by UTXO1 again, since there's no explicit mapping between inputs and outputs in the tx. If A attempts to redeem UTXO2, they won't be able to, since all the inputs are already redeemed. – acnalb – 2018-12-08T02:33:00.307

That particular example won't work; since the transaction in question has outputs totaling 2BTC, if B edits it to use UTXO 2 as the input (whose value is 1BTC), it won't be valid. I'll add an answer explaining what I have in mind. – Nate Eldredge – 2018-12-08T02:47:46.347

Answers

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

Nate Eldredge

Posted 2018-12-07T22:35:14.857

Reputation: 21 420

Thanks! That clarifies things a lot. I'm not sure if this is better left to another question but: Why then, are the outputs signed? I think I understand how a miner could exploit this, but not necessarily Bob. If outputs are not signed, then the scriptPK and amount of each output can be changed by a malicious actor. A miner could: (1) whenever they receive a tx, arbitrarily add/remove scriptPKs (so censor redeemers and collect larger fees) and (2) change outputs to be addresses they control. How could Bob exploit this? – acnalb – 2018-12-08T20:26:19.433

Actually, I think I understand how Bob could take advantage of this. For any posted transaction tx0, Bob could redeem from it with a new tx1 by changing the scriptPK that locks the outputs of tx0 such that the scriptSig <pkB><sigB> can give Bob the UTXO. Is this understanding correct? – acnalb – 2018-12-08T20:49:16.467

@acnalb: Yes, that's right. If outputs are unsigned, then any attacker (Charlie) can modify any transaction to pay Charlie's address instead of the address that was originally intended. This would make the whole system entirely unusable. – Nate Eldredge – 2018-12-09T01:36:53.337