Gavin, here's an idea: generalize the official client to handle multiple coins from the same codebase, or otherwise make it less difficult to maintain patches between codebases.
People will work on whatever scratches their itch. The onus is on you, the core developers, to make the development process receptive to incoming talent.
Topic: Nurturing AlternaCoins - page 3. (Read 4556 times)
I wish people would find more constructive things to do with their time, but I wish I could fly and never get old like Peter Pan, too.
How's the fix for the 'time travel exploit' in bitcoin going? That was found and fixed in alt chains a while back. I know you don't like alt chains but some of the stuff that's resulted from them have improved bitcoin - particularly edge case bugs as a result of attacks on the coins (The time travel exploit, the database log file growth bug a while back, etc).+1
I think alternate chains are a test bed for bitcoin. But just because Gavin you probably have a high stake in bitcoin ( i suspect) that shouldn't be a reason to try to get people to develop on the original bitcoin network.
People will do what they want with their time, just as you are.
I think having an alternative to bitcoin is a good thing in that it gives the new comers a CHOICE other than just having Pepsi or just MacDonalds.
How's the fix for the 'time travel exploit' in bitcoin going? That was found and fixed in alt chains a while back.
I don't think Bitcoin requires that fix. The feedback system in Bitcoin is either asymptotically stable in the Lyapunov sense or extremely close to being asymptotically stable. By extrememly close I mean that the maximum amplitude of oscillations that could be introduced in it is on the order of LSB in the very narrow floating-point format that is used to represent the difficulty.On the other hand the designers of alt-coins cranked up the gain in the feedback loop and applied asymmetric clipping in the feedback signal. The resultant system is probably still stable in the Lyapunov sense but no longer asymptotically stable.
Satoshi either understood the stability problem in the theory of closed-loop control systems or at least consulted somebody who understood the problems.
On the other hand the designers of alt-coins are like kids who stood up with microphone in front of the speakers and cranked up the gain on the amplifier.
http://en.wikipedia.org/wiki/Lyapunov_stability
I wish people would find more constructive things to do with their time, but I wish I could fly and never get old like Peter Pan, too.
How's the fix for the 'time travel exploit' in bitcoin going? That was found and fixed in alt chains a while back. I know you don't like alt chains but some of the stuff that's resulted from them have improved bitcoin - particularly edge case bugs as a result of attacks on the coins (The time travel exploit, the database log file growth bug a while back, etc). 
Well to date, no altcoin has done much other than tweak a few variables which doesn't take much in the development department. Solidcoin developers attempted a rewrite with microcash and have since disappeared before release without a word.
And then there are those that believe bitcoin has significant flaws that cannot be fixed by software updates and choose not to work on bitcoin.
And then there are those that believe bitcoin has significant flaws that cannot be fixed by software updates and choose not to work on bitcoin.
The amount of work required to maintain the alt-coins can be easily reduced by more than an order of magnitude.
Just cease to maintain them as forks in the github sense.
They need to be rewritten to Perl or other text-processing language.
The input to said Perl program should be the Bitcoin source tree and the list of the rather trivial changes that need to be made to various constants and identifiers in the Bitcoin source.
The output will be altcoin source tree buildable in the exact same way as the Bitcoin source tree.
This is a proven methodology that was in use when the source programs were in Fortran and the text processing language was Snobol.
Just cease to maintain them as forks in the github sense.
They need to be rewritten to Perl or other text-processing language.
The input to said Perl program should be the Bitcoin source tree and the list of the rather trivial changes that need to be made to various constants and identifiers in the Bitcoin source.
The output will be altcoin source tree buildable in the exact same way as the Bitcoin source tree.
This is a proven methodology that was in use when the source programs were in Fortran and the text processing language was Snobol.
When I tell people I work on Bitcoin full-time, a somewhat common reaction is "Really? I thought Bitcoin was finished, what do you work on?"
I spend half my development time working on new stuff (or testing new stuff that other people have submitted), but the other half I spend trying to anticipate problems or reacting to problems that are reported. That work tends to be unseen, partly because we want to keep problems quiet while we fix them and partly because quietly anticipating/fixing problems minimizes the 'lulz' that attackers might enjoy if every single-node-DoS attack caused us to run around like chickens with our heads cut off.
Anyway, good developers are hard to find, and one of the reasons I'm not thrilled by all of the AlternaCoins is because I'd rather a good developer help make Bitcoin better rather than spend their time with the busy-work of cross-porting the latest Bitcoin fixes to some other codebase. I would guess that some of the developers of the alternative chains underestimated the amount of work it takes to nurture them and keep them healthy. Maybe that will change when Bitcoin is truly mature and has dealt with another year or two or six of attacks and scaling issues...
I truly don't mean this to sound like a threat, but I think some of the blockchains that have been chugging along running on an ancient forked version of the Bitcoin codebase will be attacked; pretty soon we'll be fully disclosing the denial-of-service bugs that prompted the 0.6.2/0.6.3 releases, and it is highly likely somebody will decide to play with exploit code on a vulnerable chain.
I wish people would find more constructive things to do with their time, but I wish I could fly and never get old like Peter Pan, too.
I spend half my development time working on new stuff (or testing new stuff that other people have submitted), but the other half I spend trying to anticipate problems or reacting to problems that are reported. That work tends to be unseen, partly because we want to keep problems quiet while we fix them and partly because quietly anticipating/fixing problems minimizes the 'lulz' that attackers might enjoy if every single-node-DoS attack caused us to run around like chickens with our heads cut off.
Anyway, good developers are hard to find, and one of the reasons I'm not thrilled by all of the AlternaCoins is because I'd rather a good developer help make Bitcoin better rather than spend their time with the busy-work of cross-porting the latest Bitcoin fixes to some other codebase. I would guess that some of the developers of the alternative chains underestimated the amount of work it takes to nurture them and keep them healthy. Maybe that will change when Bitcoin is truly mature and has dealt with another year or two or six of attacks and scaling issues...
I truly don't mean this to sound like a threat, but I think some of the blockchains that have been chugging along running on an ancient forked version of the Bitcoin codebase will be attacked; pretty soon we'll be fully disclosing the denial-of-service bugs that prompted the 0.6.2/0.6.3 releases, and it is highly likely somebody will decide to play with exploit code on a vulnerable chain.
I wish people would find more constructive things to do with their time, but I wish I could fly and never get old like Peter Pan, too.
Jump to: