Is a bitcoin can be divided with more than 8 zeros or not??

[casascius]

By the time we get to a point where 1 Satoshi is a usable value, the blockchain might only be used for large balances and settling balances among institutions the way bankwires are used now.  Imagine one day they decided USD bankwires could only be sent in whole dollar increments... the world wouldn't end, and your checking account would still be in dollars and cents.  Even if the protocol never changes to accommodate this, you might be able to trade in sub-Satoshi units with whatever off-blockchain merchant/banking services evolve between now and then.

[1713931893]

1713931893

[1713931893]

1713931893

[1713931893]

1713931893

[1713931893]

1713931893

[1713931893]

1713931893

[disclaimer201]

It won't be a problem. For lower values, just use Litecoins.

[Dansker]

By the time we get to a point where 1 Satoshi is a usable value, the blockchain might only be used for large balances and settling balances among institutions the way bankwires are used now.  Imagine one day they decided USD bankwires could only be sent in whole dollar increments... the world wouldn't end, and your checking account would still be in dollars and cents.  Even if the protocol never changes to accommodate this, you might be able to trade in sub-Satoshi units with whatever off-blockchain merchant/banking services evolve between now and then.

I think this is very true.

All the worrying in this thread assumes that people will deal directly with bitcoins transfers for everyday use in the future.

If bitcoin value does explode to the point where it needs more than 8 decimals to function for the everyday user, it is very likely that systems have been built on bitcoin, and that other systems overlay those.

This will of course mean less anonymity and control for the basic user, but this is unavoidable if bitcoin is succesful, just look at Apple: They take away user autonomy and control in a trade for ease of use and coolness, and the average user loves it.

[franky1]

the blockchain only accepts values in whole satoshi's so unless you develop your own system to send more then a / 100000000th of a BTC the block chain will just grab the / 100000000th's of a BTC and leave you with the remaining useless left overs.

goodluck, trying

[casascius]

Bitcoin amounts are - as of today - encoded as 64 bit integers.

Moving to 128 bit integers would be more than enough to keep
us safe for a *very* long time...

There would be no need to move to 128 bit integers. Not all of the 64 bits are currently being used.

Mmmh. I could be wrong of course, but ... my understanding is that the full 64bit is
used to encode a amount in satoshi and is multiplied by 1e-8 to get an amount of
bitcoins.

Pointers to the code to back your statement ?

Simple math:  64 bits capacity: 1.84x10^19
Maximum number of satoshis in current system: 2.1x10^15
So there's at least 3 decimal places for the taking.
Or better yet, these extra (8+) bits could be used as an exponent, a signed scaling factor of 10^n.  Since all existing amounts will have 0's in these highest bits, we simply declare that this means satoshis * 10^0, which is equal to satoshis * 1, making all existing amounts backward compatible.  Put -2 in this field (11111110), and the remaining bits will be in hundredths of satoshis.

[Etlase2]

I'm not sure what you wrote means znort, but 64 bits is 18.4x10^18, while all the satoshis in existence is 21x10^14, meaning you can get 3 more zeros for free, and a fourth if you presume no one will have more than 9.9999...m bitcoin in a single account.

edit: beaten

[kjj]

The width of the field is not the problem, the meaning is.  Hiding silly codes in the top few bits is just as much work as just making the field wider and changing the scaling factor.

And all of this talk of digits makes me sad.  The field is binary.  log₂2.1e15=~50.899 bits

[franky1]

You entirely missed the point of this thread.

if someone sends you 0.0123456 payment you receive 0.0123456 nothing is lost.

the only loss happens if block chain accepts 0.0123456000000000000000000000000000000000000001 but only returns 0.0123456

try the command bitcoind- sendtoaddress <insert an address> 0.0123456000000000000000000000000000000000000001 and see if the block chain accepts it.

then you will know for sure if you can get anything smaller then a satoshi accepted by the blockchain.

even on exchanges sites they receive payments in BTC (multples of satoshi) and they give out BTC (multiples of satoshi)
it does not matter what thie database of trades shows. its a database of digits that represent BTC not an actual satoshi/BTC itself.

when your cashing out a value inside an exchange, that happens to be more then a 8digit trade listed in database you will only get whole satoshi as oppose to the web exchange database showing more then 8 digits

but try the command. see what happens

[Etlase2]

The width of the field is not the problem, the meaning is.  Hiding silly codes in the top few bits is just as much work as just making the field wider and changing the scaling factor.

Doesn't require more bandwidth or storage though.

And all of this talk of digits makes me sad.  The field is binary.  log₂2.1e15=~50.899 bits

Could you explain further please.

[casascius]

The width of the field is not the problem, the meaning is.  Hiding silly codes in the top few bits is just as much work as just making the field wider and changing the scaling factor.

...and then you have to do some sort of trickery to decide whether any given existing transaction from the past uses the new scaling factor or the old one.

The code isn't silly per se, it is simply decimal floating point.  Decimal floating point is the right choice versus binary, because Bitcoins are meant to be divisible in decimal fractions (unless you're Luke Jr, but fortunately all non-repeating binary numbers are representable in non-repeating decimal, but not so vice versa).

And all of this talk of digits makes me sad.  The field is binary.  log₂2.1e15=~50.899 bits

Yes, that's right.  So you mean log₁₀111011101011111000001011010000001110100000000000000 = ~110010.11100110001110010011101010111001 bits  

[dree12]

Technically?  Yes.  Any computer can deal with a wide, arbitrary range of numerical values.

Actually, no computer can, not even one with infinite memory, since an infinite amount of memory can only represent a countably infinite range of values, while the range of real numbers (not integers) is uncountably infinite. Fortunately, it is possible to infinitely divide an infinite range of integers without using non-integers for infinite future expansion (see Hilbert's paradox of the Grand Hotel for details), so this isn't an issue for Bitcoin. Though it's a moot point anyway since no computer in a finite universe can possibly have an infinite amount of memory in the first place, so bitcoins won't really be "infinitely" divisible until we extend the protocol beyond the physical limitations of our universe (this will require a hard fork).

A countably infinite amount of memory can represent any member of a continuum, which real numbers, complex numbers, etc. are. In fact, a countably infinite amount of memory can represent a countably infinite number of members of a continuum.

[dree12]

A countably infinite amount of memory can represent any member of a continuum, which real numbers, complex numbers, etc. are. In fact, a countably infinite amount of memory can represent a countably infinite number of members of a continuum.

No, unless I misunderstood Cantor.

You probably did.


It follows that:

[kjj]

but try the command. see what happens

No thanks.  I already know how the protocol works: it uses discrete units.

Nothing stops a third party from keeping track of fractions of protocol units, but they can't be exchanged on the network.

The width of the field is not the problem, the meaning is.  Hiding silly codes in the top few bits is just as much work as just making the field wider and changing the scaling factor.

Doesn't require more bandwidth or storage though.

And all of this talk of digits makes me sad.  The field is binary.  log₂2.1e15=~50.899 bits

Could you explain further please.

Meh.  8 more bytes per output isn't a huge deal.  By the time one protocol unit is a meaningful amount of value, 8 bytes will really be nothing.

The field doesn't have "digits", it has bits.  It has 64 of them, so it can represent any value from 0 to 2⁶⁴-1.  But, because of other network rules, it will never be higher than:

00000000 00000111 01110101 11110000 01011001 11100100 00000000 10010000

The width of the field is not the problem, the meaning is.  Hiding silly codes in the top few bits is just as much work as just making the field wider and changing the scaling factor.

...and then you have to do some sort of trickery to decide whether any given existing transaction from the past uses the new scaling factor or the old one.

The code isn't silly per se, it is simply decimal floating point.  Decimal floating point is the right choice versus binary, because Bitcoins are meant to be divisible in decimal fractions (unless you're Luke Jr, but fortunately all non-repeating binary numbers are representable in non-repeating decimal, but not so vice versa).

The trickery in question has a name, tx.version.

The silliness of floating point here is up for debate.  I think that the simplicity of regular old binary math more than makes up for the 8 bytes per txout cost.

[grondilu]

You probably did.

Yes.  But I notice that you are using all your memory to encode just one number.  Well ok, why not.

It follows that:

I'm not sure it is obvious that this is a consequence.  Seems interesting though.

I don't have your tool to include maths.  I'll use N to represent the integer set, and R for the real set.

What I would agree on, is that:

2^N = R^n,  where n is any finite integer.

Because you can basically use the hospital paradox to alternate location for each real.   The i-th real will have its bits on position numbers that are equal to i modulo n.   So that's fine.

But I very much doubt you can go to the limit and write:

2^N = R^N

[dree12]

It follows that:

I'm not sure it is obvious that this is a "consequence".  Seems interesting though.  

Although it is a simple derivation from the theorems of set theory, the intuitive explanation can be complex. Here's an example that should demonstrate how a countably infinite amount of reals between 0 and 1 and be stored. We start with our infinite tape, beginning at position zero and storing a single bit each. We can encode the numbers in binary, with the "0." being assumed and only the decimal point encoded, and assume uniqueness of representation is not important (if it is, we can define the unique representation as the one ending in only zeroes when there is a choice). From position zero, each position's bit is used in exactly one number. Here's the mapping:

Pos#	nth real number encoded
0	0
.
1	0
2	1
.
3	0
4	1
5	2
.
6	0
7	1
8	2
9	3
.
10	0
11	1
12	2
13	3
14	4
.
15	0
16	1
17	2
18	3
19	4
20	5
...

This is a variation of Cantor's proof that the rationals are countable, and in fact the derivation of the theorem relies on the countability of an ordered pair of members of a countable set. Hopefully this sheds some light.

[grondilu]

Although it is a simple derivation from the theorems of set theory, the intuitive explanation can be complex. Here's an example that should demonstrate how a countably infinite amount of reals between 0 and 1 and be stored. We start with our infinite tape, beginning at position zero and storing a single bit each. We can encode the numbers in binary, with the "0." being assumed and only the decimal point encoded, and assume uniqueness of representation is not important (if it is, we can define the unique representation as the one ending in only zeroes when there is a choice). From position zero, each position's bit is used in exactly one number. Here's the mapping:

Pos#	nth real number encoded
0	0
.
1	0
2	1
.
3	0
4	1
5	2
.
6	0
7	1
8	2
9	3
.
10	0
11	1
12	2
13	3
14	4
.
15	0
16	1
17	2
18	3
19	4
20	5
...

This is a variation of Cantor's proof that the rationals are countable, and in fact the derivation of the theorem relies on the countability of an ordered pair of members of a countable set. Hopefully this sheds some light.

Oh yeah, I think I get it.  A group of one, then a group of two, then a group of three...   So you can indeed store an infinite number of reals.    That's pretty smart.  Thanks.  I've learnt something today.

[DannyHamilton]

Technically?  Yes.  Any computer can deal with a wide, arbitrary range of numerical values.

Actually, no computer can, not even one with infinite memory. . .

Foxpup, I believe you are mistaken.  Until you mentioned it, this topic never had anything to do with infinitely divisible.

The OP asked only about more than 8 decimal places:

. . . So is it technically and easily possible to do that?

and grondilu, whom you replied to, only spoke of an arbitrary range.

Computers can certainly deal with more than 8 decimal places. I suppose deciding if it can deal with a "wide, arbitrary range" would depend on the definition of "wide".

[franky1]

i love seeing when people spasm at theories of relativity, time and worm holes trying to argue they know best without putting any practical testing into such theories. but your missing the fundamental point,

when mining the blockchain. if you managed to mess around with a block to make it 50 decimals long for instance. giving it back to the chain it would get rejected,

and as its only a 'copy' of a block other nodes have, it will just get forgotten about as if it never happened.. REJECTED basically

no loss, but your time in trying.

unlike getting a FIAT penny coin and cutting it into metal shards.. it is not forgotten about it as you still have the metal fillings in your hand. the only difference is that no one will want metal shards off of you..

the benefit of crypto block chain over FIAT transactions is that everything is confirmed and verified and rejects get ignored.

you will never find a 50 decimal bitcoin transaction on the system, it will just get ignore and basically appear as if the transaction never occurred.

if you ever managed to send a fresh transaction into the blockchain with 50 decimals it would not get accepted by the nodes and forgot about. leaving your transaction history only showing before the transaction occurred.

[grondilu]

i love seeing when people spasm at theories of relativity, time and worm holes trying to argue they know best without putting any practical testing into such theories. but your missing the fundamental point,

when mining the blockchain. if you managed to mess around with a block to make it 50 decimals long for instance. giving it back to the chain it would get rejected,

and as its only a 'copy' of a block other nodes have, it will just get forgotten about as if it never happened.. REJECTED basically

no loss, but your time in trying.

As mentioned earlier in this thread, the protocol would necessarily have to proceed blocks differently, depending on the height of the block in the block chain.

[franky1]

changing the protocol to allow nodes to accept blocks containg EG 50 decimals is not something one can do alone on ones own system as the other users will still be using the bitcoin standard protocol, 
so it would have to be a world wide change that affects every person.... basically getting everyone to download a new client and stop using the old one.

while your at it.. call it BBBBBBBitcoin as its no longer the 8decimal coin we use now.

thats not breaking a satoshi.. thats called inventing a new currency