Author

Topic: What is the upgrade path of bitcoin? (Read 8069 times)

full member
Activity: 150
Merit: 100
July 19, 2010, 09:42:06 PM
#3
Ah ok, it sounds like it's quite flexible then Cheesy

I wasn't suggesting that those two things were vitally important that we fix them now, but they're just good ways to illustrate potentially "breaking" changes which need to be made, it's good to know that the code is flexible enough to handle such changes.
legendary
Activity: 1652
Merit: 1186
Chief Scientist
July 19, 2010, 09:07:38 PM
#2
For a gradual change I suppose a client could be released which understand both the old and new ways, but only uses the old way, then after some time (perhaps take some measurements and estimate what perentage of the network is running the new version) release a version which uses only the new version, and all the old versions would get kicked off the network?
There are already a few places in the source code where that is done.
Quote
Are there any small changes which could be made to the client to make it more change proof, would they be worth considering implementing?
I think Satoshi's done a darn good job of anticipating future needs.  The wire protocol and database serialization formats both have version numbers, as do bitcoin addresses.  The core transaction mechanism is very flexible (I worry that it might be too flexible, but that's why we've got the TEST network to see if we can break it).

I can't think of anything simple that would make it more future-proof.  If you're worried about SHA256 getting broken or the 21quadrillion Bittiestcoins not being enough... then you worry too much.  Stop worrying, you'll just suffer from analysis paralysis and get nothing done.
full member
Activity: 150
Merit: 100
July 19, 2010, 07:07:25 PM
#1
I've seen a few topics recently (arbitrary precision bitcoins, breaking of SHA256) which would require a large change to how bitcoin works. What kind of upgrade path is in place for these sorts of things?

For a gradual change I suppose a client could be released which understand both the old and new ways, but only uses the old way, then after some time (perhaps take some measurements and estimate what perentage of the network is running the new version) release a version which uses only the new version, and all the old versions would get kicked off the network?

Are there any small changes which could be made to the client to make it more change proof, would they be worth considering implementing?
Jump to: