5

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 ?

  • 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 Sep 19 '12 at 16:48
  • 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 Sep 19 '12 at 18:35
7

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

| improve this answer | |
  • 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 Sep 19 '12 at 18:32
  • 3
    @boussac: Yes, these limits are checked upon reception. See here (MAX_MONEY is exactly 21,000,000 BTC). – Stéphane Gimenez Sep 19 '12 at 19:17
  • ...or "0 to 2,100,000,000,000,000" satoshis. ;) – RLH Oct 15 '14 at 13:17
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:

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.

| improve this answer | |
  • 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 ;) – goodguys_activate Sep 19 '12 at 19:13
  • 1
    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 Sep 20 '12 at 10:17
  • 1
    Wait, someone is using floats for financial transactions? Didn't we already learn this lesson a long long time ago? – David Perry Sep 20 '12 at 18:55
  • @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 Sep 22 '12 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.