bitcoin maximum fraction unit? there are something less than satoshi unit?

[uray]

based on transaction structure https://en.bitcoin.it/wiki/Protocol_specification

The TxOut structure consists of the following fields:

Code:

Field Size	 Description	 Data type	 Comments
8	         value            int64_t	 Transaction Value
1+	         pk_script length var_int	 Length of the pk_script
 ?	         pk_script        uchar[]	 Usually contains the public key as a Bitcoin script setting up conditions to claim this output

so maximum transaction value is signed? 64-bit integer ?
why we use signed int? can transaction value be negative?

then

if its uin64_t so then max value would be
2^64-1 = 18,446,744,073,709,551,615

there are max 21 million cap of bitcoin so

Code:

184467440.73709551615
 21000000.00000000xxx

so we can add 3 more digits after satoshi unit?

if its int64_t then max value would be
2^63-1 = 9,223,372,036,854,775,807

Code:

92233720.36854775807
21000000.00000000xxx

still more 3 digits after satoshi unit?

[1715238972]

1715238972

[1715238972]

1715238972

[kjj]

You've got the xxx on the wrong end.  What we have is headroom.

[Cryddit]

So, yes, a uint64_t is capable of recording up to 18446744073709551615 Satoshi.  And the entire money supply of bitcoin only amounts to 2100000000000000 Satoshi, so there were a bit more than 3 orders of magnitude to play with.  

While the amount in a txin or txout can't be negative, you don't want to use an unsigned int for it, because internally you often compute differences, and those can be negative.  Remember, 'if (A - B < 0)' is *always* false with unsigned quantities.  So if you weren't super-careful you could get it wrong doing things like checking to see if the total outputs of a transaction are smaller than the total inputs.  

If you wanted to subdivide into smaller fractions, you could do that, up to 3 orders of magnitude.  All that would be required is raising the COIN constant, fiddling with the 'units.h' file, and a few other minor adjustments.  Of course, then you'd have to stick in code that interprets amounts written in the blockchain before the switchover differently.  

Conversely if you wanted to have a bigger money supply, which many altcoins do, you could do that too, by pretty much the same procedure plus modifying a few things like MAX_MONEY and the payout schedule, etc.

Or you could use something bigger than 64 bits, I guess.  But you don't need to.

[olalonde]

Is there any check in the transaction verification code that this value must be >= COIN ?

[kjj]

Is there any check in the transaction verification code that this value must be >= COIN ?

util.cpp, line 386.  (0.9.0)

[Cryddit]

Actually I found something today that affects the discussion.

The RPC calls to bitcoind transmit amounts using a 'double' quantity which has only 53 bits of significand precision. 

So an RPC call which represents anything up to the number of bitcoins that actually exist will suffer no rounding error.  With about twice the number of bitcoins that actually exist, small rounding errors would become inevitable.

This is something that can be fixed (you can encode the RPC as a string for example), but given the 21-million coin limit there is no need to fix it in Bitcoin. 

Alts with lots more coins though will have accounting bugs in any financial application using RPC calls to their coins unless they fix it.