Nurturing AlternaCoins

[Gavin Andresen]

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.

[1715480525]

1715480525

[1715480525]

1715480525

[1715480525]

1715480525

[2112]

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.

[Etlase2]

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.

[doublec]

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

[2112]

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

[smoothie]

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.

[maaku]

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.

[the joint]

Gavin, I think you need a coffee and bagel intern.

[galambo]

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

2112, I'm not entirely sure if you've looked at the code for GetNextWorkRequired. You keep describing it as doing integration when from what I can tell its entirely proportional. Are you making assumptions looking at the graphs on this website? http://bitcoin.sipa.be/

Here is a condensed version of the code with my comments:

//pindexLast points to the last block generated. pindexFirst points the block generated 2015 blocks ago.

if ((pindexLast->nHeight+1) % nInterval != 0)  //nInterval is 2016
return pindexLast->nBits;

//some code to get pindexFirst and limit the gain of the proportional controller to a threshold.

int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();

bnNew.SetCompact(pindexLast->nBits);
bnNew *= nActualTimespan;
bnNew /= nTargetTimespan;  // target is 1209600 (two weeks)

The reason this is safe is that the Bitcoin protocol enforces a rough causality for every block accepted onto the network.

My reason for posting this is I'd like to get your opinion on how safe the implementation is.

As far as the graphs on sipa's website, only the difficulty actually exists. The estimates are calculated in this way.

<sipa> galambo: i use an exponentially decaying average over time (which can be considered an IIR) to calculate averages of block-finding-speed (weighted by difficulty) and average age of recent blocks, and feed those to a maximum likelyhood estimator that estimates average and growth rate for an assumed poisson-like process with exponentially changing rate
<sipa> assuming the actual hash rate is a function of the form A*exp(B*t), it will give a very accurate estimation of A and B
<sipa> but the hashrate that results from this calculation is effectively an extrapolation (it uses data from the past to guess the current speed)
<sipa> which makes it inappriopriate as a difficulty function

[galambo]

Gavin--

What is this post about?

Did somebody say something stupid to you?

We appreciate all the work that you do on Bitcoin.

What is version .0.6.3? The latest version available to the public is .0.6.2.

Thanks.

[bulanula]

Don't know why but I see this as a warning to coblee and LTC abou Luke coming to attack the chain

Hope it does NOT happen because that is NOT cool and anti competitive BS just like the government and status quo like ...

[2112]

2112, I'm not entirely sure if you've looked at the code for GetNextWorkRequired. You keep describing it as doing integration when from what I can tell its entirely proportional.

Same difference. There is a 2016-way decimator (or subsampler) at the output of the I or PI controller.

The decimator is there to assure that the blockchain converges after an emergence of orphans right after the difficulty retarget. Without the decimator the blockchain would either completely split or took much longer time to converge to a majority.

The I vs PI argument is somewhat hair splitting because if it is PI then the proportions are about 1/2016 P and 2015/2016 I. Additionally there is at least one off-by-one bug in the computation of the feedback value so the equations aren't optimal but about 1/2016 away from the optimal.

Incidentally (or by design) integrator is also an approximation of an average. And average happens to be maximum likelihood (or maybe minimum variance or some such) estimator for the lambda parameter in the exponential distribution governing the block-winning lottery.

I have a feeling that Satoshi had a very peculiar sense of humor, intentionally setting a traps for people who kinda but not really understand what's going on. Very similar to the choice of stochastic knapsack solver for the wallet coin selector. I now always imagine him cackling at the discussions here from a safe distance.

[smoothie]

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.

Hey Gavin, how about PM coblee and DoubleC about these exploits so they can begin work on the alt chains if they so choose to?

Why the secrecy?

[galambo]

Gavin, perhaps you should consider the good things about alternative chains--

1) Keeping other block chains in mind promotes writing "good", bottom-up code where everything is properly encapsulated, and easily extendable by the alternate chain authors. Obsession with "good" code can be taken too far, but programming with alternative chains in mind would actually help you improve the official client.

2) Additionally, the kinds of changes many have suggested to improve the official client's alternative currency support would improve Bitcoin itself. For instance, etothejpi's tree of unspent outputs is a type of alternative chain. Additionally, namecoin is another alternative chain that has some practical value to Bitcoin users.

3) As others have pointed out in this thread -- Alternative currencies help to highlight bad design decisions and why Bitcoin, at the moment, is superior. You can learn from others mistakes.

4) Alternative chains are absolutely necessary for the long term success of Bitcoin. Remember what proof of work was before Bitcoin? It was used as a type of digital notary stamp to prevent spam e-mails.  Proof of work is a digital token that says "I invested some amount of time and computational effort in solving this problem." The primary future use of Bitcoin will likely be supplemental to the actual crypto-currencies most people use. Bitcoin's role in a future economy will be much like the role of the Bureau of Engraving and Printing in the early history of the U.S. Dollar when employees of the U.S. Treasury would sign the individual bills produced by private companies for the Treasury. The role of the signature was to "monetize" the paper, much like the role of the Bitcoin will be to "monetize" alternative currencies.

[Gavin Andresen]

Rereading my original post, I should make clear: the people I really have issues with are the people who think it is more fun to try to destroy something than to help build it.  My comment about "I wish people would find more constructive things to do with their time" was not meant to be aimed not at AlternaCoin creators.

I agree that there are some benefits to the alternate chains existing; I just wonder if the costs of all the duplicate infrastructure (exchanges and pools and faucets and...) is worth the benefits.

RE: privately disclosing exploits to AlternaCoin developers: well, to be frank, I have no idea if most AlternaCoin developers can be trusted with sensitive exploit information or even who is currently supporting which chain. The danger would be somebody emailing me claiming to be the lead developer for FooCoin, I tell them about the vulnerability, and then they turn out to NOT be the lead FooCoin developer but an attacker.  Or I tell FooCoin about the vulnerability and they decide to use it to launch an attack on their arch-enemy, BarCoin.

It is all drama and heartburn that I'd really rather not have (again, costs and benefits....)

[smoothie]

Rereading my original post, I should make clear: the people I really have issues with are the people who think it is more fun to try to destroy something than to help build it.  My comment about "I wish people would find more constructive things to do with their time" was not meant to be aimed not at AlternaCoin creators.

I agree that there are some benefits to the alternate chains existing; I just wonder if the costs of all the duplicate infrastructure (exchanges and pools and faucets and...) is worth the benefits.

RE: privately disclosing exploits to AlternaCoin developers: well, to be frank, I have no idea if most AlternaCoin developers can be trusted with sensitive exploit information or even who is currently supporting which chain. The danger would be somebody emailing me claiming to be the lead developer for FooCoin, I tell them about the vulnerability, and then they turn out to NOT be the lead FooCoin developer but an attacker.  Or I tell FooCoin about the vulnerability and they decide to use it to launch an attack on their arch-enemy, BarCoin.

It is all drama and heartburn that I'd really rather not have (again, costs and benefits....)

Gavin, that's why you send it to people who are trusted in the community.

For all we know you could be a terrorist with all the exploits right? So what's the difference? You made an impression on the forum...so can others. You're not special bro...

[maaku]

Gavin, I misinterpreted your original posting and I apologize for the passive aggressive hostility. You do good work; keep it up.

[steelhouse]

There are probably about 7 running and 2 probably have dropped out this year (geistgeld and liquidcoin?).  Due to the numbers none have them gained any traction, the numbers weaken them.  If there were only 1 or 2 like namecoin and microcash, they would be a lot more powerful.  The secret is out cryptocurrencies work.  People are going to try to get in on the ground floor and start new coins.  It seems you are offering request for help in the main coin, bitcoin.  Maybe you can ask them directly for help.

[ffe]

+1

[smoothie]

There are probably about 7 running and 2 probably have dropped out this year (geistgeld and liquidcoin?).  Due to the numbers none have them gained any traction, the numbers weaken them.  If there were only 1 or 2 like namecoin and microcash, they would be a lot more powerful.  The secret is out cryptocurrencies work.  People are going to try to get in on the ground floor and start new coins.  It seems you are offering request for help in the main coin, bitcoin.  Maybe you can ask them directly for help.

that doesnt exist lol