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 ?
2
-
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 GimenezCommented Sep 19, 2012 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 PerryCommented Sep 19, 2012 at 18:35
Add a comment
|
2 Answers
0 to 21 million BTC. (Yes, 0-BTC transactions are allowed as long as they have a fee.)
-
That makes sense but is this the validation performed by a compliant client when checking an incoming transaction message for inclusion in its pool?– boussacCommented Sep 19, 2012 at 18:32
-
3@boussac: Yes, these limits are checked upon reception. See here (
MAX_MONEYis exactly 21,000,000 BTC). Commented Sep 19, 2012 at 19:17 -
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 [email protected]....
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.
answered Sep 19, 2012 at 18:29
-
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 ;) Commented Sep 19, 2012 at 19:13
-
1At 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). Commented Sep 20, 2012 at 10:17
-
1Wait, someone is using floats for financial transactions? Didn't we already learn this lesson a long long time ago? Commented Sep 20, 2012 at 18:55
-
@DavidPerry In some languages, such as lua(and I think javascript)
doubleis all you have. It's only a problem if you're using the fractional part of binary floatingpoints. If you usedoubleto represent an integral amount of satoshis that's no problem. And decimal floatingpoints (such as .net'sSystem.Decimal) can even use the decimal part. Commented Sep 22, 2012 at 16:12