Bitcoin Forum
December 11, 2016, 11:53:27 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Longer ints for bitcoin  (Read 1377 times)
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
February 09, 2011, 02:53:10 PM
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481457207
Hero Member
*
Offline Offline

Posts: 1481457207

View Profile Personal Message (Offline)

Ignore
1481457207
Reply with quote  #2

1481457207
Report to moderator
1481457207
Hero Member
*
Offline Offline

Posts: 1481457207

View Profile Personal Message (Offline)

Ignore
1481457207
Reply with quote  #2

1481457207
Report to moderator
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
February 09, 2011, 03:55:28 PM
 #2

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.

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
Anonymous
Guest

February 09, 2011, 03:56:42 PM
 #3

Since Bitcoin will only work on earth
Challenge accepted.
Cdecker
Hero Member
*****
Offline Offline

Activity: 487



View Profile WWW
February 09, 2011, 04:05:29 PM
 #4

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]

Want to see what developers are chatting about? http://bitcoinstats.com/irc/bitcoin-dev/logs/
Bitcoin-OTC Rating
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 09, 2011, 04:14:01 PM
 #5

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

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
February 09, 2011, 05:14:48 PM
 #6

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

genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
February 09, 2011, 08:35:05 PM
 #7

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
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 09, 2011, 08:37:50 PM
 #8

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
Full Member
***
Offline Offline

Activity: 210


View Profile
February 12, 2011, 05:53:28 PM
 #9

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.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
RHorning
Full Member
***
Offline Offline

Activity: 210


View Profile
February 12, 2011, 06:33:20 PM
 #10

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.

1FLK3uUT3Vup5JtkGJVXKHAoS3AZWPcKdv
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
February 12, 2011, 09:34:48 PM
 #11

I do not think that we really need int128. Undecided

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

"Never invest unless you can afford to lose your entire investment." © S3052
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!