How was the overflow bug of 2010 detected? Should UINT64_MAX value transactions be considered suspicious?

2

The overflow bug of 2010 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))

goodguys_activate

Posted 2012-09-17T05:31:54.600

Reputation: 11 898

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 2015-07-30T07:01:38.190

Answers

4

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.

David Schwartz

Posted 2012-09-17T05:31:54.600

Reputation: 46 931

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?goodguys_activate 2012-09-17T18:51:21.483

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 2012-09-17T18:55:40.477