<p>For the best possible explanation, it's important to understand how a Bitcoin transaction is formatted. Here is an example of the format used for a Bitcoin transaction <a href="https://en.bitcoin.it/wiki/Protocol_specification" rel="nofollow">from the wiki</a>:</p>

<pre><code>000000  F9 BE B4 D9 74 78 00 00  00 00 00 00 00 00 00 00   ....tx..........
000010  02 01 00 00 E2 93 CD BE  01 00 00 00 01 6D BD DB   .............m..
000020  08 5B 1D 8A F7 51 84 F0  BC 01 FA D5 8D 12 66 E9   .[...Q........f.
000030  B6 3B 50 88 19 90 E4 B4  0D 6A EE 36 29 00 00 00   .;P......j.6)...
000040  00 8B 48 30 45 02 21 00  F3 58 1E 19 72 AE 8A C7   ..H0E.!..X..r...
000050  C7 36 7A 7A 25 3B C1 13  52 23 AD B9 A4 68 BB 3A   .6zz%;..R#...h.:
000060  59 23 3F 45 BC 57 83 80  02 20 59 AF 01 CA 17 D0   Y#?E.W... Y.....
000070  0E 41 83 7A 1D 58 E9 7A  A3 1B AE 58 4E DE C2 8D   .A.z.X.z...XN...
000080  35 BD 96 92 36 90 91 3B  AE 9A 01 41 04 9C 02 BF   5...6..;...A....
000090  C9 7E F2 36 CE 6D 8F E5  D9 40 13 C7 21 E9 15 98   .~.6.m...@..!...
0000A0  2A CD 2B 12 B6 5D 9B 7D  59 E2 0A 84 20 05 F8 FC   *.+..].}Y... ...
0000B0  4E 02 53 2E 87 3D 37 B9  6F 09 D6 D4 51 1A DA 8F   N.S..=7.o...Q...
0000C0  14 04 2F 46 61 4A 4C 70  C0 F1 4B EF F5 FF FF FF   ../FaJLp..K.....
0000D0  FF 02 40 4B 4C 00 00 00  00 00 19 76 A9 14 1A A0   ..@KL......v....
0000E0  CD 1C BE A6 E7 45 8A 7A  BA D5 12 A9 D9 EA 1A FB   .....E.z........
0000F0  22 5E 88 AC 80 FA E9 C7  00 00 00 00 19 76 A9 14   "^...........v..
000100  0E AB 5B EA 43 6A 04 84  CF AB 12 48 5E FD A0 B7   ..[.Cj.....H^...
000110  8B 4E CC 52 88 AC 00 00  00 00                     .N.R......


Message header:
 F9 BE B4 D9                                       - main network magic bytes
 74 78 00 00 00 00 00 00 00 00 00 00               - "tx" command
 02 01 00 00                                       - payload is 258 bytes long
 E2 93 CD BE                                       - checksum of payload

Transaction:
 01 00 00 00                                       - version

Inputs:
 01                                                - number of transaction inputs

Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF                                       - sequence

Outputs:
 02                                                - 2 Output Transactions

Output 1:
 40 4B 4C 00 00 00 00 00                           - 0.05 BTC (5000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 1A A0 CD 1C BE  A6 E7 45 8A 7A BA D5 12  - pk_script
 A9 D9 EA 1A FB 22 5E 88  AC

Output 2:
 80 FA E9 C7 00 00 00 00                           - 33.54 BTC (3354000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 0E AB 5B EA 43  6A 04 84 CF AB 12 48 5E  - pk_script
 FD A0 B7 8B 4E CC 52 88  AC

Locktime:
 00 00 00 00                                       - lock time
</code></pre>

<p>And here's the really important part:</p>

<pre><code>Output 1:
 40 4B 4C 00 00 00 00 00                           - 0.05 BTC (5000000)
</code></pre>

<p>Note that we've used 8 bytes (or 64 bits) worth of hex to represent the amount, in Satoshis (0.00000001 BTC, the smallest possible unit). At peak, approximately 21 million BTC will exist, so that's the most you could possibly have in your wallet, even if you controlled all the bitcoins in the world. the maximum value storable in the standard 9 bytes would be 0xFFFFFFFFFFFFFFFF~=1.84e+19 satoshis or 184,467,440,737 BTC, or about 8,784 times the number of coins that will ever exist.</p>

<p>So the technical upper limit for bitcoins sendable in a single transaction is 4.7e+21 but the functional upper limit is 21 million, since that's all there will ever be.</p>

<p>Even if you're using an alt chain that never stops inflating via block rewards, at the standard 50 coins per 10 minute block it would take more than 9 billion years for the entire network to accumulate enough coins to breach that upper limit.</p>

<p>TL;DR: There's a limit but you shouldn't ever under any circumstances have to worry about it.</p>

CC BY-SA 3.0
2012-09-19T19:13:41.147Z
Alternate TL;DR ... if you're close to that value you're rich enough to hire a team of PHD's to watch that for you  ;)
makerofthings7
CC BY-SA 3.0
2012-09-20T10:17:38.097Z
At around 53 bits(100 mio BTC) double precision becomes a problem. This should not be a problem for the core bitcoin code which uses 64 bit integers, but might cause problems with the JSon API, if the values in there are interpreted as double. Obviously that's not a problem with bitcoin, since the 21mio limit is smaller than that (alt chains are a different issue).
CodesInChaos
CC BY-SA 3.0
2012-09-20T18:55:20.963Z
Wait, someone is using floats for financial transactions? Didn't we already learn this lesson a long long time ago?
David Perry
CC BY-SA 3.0
2012-09-22T16:12:33.620Z
@DavidPerry In some languages, such as lua(and I think javascript) `double` is all you have. It's only a problem if you're using the fractional part of binary floatingpoints. If you use `double` to represent an integral amount of satoshis that's no problem.  And decimal floatingpoints (such as .net's `System.Decimal`) can even use the decimal part.
CodesInChaos
CC BY-SA 3.0
2012-09-19T18:29:11.657Z
2012-09-19T18:29:11.657Z
David Perry
<p>0 to 21 million BTC. (Yes, 0-BTC transactions are allowed as long as they have a fee.)</p>

CC BY-SA 3.0
2014-10-15T13:17:17.813Z
...or "0 to 2,100,000,000,000,000" satoshis. ;)
RLH
CC BY-SA 3.0
2012-09-19T18:32:14.107Z
That makes sense but is this the validation performed by a compliant client when checking an incoming transaction message for inclusion in its pool?
boussac
CC BY-SA 3.0
2012-09-19T19:17:21.487Z
@boussac: Yes, these limits are checked upon reception. See [here](http://github.com/bitcoin/bitcoin/blob/b1d3e95a0a9f51e81c82b58ff818a4c236e48e30/src/main.cpp#L443) (`MAX_MONEY` is exactly 21,000,000 BTC).
Stéphane Gimenez
CC BY-SA 3.0
2012-09-19T18:12:17.933Z
2012-09-19T18:12:17.933Z
theymos
<p>What is the legal money range for a bitcoin transaction message ?
I am guessing that the lower limit is one satoshi but what about an upper limit aside from the maximum block size constraint ?</p>

CC BY-SA 3.0
2012-09-19T16:48:35.713Z
The size of a transaction is not related to the money amounts involved. Taking this into consideration, I'm not sure this question still makes sense, is it?
Stéphane Gimenez
CC BY-SA 3.0
2012-09-19T18:35:49.930Z
Block size doesn't enter into it. 8 bytes (64 bits) are used for the value field regardless of the amount sent so the number of coins sent does not effect the transaction at all. That 64 bits does represent its own upper limit (as mentioned in my answer), but it doesn't effect block size.
David Perry
<transactions><block><message-verification>
What is the legal money range for a bitcoin transaction?
boussac
# What is the legal money range for a bitcoin transaction?

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

What is the legal money range for a bitcoin transaction message ?
I am guessing that the lower limit is one satoshi but what about an upper limit aside from the maximum block size constraint ?

**Tags:** transactions, block, message-verification

> **Comments:**
> **username_1**: The size of a transaction is not related to the money amounts involved. Taking this into consideration, I'm not sure this question still makes sense, is it?  
> **username_2**: Block size doesn't enter into it. 8 bytes (64 bits) are used for the value field regardless of the amount sent so the number of coins sent does not effect the transaction at all. That 64 bits does represent its own upper limit (as mentioned in my answer), but it doesn't effect block size.  

---

## 2 answers

### Answer by username_5 on 2012-09-19. Score: 7 | Accepted answer

0 to 21 million BTC. (Yes, 0-BTC transactions are allowed as long as they have a fee.)

> **Comments:**
> **username_0**: That makes sense but is this the validation performed by a compliant client when checking an incoming transaction message for inclusion in its pool?  
> **username_1**: @username_0: Yes, these limits are checked upon reception. See [here](http://github.com/bitcoin/bitcoin/blob/b1d3e95a0a9f51e81c82b58ff818a4c236e48e30/src/main.cpp#L443) (`MAX_MONEY` is exactly 21,000,000 BTC).  
> **username_6**: ...or "0 to 2,100,000,000,000,000" satoshis. ;)  

---

### Answer by username_2 on 2012-09-19. Score: 2

For the best possible explanation, it's important to understand how a Bitcoin transaction is formatted. Here is an example of the format used for a Bitcoin transaction [from the wiki](https://en.bitcoin.it/wiki/Protocol_specification):

```
000000  F9 BE B4 D9 74 78 00 00  00 00 00 00 00 00 00 00   ....tx..........
000010  02 01 00 00 E2 93 CD BE  01 00 00 00 01 6D BD DB   .............m..
000020  08 5B 1D 8A F7 51 84 F0  BC 01 FA D5 8D 12 66 E9   .[...Q........f.
000030  B6 3B 50 88 19 90 E4 B4  0D 6A EE 36 29 00 00 00   .;P......j.6)...
000040  00 8B 48 30 45 02 21 00  F3 58 1E 19 72 AE 8A C7   ..H0E.!..X..r...
000050  C7 36 7A 7A 25 3B C1 13  52 23 AD B9 A4 68 BB 3A   .6zz%;..R#...h.:
000060  59 23 3F 45 BC 57 83 80  02 20 59 AF 01 CA 17 D0   Y#?E.W... Y.....
000070  0E 41 83 7A 1D 58 E9 7A  A3 1B AE 58 4E DE C2 8D   .A.z.X.z...XN...
000080  35 BD 96 92 36 90 91 3B  AE 9A 01 41 04 9C 02 BF   5...6..;...A....
000090  C9 7E F2 36 CE 6D 8F E5  D9 40 13 C7 21 E9 15 98   .~.6.m...@..!...
0000A0  2A CD 2B 12 B6 5D 9B 7D  59 E2 0A 84 20 05 F8 FC   *.+..].}Y... ...
0000B0  4E 02 53 2E 87 3D 37 B9  6F 09 D6 D4 51 1A DA 8F   N.S..=7.o...Q...
0000C0  14 04 2F 46 61 4A 4C 70  C0 F1 4B EF F5 FF FF FF   ../FaJLp..K.....
0000D0  FF 02 40 4B 4C 00 00 00  00 00 19 76 A9 14 1A A0   ..@KL......v....
0000E0  CD 1C BE A6 E7 45 8A 7A  BA D5 12 A9 D9 EA 1A FB   .....E.z........
0000F0  22 5E 88 AC 80 FA E9 C7  00 00 00 00 19 76 A9 14   "^...........v..
000100  0E AB 5B EA 43 6A 04 84  CF AB 12 48 5E FD A0 B7   ..[.Cj.....H^...
000110  8B 4E CC 52 88 AC 00 00  00 00                     .N.R......

Message header:
 F9 BE B4 D9                                       - main network magic bytes
 74 78 00 00 00 00 00 00 00 00 00 00               - "tx" command
 02 01 00 00                                       - payload is 258 bytes long
 E2 93 CD BE                                       - checksum of payload

Transaction:
 01 00 00 00                                       - version

Inputs:
 01                                                - number of transaction inputs

Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF                                       - sequence

Outputs:
 02                                                - 2 Output Transactions

Output 1:
 40 4B 4C 00 00 00 00 00                           - 0.05 BTC (5000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 1A A0 CD 1C BE  A6 E7 45 8A 7A BA D5 12  - pk_script
 A9 D9 EA 1A FB 22 5E 88  AC

Output 2:
 80 FA E9 C7 00 00 00 00                           - 33.54 BTC (3354000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 0E AB 5B EA 43  6A 04 84 CF AB 12 48 5E  - pk_script
 FD A0 B7 8B 4E CC 52 88  AC

Locktime:
 00 00 00 00                                       - lock time

```

And here's the really important part:

```
Output 1:
 40 4B 4C 00 00 00 00 00                           - 0.05 BTC (5000000)

```

Note that we've used 8 bytes (or 64 bits) worth of hex to represent the amount, in Satoshis (0.00000001 BTC, the smallest possible unit). At peak, approximately 21 million BTC will exist, so that's the most you could possibly have in your wallet, even if you controlled all the bitcoins in the world. the maximum value storable in the standard 9 bytes would be 0xFFFFFFFFFFFFFFFF~=1.84e+19 satoshis or 184,467,440,737 BTC, or about 8,784 times the number of coins that will ever exist.

So the technical upper limit for bitcoins sendable in a single transaction is 4.7e+21 but the functional upper limit is 21 million, since that's all there will ever be.

Even if you're using an alt chain that never stops inflating via block rewards, at the standard 50 coins per 10 minute block it would take more than 9 billion years for the entire network to accumulate enough coins to breach that upper limit.

TL;DR: There's a limit but you shouldn't ever under any circumstances have to worry about it.

> **Comments:**
> **username_3**: Alternate TL;DR ... if you're close to that value you're rich enough to hire a team of PHD's to watch that for you  ;)  
> **username_4**: At around 53 bits(100 mio BTC) double precision becomes a problem. This should not be a problem for the core bitcoin code which uses 64 bit integers, but might cause problems with the JSon API, if the values in there are interpreted as double. Obviously that's not a problem with bitcoin, since the 21mio limit is smaller than that (alt chains are a different issue).  
> **username_2**: Wait, someone is using floats for financial transactions? Didn't we already learn this lesson a long long time ago?  
> **username_4**: @username_2 In some languages, such as lua(and I think javascript) `double` is all you have. It's only a problem if you're using the fractional part of binary floatingpoints. If you use `double` to represent an integral amount of satoshis that's no problem.  And decimal floatingpoints (such as .net's `System.Decimal`) can even use the decimal part.  

---

