<p>Your first source is wrong.</p>
<p>The block in question contained three transactions: the first is a coinbase transaction, the second is the one that did the overflow. The third is unknown, and not relevant.</p>
<p>The overflow transaction does not spend from the first transaction, rather it spends a UTXO that was created in an earlier transaction, which is actually in the blockchain and can be looked up today. The UTXO it spends is 0.5 BTC.</p>
<p>The two outputs of the overflow transaction are each 92233720368.54277039 whose bytes are <code>7ffffffffff863af</code> in hex. The most significant bit of this number is the sign bit - if it is <code>1</code> then the number is negative, <code>0</code> it is positive. In this case, these values are positive. This allows these values to pass the check that the output values are not negative.</p>
<p>The next relevant check is that the amount in the inputs can provide for the amount in the outputs. However the way this was done was not by checking the values directly, but rather the fee was calculated (input amounts - output amounts), and the fee is checked to be non-negative.</p>
<p>But because the output values are so large, when they are added together, they overflow the maximum signed integer and become negative. Subtracting this sum from the 0.5 BTC input becomes an addition as subtracting a negative number is addition. So the calculated fee is greater than 0 and this last check passes.</p>
<p>There are two inflationary effects of this bug. The first is the obvious one of the two extremely large outputs. The second is the transaction fee. The miner of that block can collect the miscalculated transaction fee of the overflow transaction, and so there is an additional 0.00997538 Bitcoin created.</p>

CC BY-SA 4.0
2022-07-31T07:53:43.820Z
Thank you for your answer. Please see the following and let me know if I got it right.

1. A 64 bit signed number can have from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.

Translating them from Satoshi to Bitcoin, -92.233,720,368.5477... to 92.233,720,368.5477...

2. The sum of the two output values, 184,467,440,737.0850, is expressed as -0.01, by overflowing the max positive number.

3. Subtract it from the input value of 0.5, and you get 0.51.

As this is positive, the tx is processed.
Slowblogger
CC BY-SA 4.0
2022-07-31T08:10:47.580Z
Another minor question, lest I forget, is about the coinbase tx. It had 50.51000000 as the output. How is it larger than 50, the mining reward? Is the tx fee included here? If so, why is it slightly larger than the (though erroneous) difference of in and out of 0.00997538?
Slowblogger
CC BY-SA 4.0
2022-07-31T08:19:34.510Z
The coinbase outputs include the transaction fee from *both* the other two transactions in the block.
RedGrittyBrick
CC BY-SA 4.0
2022-07-31T06:15:24.657Z
2022-09-01T14:53:34.473Z
2022-09-01T14:53:34.473Z
Ava Chow
<p>In 2010, there was an incident of value overflow on Bitcoin.</p>
<p>I am not a developer, but I want to know what the bug was in more detail. #1 is the only answer I found online, and #2-3 are my attempts to alternative answers.</p>
<p>1.
<a href="https://bitfalls.com/2018/01/14/curious-case-184-billion-bitcoin/" rel="nofollow noreferrer">Source: https://bitfalls.com/2018/01/14/curious-case-184-billion-bitcoin/</a></p>
<p>Total outputs were greater than 184,467,440,737.09551615, the maximum number that could be stored, by 50.51. And 50.51 was equal to the input value, so the tx was processed.</p>
<p>This was the tx, according to the source.</p>
<ul>
<li>from my address which has 50.51 BTC</li>
<li>send 92233720368.54277039 to address A</li>
<li>send 92233720368.54277039 to address B</li>
<li>send 50.51 BTC to address C</li>
</ul>
<p>But I am not sure. Looking at the block on <a href="https://bitcointalk.org/index.php?topic=822.msg9503#msg9503" rel="nofollow noreferrer">jgarzik's original post</a>, it looks like 50.51 was a separate tx from the two 92233720368.54277039 txs. And the input value for those 2 large txs seems to be 0.5. It doesn't really make sense. So, here are my alternative possible answers.</p>
<p>2.
The combined outputs of two large txs, 184,467,440,737(decimals cut off for simplicity), is subtracted from the input of 0.5, which results in -184,467,440,736.5. But because the variable was an unsigned number, it was wrapped (around the max number of 184,467,440,737.09551615) to end up as 0.5 (or smaller). This is equal to the input value, so the tx is included.</p>
<p>3.
Similar to #1, but I saw somewhere that negative sign could erroneously be interpreted as another number digit. So (rather than wrapped around the max number) -184,467,440,736.5 is seen as a larger positive number. I don't know what number it will become. 1,000,000,000,000 + 184,467,440,736.5? Or 2 x 184,467,440,736.5?</p>
<p>Maybe something else? Please let me know what you think really happened. Thank you in advance.</p>

CC BY-SA 4.0
2022-07-31T17:24:03.783Z
Does this answer your question? [What’s the purpose of checking for input overflow?](https://bitcoin.stackexchange.com/questions/86173/what-s-the-purpose-of-checking-for-input-overflow)
user2284570
CC BY-SA 4.0
2022-08-01T06:28:35.907Z
I am afraid not. But it's interesting. Thanks. @user2284570
Slowblogger
<bitcoin-core><bitcoind><bitcoin-core-development><history><satoshi-nakamoto>
What was the bug for the Bitcoin value overflow in 2010?
Slowblogger
# What was the bug for the Bitcoin value overflow in 2010?

(Asked by: username_0 on 2022-07-31)

In 2010, there was an incident of value overflow on Bitcoin.

I am not a developer, but I want to know what the bug was in more detail. #1 is the only answer I found online, and #2-3 are my attempts to alternative answers.

1.
[Source: https://bitfalls.com/2018/01/14/curious-case-184-billion-bitcoin/](https://bitfalls.com/2018/01/14/curious-case-184-billion-bitcoin/)

Total outputs were greater than 184,467,440,737.09551615, the maximum number that could be stored, by 50.51. And 50.51 was equal to the input value, so the tx was processed.

This was the tx, according to the source.

* from my address which has 50.51 BTC
* send 92233720368.54277039 to address A
* send 92233720368.54277039 to address B
* send 50.51 BTC to address C

But I am not sure. Looking at the block on [jgarzik's original post](https://bitcointalk.org/index.php?topic=822.msg9503#msg9503), it looks like 50.51 was a separate tx from the two 92233720368.54277039 txs. And the input value for those 2 large txs seems to be 0.5. It doesn't really make sense. So, here are my alternative possible answers.

2.
The combined outputs of two large txs, 184,467,440,737(decimals cut off for simplicity), is subtracted from the input of 0.5, which results in -184,467,440,736.5. But because the variable was an unsigned number, it was wrapped (around the max number of 184,467,440,737.09551615) to end up as 0.5 (or smaller). This is equal to the input value, so the tx is included.

3.
Similar to #1, but I saw somewhere that negative sign could erroneously be interpreted as another number digit. So (rather than wrapped around the max number) -184,467,440,736.5 is seen as a larger positive number. I don't know what number it will become. 1,000,000,000,000 + 184,467,440,736.5? Or 2 x 184,467,440,736.5?

Maybe something else? Please let me know what you think really happened. Thank you in advance.

**Tags:** bitcoin-core, bitcoind, bitcoin-core-development, history, satoshi-nakamoto

> **Comments:**
> **username_1**: Does this answer your question? [What’s the purpose of checking for input overflow?](https://bitcoin.stackexchange.com/questions/86173/what-s-the-purpose-of-checking-for-input-overflow)  
> **username_0**: I am afraid not. But it's interesting. Thanks. @username_1  

---

## 1 answers

### Answer by username_2 on 2022-07-31. Score: 5

Your first source is wrong.

The block in question contained three transactions: the first is a coinbase transaction, the second is the one that did the overflow. The third is unknown, and not relevant.

The overflow transaction does not spend from the first transaction, rather it spends a UTXO that was created in an earlier transaction, which is actually in the blockchain and can be looked up today. The UTXO it spends is 0.5 BTC.

The two outputs of the overflow transaction are each 92233720368.54277039 whose bytes are `7ffffffffff863af` in hex. The most significant bit of this number is the sign bit - if it is `1` then the number is negative, `0` it is positive. In this case, these values are positive. This allows these values to pass the check that the output values are not negative.

The next relevant check is that the amount in the inputs can provide for the amount in the outputs. However the way this was done was not by checking the values directly, but rather the fee was calculated (input amounts - output amounts), and the fee is checked to be non-negative.

But because the output values are so large, when they are added together, they overflow the maximum signed integer and become negative. Subtracting this sum from the 0.5 BTC input becomes an addition as subtracting a negative number is addition. So the calculated fee is greater than 0 and this last check passes.

There are two inflationary effects of this bug. The first is the obvious one of the two extremely large outputs. The second is the transaction fee. The miner of that block can collect the miscalculated transaction fee of the overflow transaction, and so there is an additional 0.00997538 Bitcoin created.

> **Comments:**
> **username_0**: Thank you for your answer. Please see the following and let me know if I got it right.  1. A 64 bit signed number can have from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.  Translating them from Satoshi to Bitcoin, -92.233,720,368.5477... to 92.233,720,368.5477...  2. The sum of the two output values, 184,467,440,737.0850, is expressed as -0.01, by overflowing the max positive number.  3. Subtract it from the input value of 0.5, and you get 0.51.  As this is positive, the tx is processed.  
> **username_0**: Another minor question, lest I forget, is about the coinbase tx. It had 50.51000000 as the output. How is it larger than 50, the mining reward? Is the tx fee included here? If so, why is it slightly larger than the (though erroneous) difference of in and out of 0.00997538?  
> **username_3**: The coinbase outputs include the transaction fee from *both* the other two transactions in the block.  

---

