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

[knight22]

I have read some topics that said yes to this answers and other not... So is it technically and easily possible to do that?

[1714982051]

1714982051

[1714982051]

1714982051

[kjj]

It would require a protocol change because the protocol operates on discrete units of 1/100000000 BTC, often known informally as a satoshi.  A protocol change is not easy, but if we ever get to the point where 1 protocol unit is a meaningful amount of value, it can be done.

[kokojie]

It can be done, and it's not easy. I don't think you need to worry about it for the next 10 years at least.

[SaltySpitoon]

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

You can't divide by a single zero, so I don't know how you would divide by eight zeros.

[walruscode]

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

You can't divide by a single zero, so I don't know how you would divide by eight zeros.

http://i217.photobucket.com/albums/cc22/jpwanabe/gifs/clap.gif

[scintill]

It can be done, and it's not easy. I don't think you need to worry about it for the next 10 years at least.

I lay awake at night, worrying that by the next day, Bitcoin prices will have gone beyond 10^8 USD and the divisibility limit will be a problem.

[cypherdoc]

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

You can't divide by a single zero, so I don't know how you would divide by eight zeros.

isn't there a difference btwn the words with and by?

[Etlase2]

Yes let's make fun of someone for not speaking English as a first language. Hilarious.

[SaltySpitoon]

Yes let's make fun of someone for not speaking English as a first language. Hilarious.

If you say its not a tiny bit amusing, you are lying. There's a difference between poking a bit of fun at bad wording due to translation errors, etc, and being a jerk about it.

English isn't necessarily my first language either, kind of learned it at the same time as Portuguese (because of the area I was in) and I started learning Spanish/German when I was a very young as well.

[grondilu]

I have read some topics that said yes to this answers and other not... So is it technically and easily possible to do that?

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

Easily?  Almost certainly not.  I'm not in the dev team, but if you look at the code you'll see that the "amount" field is coded with a fixed size integer, not a BigNum or something.  So I guess if we'd really have to divide bitcoins to more than 10^8, a lot of code rewrite would be required.

Also, consider that it would probably require some clear conditional test on the code somewhere:

Code:

if (blocknumber < BLOCK_NUMBER_AT_DIVISIBILITY_CHANGE) {
   // do as normal
   ;
} else {
   // use the new algorithm for increased divisibility
   ;
}

[Foxpup]

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).

[scintill]

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).

Just in case, I created an infinite_divisibility branch we can start working on.

[grondilu]

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.

Yeah.  True.   But if you mention that, it's hard not to look like a smart ass, isn't it?

[acoindr]

The world won't ever need more than 8 decimal places IMO.

Right now U.S. dollars are the world's reserve currency, and there are trillions of them. But those are inflated dollars. That's 1,000,000,000,000 plus (1 followed by 12 zeros).

Have you ever heard people say candy bars used to cost a $0.05 or a gallon of gas $0.10? Now candy bars cost almost $1 and a gallon of gas about $4. That's about 2000% and 3000% inflation respectively.

If there was no inflation then the world's currency supply could be greatly reduced. Just 1 bitcoin could cover the same as $20 to $30 because bitcoins can't be inflated. That's the same as a world currency supply of about 50,000,000,000 dollars (50 billion dollars).

[ildubbioso]

The more time passes, the more that codebase grows, and
the harder it'll get. A very Y2K-ish type problem.

Yes, I tought it too. Why don't make it as soon as possible? I think everybody would accept this change.

[kokojie]

The world won't ever need more than 8 decimal places IMO.

Right now U.S. dollars are the world's reserve currency, and there are trillions of them. But those are inflated dollars. That's 1,000,000,000,000 plus (1 followed by 12 zeros).

Have you ever heard people say candy bars used to cost a $0.05 or a gallon of gas $0.10? Now candy bars cost almost $1 and a gallon of gas about $4. That's about 2000% and 3000% inflation respectively.

If there was no inflation then the world's currency supply could be greatly reduced. Just 1 bitcoin could cover the same as $20 to $30 because bitcoins can't be inflated. That's the same as a world currency supply of about 50,000,000,000 dollars (50 billion dollars).

Actually BTC most definitely will need more than 8 decimal places in the distant future, because certain amount of bitcoin gets destroyed per year due to various factors such as carelessness. it's just that the future is so distant, there's no point worrying about it now.

[acoindr]

The world won't ever need more than 8 decimal places IMO.

Right now U.S. dollars are the world's reserve currency, and there are trillions of them. But those are inflated dollars. That's 1,000,000,000,000 plus (1 followed by 12 zeros).

Have you ever heard people say candy bars used to cost a $0.05 or a gallon of gas $0.10? Now candy bars cost almost $1 and a gallon of gas about $4. That's about 2000% and 3000% inflation respectively.

If there was no inflation then the world's currency supply could be greatly reduced. Just 1 bitcoin could cover the same as $20 to $30 because bitcoins can't be inflated. That's the same as a world currency supply of about 50,000,000,000 dollars (50 billion dollars).

Actually BTC most definitely will need more than 8 decimal places in the distant future, because certain amount of bitcoin gets destroyed per year due to various factors such as carelessness. it's just that the future is so distant, there's no point worrying about it now.

Right now the market cap for bitcoins is about $90 million (about $10 times 9 million bitcoins in existence). What percentage of bitcoins do you think has been lost since 2009? What percentage of your bitcoin wealth do you lose carelessly yearly?

[knight22]

Right now the market cap for bitcoins is about $90 million (about $10 times 9 million bitcoins in existence). What percentage of bitcoins do you think has been lost since 2009? What percentage of your bitcoin wealth do you lose carelessly yearly?

Check this thread to give you an idea:
https://bitcointalk.org/index.php?topic=7253.0

[davidspitzer]

even if BTC end up being $2000 each eight decimal places is a very small fraction

[acoindr]

Right now the market cap for bitcoins is about $90 million (about $10 times 9 million bitcoins in existence). What percentage of bitcoins do you think has been lost since 2009? What percentage of your bitcoin wealth do you lose carelessly yearly?

Check this thread to give you an idea:
https://bitcointalk.org/index.php?topic=7253.0

The highest total lost bitcoins I see in that (unofficial) thread is the last post at about 73K BTC.

73,000 is .81% of 9,000,000 - the approximate number of bitcoins now in existence.

What's your point? You don't think a currency could work losing less than one percent of its total every 3 years?

It would take over 300 years to completely deplete it at that rate.

And keep in mind those reported losses are as people get used to dealing with this new currency.

[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.

[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

[grondilu]

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

That may create a fork indeed.  A consensus would be required.

But the idea of allowing the code to behave differently depending on the height of the block was mentioned by Satoshi himself on this forum, iirc.

[BkkCoins]

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

This is just newbie sillyness. The devs have mentioned many times that an extension of decimal places could be coded into the blockchain if ever required. I don't know why people are wasting so much effort on this topic as this is way, way off in some imaginary future that will require other client/blockchain adjustments before getting to this point. None of this means a new currency is created - only that changes are made to the client and consensus among users to accept and use the new client.

The 0.7.0 release today has 3 new BIP in it. Extending the decimals is likely discussed, coded and accepted in a similar way.

[Foxpup]

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.

Erm, no, you can store an infinte number of rational numbers. Representing the set of all real numbers (both rational and irrational) is harder, and may pose a potential security risk for the infinite divisibility fork: creation of infinite bitcoins through an infinite overflow caused by sending an irrational number of bitcoins (proving that bounds checking is still important, even when dealing 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".

It was a joke. People are constantly claiming that bitcoins are "infinitely" divisibile, which is of course completely ridiculous. And an "arbitrary" range is equally ridiculous if it is taken to mean "anything up to infinity", I was just pointing that out by taking that statement to it's logical extreme. I wasn't really expecting my comment to derail the whole thread. Oh well.

[kjj]

It was a joke. People are constantly claiming that bitcoins are "infinitely" divisibile, which is of course completely ridiculous. And an "arbitrary" range is equally ridiculous if it is taken to mean "anything up to infinity", I was just pointing that out by taking that statement to it's logical extreme. I wasn't really expecting my comment to derail the whole thread. Oh well.

The term "arbitrary" has a long history in computing.  It is always understood to mean "no particular artificial limit", and not "infinite".  Computer science may be a branch of mathematics, but it is not a branch that cares about literal infinity.

[DannyHamilton]

Erm, no, you can store an infinte number of . . .

Until you mentioned it, this topic never had anything to do with infinitely divisible. . .

It was a joke. . .

Obviously it was a joke. I was just pointing out that it your comedic timing was off a bit.  The joke would work better if you waited until someone mentioned infinite divisibility before making your joke about countable infinity vs. uncountable infinity.

[exdirrk]

It can be done, and it's not easy. I don't think you need to worry about it for the next 10 years at least.

I lay awake at night, worrying that by the next day, Bitcoin prices will have gone beyond 10^8 USD and the divisibility limit will be a problem.

Counting down the days.

[dree12]

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.

Erm, no, you can store an infinte number of rational numbers. Representing the set of all real numbers (both rational and irrational) is harder, and may pose a potential security risk for the infinite divisibility fork: creation of infinite bitcoins through an infinite overflow caused by sending an irrational number of bitcoins (proving that bounds checking is still important, even when dealing with infinite memory).

With an countably infinite memory, you can store a countably infinite number of real numbers. This is easily derived through basic set theory. However, the process of storing the real numbers will take a countably infinite amount of time, unless the operation is atomic, so in practice even given an infinite memory, storing arbitrary reals is impossible.