<p>It appears to largely be just a belt-and-suspenders check. As you say, it is unnecessary to do this check. However it doesn't hurt to have this check in there. At worst, it just adds a few nanoseconds to verification time. At best, it will catch some serious bugs.</p>

<p>Given that this is consensus related, it does not hurt to have extra checks that are theoretically unnecessary. They will prevent errors in cases where some edge case occurs. In this case, it was possible for an input with negative value to be spent and thus this check would come into play. That would occur if someone updated their node following the block with the bad transaction, but did not rollback their blockchain. If the owner of the negative output had spent it, this check would have prevented the node from accepting the transaction.</p>

CC BY-SA 4.0
2019-04-23T20:35:31.023Z
The points is every cryptocurrencies are doing it. Even those not using Bitcoin code like Monero. So it seems to be strange that all cryptocurrencies tracking coins instead of balances are ensuring what would be an unnecessary check. Maybe there’s something I missed and an inflation attack from input overflow is possible ?
user2284570
CC BY-SA 4.0
2019-04-23T20:38:05.967Z
Most of those cryptocurrencies just blindly copied and forked the Bitcoin source code. The check is there because they didn't bother to remove it. The check is still in Bitcoin Core because Bitcoin Core hasn't bothered to remove it. I don't think there's really any real reason as to why it's still there other than that it was added and it does no harm.
Ava Chow
CC BY-SA 4.0
2019-04-23T20:57:20.637Z
Yes, for those who started by forking Bitcoin. But for monero (which is an example among others), I can say definitely that’s it’s not Bitcoin code.
user2284570
CC BY-SA 4.0
2019-04-23T21:02:19.380Z
You would have to ask the Monero developers. It is possible that they have it because a break in Monero's cryptography would allow for hidden inflation. It is also possible that during the initial implementation, they were copying code from Bitcoin even if they did not directly fork their source code from Bitcoin. After all, they have a somewhat similar transaction and blockchain model, so there's no need to rewrite everything from scratch.
Ava Chow
CC BY-SA 4.0
2019-04-23T21:19:52.263Z
the same is true for Zcash Joinspits.
user2284570
CC BY-SA 4.0
2019-04-23T20:30:14.287Z
2019-04-23T20:30:14.287Z
Ava Chow
<p>While it's not valid on the Bitcoin network for inputs to add up to a negative amount, or to more that 21 million, the computer doesn't innately know that - it needs a program to instruct it. Your link is to one point in the bitcoind program where the computer is instructed how to tell the difference between valid, and invalid, transactions.</p>

<p>You can also think of your assertion "it’s not possible to have enough utxo" another way. One reason it is not possible is because of the IF statement you point to: remove the check, and suddenly it IS possible (later code withstanding.)</p>

CC BY-SA 4.0
2019-04-21T17:27:44.577Z
If "duplicate inputs things are deleted later" then the processing between this point and that later point is wasted because it is known /now/ that they won't pass.
What the attacker may or not believe seems irrelevant to your question "What’s the point of checking inputs overflow?". I suggest if my answer isn't what you're after, you further clarify what you're asking.
Alistair Mann
CC BY-SA 4.0
2019-04-21T17:35:03.567Z
@user2284570 Both your question and this remark is actually very confusing with incomplete and grammatically incorrect sentences. The remark, to a good attempt at an answer, is very rude as well. I'm very much inclined to vote for closing this whole question if you don't improve it.
Jannes
CC BY-SA 4.0
2019-04-21T18:09:55.990Z
@Jannes `While it's not valid on the Bitcoin network for inputs to add up to a negative amount` the point is why making invalid something invalid and why would an attacker would want this as a 74638 block style attack. **So know I suppose you understand the answer is like answering what will be the weather tomorrow to a question asking how the weather was yesterday**, that is : an off topic answer. The answer explains why it’s impossible whereas the question is about why making it impossible. Of course, please edit the question to reflect this.
user2284570
CC BY-SA 4.0
2019-04-21T18:14:13.963Z
@AlistairMann the question is about why making invalid something which is already impossible whereas you’re answering how it’s done to do it.
user2284570
CC BY-SA 4.0
2019-04-21T18:40:54.980Z
@AlistairMann the code I’m referring to is only a security fix for an inflation bug and has no purpose for ᴅᴅᴏꜱ logic. Is it clear now ?
user2284570
CC BY-SA 4.0
2019-04-22T10:49:54.287Z
Seems to me this patch is about adding proper bounds checks, which must be done in all relevant places where bad data can lean in. It also makes perfect sense to do this as early as possible in the call stack. Simple input validation logic. I still don't understand your problem.
Jannes
CC BY-SA 4.0
2019-04-23T20:23:46.907Z
@Jannes yes and the point of the question is why doing it on inputs ? This has no sense because for inputs bad data can’t lean in for inputs. Also, only overflowing output is interesting since it allows to decrease transaction value requirement : something which has no sense for inputs.
user2284570
CC BY-SA 4.0
2019-04-21T17:14:02.673Z
2019-04-21T17:14:02.673Z
Alistair Mann
<p>Everyone knows <a href="https://github.com/bitcoin/bitcoin/commit/d4c6b90ca3f9b47adb1b2724a0c3514f80635c84#diff-118fcbaaba162ba17933c7893247df3aR1010" rel="nofollow noreferrer">this famous fix for block 74638 which still exists in other files</a>. But there’s something I can’t understand, why check for inputs overflow since it’s not possible to have enough utxo for such case as it’s their hash being tracked and from an attacker point of view this only decrease what he/she/they have in reality (unlike outputs where it decrease the amount to be paid).</p>

<p>So why making invalid something which is already impossible and would has no impacts as an inflation bug ?<br>
Even the go implementation of bitcoin is doing it.</p>

CC BY-SA 4.0
2019-04-21T17:43:05.200Z
Which of the three checks you're linking to are you asking for?
Pieter Wuille
CC BY-SA 4.0
2019-04-21T17:53:54.533Z
@PieterWuille the whole check for inputs. Question edited to reflect this.
user2284570
<security><transaction-input><inflation><utxo-set>
What’s the purpose of checking for input overflow?
user2284570
# What’s the purpose of checking for input overflow?

(Asked by: username_0 on 2019-04-21)

Everyone knows [this famous fix for block 74638 which still exists in other files](https://github.com/bitcoin/bitcoin/commit/d4c6b90ca3f9b47adb1b2724a0c3514f80635c84#diff-118fcbaaba162ba17933c7893247df3aR1010). But there’s something I can’t understand, why check for inputs overflow since it’s not possible to have enough utxo for such case as it’s their hash being tracked and from an attacker point of view this only decrease what he/she/they have in reality (unlike outputs where it decrease the amount to be paid).

So why making invalid something which is already impossible and would has no impacts as an inflation bug ?  
Even the go implementation of bitcoin is doing it.

**Tags:** security, transaction-input, inflation, utxo-set

> **Comments:**
> **username_1**: Which of the three checks you're linking to are you asking for?  
> **username_0**: @username_1 the whole check for inputs. Question edited to reflect this.  

---

## 2 answers

### Answer by username_2 on 2019-04-23. Score: 3

It appears to largely be just a belt-and-suspenders check. As you say, it is unnecessary to do this check. However it doesn't hurt to have this check in there. At worst, it just adds a few nanoseconds to verification time. At best, it will catch some serious bugs.

Given that this is consensus related, it does not hurt to have extra checks that are theoretically unnecessary. They will prevent errors in cases where some edge case occurs. In this case, it was possible for an input with negative value to be spent and thus this check would come into play. That would occur if someone updated their node following the block with the bad transaction, but did not rollback their blockchain. If the owner of the negative output had spent it, this check would have prevented the node from accepting the transaction.

> **Comments:**
> **username_0**: The points is every cryptocurrencies are doing it. Even those not using Bitcoin code like Monero. So it seems to be strange that all cryptocurrencies tracking coins instead of balances are ensuring what would be an unnecessary check. Maybe there’s something I missed and an inflation attack from input overflow is possible ?  
> **username_2**: Most of those cryptocurrencies just blindly copied and forked the Bitcoin source code. The check is there because they didn't bother to remove it. The check is still in Bitcoin Core because Bitcoin Core hasn't bothered to remove it. I don't think there's really any real reason as to why it's still there other than that it was added and it does no harm.  
> **username_0**: Yes, for those who started by forking Bitcoin. But for monero (which is an example among others), I can say definitely that’s it’s not Bitcoin code.  
> **username_2**: You would have to ask the Monero developers. It is possible that they have it because a break in Monero's cryptography would allow for hidden inflation. It is also possible that during the initial implementation, they were copying code from Bitcoin even if they did not directly fork their source code from Bitcoin. After all, they have a somewhat similar transaction and blockchain model, so there's no need to rewrite everything from scratch.  
> **username_0**: the same is true for Zcash Joinspits.  

---

### Answer by username_3 on 2019-04-21. Score: -2

While it's not valid on the Bitcoin network for inputs to add up to a negative amount, or to more that 21 million, the computer doesn't innately know that - it needs a program to instruct it. Your link is to one point in the bitcoind program where the computer is instructed how to tell the difference between valid, and invalid, transactions.

You can also think of your assertion "it’s not possible to have enough utxo" another way. One reason it is not possible is because of the IF statement you point to: remove the check, and suddenly it IS possible (later code withstanding.)

> **Comments:**
> **username_3**: If "duplicate inputs things are deleted later" then the processing between this point and that later point is wasted because it is known /now/ that they won't pass. What the attacker may or not believe seems irrelevant to your question "What’s the point of checking inputs overflow?". I suggest if my answer isn't what you're after, you further clarify what you're asking.  
> **username_4**: @username_0 Both your question and this remark is actually very confusing with incomplete and grammatically incorrect sentences. The remark, to a good attempt at an answer, is very rude as well. I'm very much inclined to vote for closing this whole question if you don't improve it.  
> **username_0**: @username_4 `While it's not valid on the Bitcoin network for inputs to add up to a negative amount` the point is why making invalid something invalid and why would an attacker would want this as a 74638 block style attack. **So know I suppose you understand the answer is like answering what will be the weather tomorrow to a question asking how the weather was yesterday**, that is : an off topic answer. The answer explains why it’s impossible whereas the question is about why making it impossible. Of course, please edit the question to reflect this.  
> **username_0**: @username_3 the question is about why making invalid something which is already impossible whereas you’re answering how it’s done to do it.  
> **username_0**: @username_3 the code I’m referring to is only a security fix for an inflation bug and has no purpose for ᴅᴅᴏꜱ logic. Is it clear now ?  
> **username_4**: Seems to me this patch is about adding proper bounds checks, which must be done in all relevant places where bad data can lean in. It also makes perfect sense to do this as early as possible in the call stack. Simple input validation logic. I still don't understand your problem.  
> **username_0**: @username_4 yes and the point of the question is why doing it on inputs ? This has no sense because for inputs bad data can’t lean in for inputs. Also, only overflowing output is interesting since it allows to decrease transaction value requirement : something which has no sense for inputs.  

---

