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).
Topic: Is a bitcoin can be divided with more than 8 zeros or not?? (Read 4366 times)
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.
Erm, no, you can store an infinte number of . . .
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. Until you mentioned it, this topic never had anything to do with infinitely divisible. . .
It was a joke. . .
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.
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:
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. 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".
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.
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.
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
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.
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.
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.
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.
Technically? Yes. Any computer can deal with a wide, arbitrary range of numerical values.
Actually, no computer can, not even one with infinite memory. . .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".
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:
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.
| 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.
Quote
It follows that:
I'm not sure it is obvious that this is a "consequence". Seems interesting though. | 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.
You probably did.
Yes. But I notice that you are using all your memory to encode just one number. Well ok, why not.
Quote
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
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.
Quote
And all of this talk of digits makes me sad. The field is binary. log22.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 264-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.
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.
It follows that:
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).
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. log22.1e15=~50.899 bits
Yes, that's right. So you mean log10111011101011111000001011010000001110100000000000000 = ~110010.11100110001110010011101010111001 bits
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.
Quote
And all of this talk of digits makes me sad. The field is binary. log22.1e15=~50.899 bits
Could you explain further please.
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
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
Jump to: