Isn't there a value stored in the output? If I spend a single output, and create multiple outputs of my own, don't my outputs have values stored as int_64 in the blockchain indicating how much is being spent along with the public key (or hash of the public key) allowing the private key holder to spend that output?

Requiring a hard fork to add extra decimal places is a significant, breaking change to the bitcoin protocol and should not be taken lightly or assumed to be part of the specification.

I was only making that clear.

And they will never be infinitely divisible as there would have to be an infinite number of bits.

Fair enough. In any event, it's difficult to imagine 8 decimal places not being sufficient. I still don't understand why it isn't possible to always be able to add one more decimal place to the right.

The protocol currently uses integer math. Values are 64 bit. If I send 1 BTC to myself, in the transaction that shows up at 100,000,000.

In other words, the fundamental unit of the system is 1/100,000,000 of a BTC (commonly nicknamed "one satoshi"). The software does all math in terms of satoshis, but displays BTC to the user by scaling.

I sorta suspect that we'll switch to a 128 bit representation for technological reasons (wider CPUs) long before we need more digits for economic reasons. Such a switch would give us some combination of more headroom and more dividing room. It would also require a more-or-less hard fork.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

A 64 bit int can hold the entire supply (8 decimals in all) in one integer, 8,700 times over. 4 more decimals could be added and still almost hold the entire supply in one int64 (18.5 vs 21 with a bunch of zeroes). If you limit the left hand side, you could go much further than 4 more decimals.

A 64 bit int can hold the entire supply (8 decimals in all) in one integer, 8,700 times over. 4 more decimals could be added and still almost hold the entire supply in one int64 (18.5 vs 21 with a bunch of zeroes). If you limit the left hand side, you could go much further than 4 more decimals.

But why would you do that? Changing the way you interpret the integer is what breaks everything, not the size of the field. If you are going to make the change, make the change big.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

What you should argue is, if you are going to make the change, make the change smart. Doubling the size of every integer in the block chain so that you can go to 30 zeroes seems a bit odd from that standpoint. I wonder why satoshi didn't just go to 11 decimals though since that wouldn't have changed anything.

Yes the coins are lost forever. No amount of hash-power that we could reasonably posses will ever find all or even a few of the priv keys.

nothing that we could possess TODAY. Technology marches on

Quote

If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this computer. But that’s just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. If all of this energy could be channelled into a single orgy of computation, a 219-bit counter could be cycled through all of its states. These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Of course there is a small possibility that the algorithms themselves could succumb to new technology and new understandings, such that finding the private key for a given hash of a public key does not require brute force calculation of all keypairs until a matching one is found.

For a "Satoshi" to even be worth one penny, which is the smallest unit of a dollar, we would need bitcoins to be valued at TEN MILLION DOLLARS. This is ludicrously high. Some countries don't even use pennies, like New Zealand. Considering our inflation, by the time we have 10 million dollar bitcoins, 1 cent will be even more completely worthless than it is now, pushing to limit to a 10 cent saroshi.Keep in mind, even though the dollar has a lower limit of 1 cent, finance and accounting still trades and deals with fractions of a cent. This is also possible with a bitcoin lower limit. You can make up any division of any currency by arithmetic necessity in accounting.

If the Singularity follows Moore's Law and becomes exponentially intelligent in a relatively short period of time, when do you suppose it will acquire enough processing capacity to recreate the lost bitcoins?

If the Singularity follows Moore's Law and becomes exponentially intelligent in a relatively short period of time, when do you suppose it will acquire enough processing capacity to recreate the lost bitcoins?

No. Please do some research instead of asking why not.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.

Bitcoins are never lost... they are always there... you just lose access to them.

Sorry, but with 100PHs network, you can easily "guess" a collision of sha-256, or guess a collision of a collision of a sha-256.

If it were 1:999999999999-trillion-trillion-trillion to find 1 collision... You could find it in 1 try, on some address on the network, just as easily.

Now 256-bits is only 32-bytes, represented as 64-bytes as HEX-values.EG: "BOB" = 54fcf974eabb0444320acd2835977b2c686b916162e6571668ac45db549da031

A collision for that could be the hash for the word "SUE", or "FRED", or "CAT", though that is hashed again.EG: 54fcf974eabb0444320acd2835977b2c686b916162e6571668ac45db549da031 => 96faee69f068c221ad557cbba0c0e7afdd9d3a18ffa2d81f2290d72e2818111a

Now that hash, which could have been "BOB" or "SUE" or "FRED" or "CAT"... has collisions also, which could be "FISH", or "SNOT", or "PEPSI", or "PASSWORD", or "GOLD"... Multiplied by the number of collisions that were possible from the first conversion.

Thus, now there are multiple more "acceptable" hashes/keys that will unlock any of those wallets. Because you are still converting a single-answer-password into a multi-possible-answer-hash, into another multi-possible-answer-hash.

You can test this with something simple like CRC32, and see that you now have millions of "keys" that are valid, instead of only a hundred, by double-encryption, with the same type of encryption. (That is the real reason the whole project was abandoned.)

P.S. Doesn't take a computer long to create 32-bytes randomly and stuff those values into an off-line wallet to see if it unlocks it. Since those accounts are not being monitored by anyone. Since the whole chain, all accounts, are already downloaded on his computer. Takes but a few seconds to make one random key, and try it on all existing accounts, before generating another random key, and trying it on all of them again.