<blockquote>
  <p>I thought the whole amount of the input is always spent.</p>
</blockquote>

<p>That's correct.</p>

<blockquote>
  <p>In case the spender doesn't want to spend it whole, some of it goes to the same address (called change) returning the bitcoins.</p>
</blockquote>

<p>No, if the amount in the outputs is less than the inputs being spent, the difference is converted into fee.</p>

<p>Software that creates transactions can <em>explicitly</em> add an output for change that goes back to the former owner. This can be to the same address, but generally isn't. It is called change indeed, but it's not part of the protocol. It's just how wallets deal with inputs that are too large.</p>

<blockquote>
  <p>What do they mean by that? Does it mean the full available amount in the input?</p>
</blockquote>

<p><strong>Exactly</strong>. It's redundant information that is already implied by referencing the transactions that created the outputs. However, it simplifies the operation of some pieces of infrastructure.</p>

<p>In particular, right now if you want to use a hardware signing device ("hardware wallet"), and that wallet wants to show you how much fee you'll be creating, it needs to know the amounts of the outputs being spent (as the fee is the difference between outputs and inputs). That means it needs to be given the full transactions those outputs belonged to - which can be big. Otherwise, the software that created the transaction could lie, and in fact convert a giant portion of your money into fee without you knowing it.</p>

<p>With the fee explicitly part of the signature hash in BIP143, if the wallet software lies about the amounts to the hardware signer, the signature will simply be invalid.</p>

CC BY-SA 4.0
2019-03-13T17:20:18.693Z
If you put the full amount of the input in this field, does it mean that you're not accounting for miners fees?
Malone
CC BY-SA 4.0
2019-03-13T18:01:26.183Z
@Malone BIP143 commits directly to the input amount. It only indirectly commits to the fee (by virtue of including all output amounts, and referencing the txid:index of the output being spent, and that txid commits to all output amounts).
Pieter Wuille
CC BY-SA 3.0
2017-10-25T09:54:29.167Z
2017-10-25T09:54:29.167Z
Pieter Wuille
<p>I'm looking into <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">BIP 143</a> and I'm confused by item 6 in the specification of the transaction digest algorithm. It says:</p>

<blockquote>
  <p>The item 6 is a 8-byte value of the amount of bitcoin spent in this input.</p>
</blockquote>

<p>I thought the whole amount of the input is always spent. In case the spender doesn't want to spend it whole, some of it goes to the same address (called <em>change</em>) returning the bitcoins.</p>

<p>What do they mean by that? Does it mean the full available amount in the input?</p>

<transactions><segregated-witness>
What is ment by the "value of the output spent by this input" in BIP 143?
tsusanka
# What is ment by the "value of the output spent by this input" in BIP 143?

(Asked by: username_0 on 2017-10-25)

I'm looking into [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) and I'm confused by item 6 in the specification of the transaction digest algorithm. It says:

> The item 6 is a 8-byte value of the amount of bitcoin spent in this input.

I thought the whole amount of the input is always spent. In case the spender doesn't want to spend it whole, some of it goes to the same address (called *change*) returning the bitcoins.

What do they mean by that? Does it mean the full available amount in the input?

**Tags:** transactions, segregated-witness


---

## 1 answers

### Answer by username_1 on 2017-10-25. Score: 4 | Accepted answer

> I thought the whole amount of the input is always spent.

That's correct.

> In case the spender doesn't want to spend it whole, some of it goes to the same address (called change) returning the bitcoins.

No, if the amount in the outputs is less than the inputs being spent, the difference is converted into fee.

Software that creates transactions can *explicitly* add an output for change that goes back to the former owner. This can be to the same address, but generally isn't. It is called change indeed, but it's not part of the protocol. It's just how wallets deal with inputs that are too large.

> What do they mean by that? Does it mean the full available amount in the input?

**Exactly**. It's redundant information that is already implied by referencing the transactions that created the outputs. However, it simplifies the operation of some pieces of infrastructure.

In particular, right now if you want to use a hardware signing device ("hardware wallet"), and that wallet wants to show you how much fee you'll be creating, it needs to know the amounts of the outputs being spent (as the fee is the difference between outputs and inputs). That means it needs to be given the full transactions those outputs belonged to - which can be big. Otherwise, the software that created the transaction could lie, and in fact convert a giant portion of your money into fee without you knowing it.

With the fee explicitly part of the signature hash in BIP143, if the wallet software lies about the amounts to the hardware signer, the signature will simply be invalid.

> **Comments:**
> **username_2**: If you put the full amount of the input in this field, does it mean that you're not accounting for miners fees?  
> **username_1**: @username_2 BIP143 commits directly to the input amount. It only indirectly commits to the fee (by virtue of including all output amounts, and referencing the txid:index of the output being spent, and that txid commits to all output amounts).  

---

