Longer ints for bitcoin

[genjix]

Whether the precision should be made larger from int64 to int128

I'm sure the inventors of the internet didn't guess that ipv4 addresses would become exhausted. It's not a big deal to double the precision and much easier to change now than in the future.

In the future if there's multiple implementations, then getting a universal upgrade from all clients will be impossibly difficult.

[1714790636]

1714790636

[1714790636]

1714790636

[Cdecker]

Since Bitcoin will only work on earth (speed of light and everything) we only have to consider the earths population: 7 billion people currently.

That's ~2^33 (don't you love working in binary?)
Given 2^64 minimal fragments of a bitcoin we still have 2^64/2^33 ~= 2^31 = 2147483648 fragments per person, or expressed in other terms: every living person on earth can have an average of 21.47 Bitcoins.

Anyway since making the change would break all signatures, we'd have to run both protocols in parallel, making it as hard now as it'll be in a few years.

[Anonymous]

Since Bitcoin will only work on earth

Challenge accepted.

[Cdecker]

Challenge accepted.

Shall we open another thread? I don't want to stray too much from the subject.

[OT]Light needs 20 minutes to travel from Mars to Earth, even assuming we could get a client up there it'd be much more practical to establish a MarsCoin and let it build up resources locally, rather than trying to tie it to EarthCoin ^^
The better option is to set up an exchange that allows to buy MarsCoin for EarthCoin should we need them[/OT]

[theymos]

Given 2^64 minimal fragments of a bitcoin we still have 2^64/2^33 ~= 2^31 = 2147483648 fragments per person, or expressed in other terms: every living person on earth can have an average of 21.47 Bitcoins.

The numbers don't need to be unique, so BTC per person isn't important. Each person on Earth is even now capable of sending 92 billion BTC at once (if the BTC existed).

Maybe precision will need to be increased in 50+ years. This can be done without breaking old signatures by defining the first bit of the int64 to be some sort of "enhanced precision" flag. Money is a signed int64, so this is guaranteed not to have been used.

We'll probably hit the 2106 time overflow before we need to increase money precision. We can then fix all the problems at once.

[Luke-Jr]

Someone care to explain how precision even could be increased? It doesn't seem possible from what i know of the Bitcoin network.

[genjix]

Someone care to explain how precision even could be increased? It doesn't seem possible from what i know of the Bitcoin network.

Everybody upgrades their client to use the new precision.

[ribuck]

Everybody upgrades their client to use the new precision.

We should make sure that the existing client would see these micro-transactions (with the sign bit "set") as zero transactions. Graceful degradation, in other words.

Then, in 2016 or whenever the extra bits are needed, people will need to upgrade before they can spend the micro-transaction, but nothing breaks if they don't upgrade.

[RHorning]

Challenge accepted.

Shall we open another thread? I don't want to stray too much from the subject.

I already did:  http://bitcointalk.org/index.php?topic=506.0

I've given this issue more than a little thought, and it is something that could have some more effort put into it.  A related concept is how you can keep "sub-nets" of some sort synched with each other if they weren't directly linked to the main internet with a presumption of ping times less than 1 second.  This could include 3rd world countries where Bitcoins could be shared on a thumb drive and shared by SneakerNet or between LANs that might have their external connections severed due to natural/man-made disasters (including war or civil unrest like what happened this month in Egypt).

Making the Bitcoin protocol a bit more robust to deal with this issue could be useful, particularly if it is going to be used as a cash-like currency.

[RHorning]

Someone care to explain how precision even could be increased? It doesn't seem possible from what i know of the Bitcoin network.

Everybody upgrades their client to use the new precision.

Since this would be a relatively benign upgrade in the protocol that most people would accept, all it would really take is updating the version number in the protocol.... sort of like the IPv4 vs. IPv6 issue.  That would require an update of the clients, but it wouldn't be too bad.

The main issue is that at least for awhile the network would be forked like what happened with the 0.3.10 update, where users running the older software would not be able to recognize the newer blocks, but the older blocks (and transactions) would be recognized for awhile.  Doing a shift of that nature would end up having the majority of the network "voting" with their CPU processors, where the largest number of hashes would decide if the change is accepted or not.  It doesn't have to be "everybody", but those left behind on the smaller network would be quickly "forced" to make the switch.

If we do make such a switch, I hope it is done thoughtfully and other "bugs" in the protocol are strongly looked at as well.

Considering the substantial overhead in the current protocol, the few extra bytes for additional precision in the transactions is irrelevant and shouldn't even be an issue here, particularly if some of those overhead issues were cleaned up with a tighter protocol.

I don't see a graceful hand-off though, which would be the issue.  The main issue is that the "new" transactions that would have the extended precision data would be rejected by older clients on the first block that has one of these "new" precision transactions incorporated into that block.

[LZ]

I do not think that we really need int128.

I already did:  http://bitcointalk.org/index.php?topic=506.0

And here too: http://bitcointalk.org/index.php?topic=3009.0