<p>Your first question is kind of a pointless retrospective question. Sure, now that we know that overflow can be a problem in this way, we should consider transactions that attempt to overflow to be suspicious.</p>

<p>The bug was detected by inspection of the blockchain. The bad transactions stood out. Had it not been detected by inspection, sooner or later it would have been detected by the presence of too many Bitcoins circulating.</p>

<p>There are no issues any more. Each individual output is now checked in a way that ensures that their sum cannot exceed the input to the transaction. Overflow is, so far as we know, no longer possible.</p>

<p>Your question seems to be asking if there's some "magic bullet" that can solve similar future problems that are presently unknown. The thing is, if there was, we wouldn't know it because we don't know what the future problems are likely to be. Sure, in retrospect, there are many things that could have been differently that would have made this particular exploit impossile.</p>

CC BY-SA 3.0
2012-09-17T18:51:21.483Z
Perhaps I need to read the source code.. I thought the issue was a UINT64 field was filled in with INT64 data.  Based on this, I would think that any similar value might indicate a client/peer bug.  Sure it was fixed in that one version of the client, but it's possible for ports to be made that exhibit the same bug.  In this case, should peers treat that value with suspicion?  My bet is yes, and since UINT64 > INT64 we may see this again in the future.  What do we do if we see it?
makerofthings7
CC BY-SA 3.0
2012-09-17T18:55:40.477Z
There's no need to treat it with suspicion. It will just be rejected since it's an output whose value exceeds the total input.
David Schwartz
CC BY-SA 3.0
2012-09-17T18:15:55.603Z
2012-09-17T18:15:55.603Z
David Schwartz
<p>The <a href="https://bitcointalk.org/index.php?topic=823.0;all" rel="nofollow">overflow bug of 2010</a> was a result of a client that summed two values together and reaching INT64_MAX instead of UINT64_MAX.</p>

<ul>
<li><p>Should transactions of INT64_MAX (or any similar constant) be treated with suspicion?</p></li>
<li><p>How was the overflow bug of 2010 detected?</p></li>
<li><p>Are there provisions in place for similar, future large transactions that may involve larger sums?  (128 bit values (if possible in the network)) </p></li>
</ul>

CC BY-SA 3.0
2015-07-30T07:01:38.190Z
Something similar exists in the Bitcoin client - if you create an output larger than MAX_MONEY, (which is equal to 21 million Bitcoins) the transaction will be rejected, before the check that @DavidSchwartz talks about.
Nick ODell
<transactions><verification>
How was the overflow bug of 2010 detected? Should UINT64_MAX value transactions be considered suspicious?
makerofthings7
# How was the overflow bug of 2010 detected? Should UINT64_MAX value transactions be considered suspicious?

(Asked by: username_0 on 2012-09-17)

The [overflow bug of 2010](https://bitcointalk.org/index.php?topic=823.0;all) was a result of a client that summed two values together and reaching INT64\_MAX instead of UINT64\_MAX.

* Should transactions of INT64\_MAX (or any similar constant) be treated with suspicion?
* How was the overflow bug of 2010 detected?
* Are there provisions in place for similar, future large transactions that may involve larger sums? (128 bit values (if possible in the network))

**Tags:** transactions, verification

> **Comments:**
> **username_1**: Something similar exists in the Bitcoin client - if you create an output larger than MAX_MONEY, (which is equal to 21 million Bitcoins) the transaction will be rejected, before the check that @username_2 talks about.  

---

## 1 answers

### Answer by username_2 on 2012-09-17. Score: 5 | Accepted answer

Your first question is kind of a pointless retrospective question. Sure, now that we know that overflow can be a problem in this way, we should consider transactions that attempt to overflow to be suspicious.

The bug was detected by inspection of the blockchain. The bad transactions stood out. Had it not been detected by inspection, sooner or later it would have been detected by the presence of too many Bitcoins circulating.

There are no issues any more. Each individual output is now checked in a way that ensures that their sum cannot exceed the input to the transaction. Overflow is, so far as we know, no longer possible.

Your question seems to be asking if there's some "magic bullet" that can solve similar future problems that are presently unknown. The thing is, if there was, we wouldn't know it because we don't know what the future problems are likely to be. Sure, in retrospect, there are many things that could have been differently that would have made this particular exploit impossile.

> **Comments:**
> **username_0**: Perhaps I need to read the source code.. I thought the issue was a UINT64 field was filled in with INT64 data.  Based on this, I would think that any similar value might indicate a client/peer bug.  Sure it was fixed in that one version of the client, but it's possible for ports to be made that exhibit the same bug.  In this case, should peers treat that value with suspicion?  My bet is yes, and since UINT64 > INT64 we may see this again in the future.  What do we do if we see it?  
> **username_2**: There's no need to treat it with suspicion. It will just be rejected since it's an output whose value exceeds the total input.  

---

