Core Bitcoin Development Help Wanted

[Gavin Andresen]

Why not keep an up-to-date TODO list of small tasks for new developers to get mucked into? A launchpad.

Good Idea.  You should do that.  Maybe marking issues at github with a "Launchpad" tag would be a good system?

[Jim Hyslop]

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with.  The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?").  Just rearranging the code that is there now won't make that problem any better.

No, but splitting main.cpp into smaller files will make compiles much faster when you make a tiny change to a single function. As would eliminating headers.h; it's been my experience that "#include everything you might possibly need and then some" leads to code that is far too tightly coupled, which makes the code even harder to understand.

Just my two cents worth, based on 20 years of C++ programming :-D

[Steve]

Having spent a lot of time working with the existing code, I don't think splitting the code into multiple files would make it much easier to work with.  The hard part is figuring out how everything fits together (for example "if I have a CWalletTx, how do I get the CBlock that it is in (if any)?").  Just rearranging the code that is there now won't make that problem any better.

No, but splitting main.cpp into smaller files will make compiles much faster when you make a tiny change to a single function. As would eliminating headers.h; it's been my experience that "#include everything you might possibly need and then some" leads to code that is far too tightly coupled, which makes the code even harder to understand.

Just my two cents worth, based on 20 years of C++ programming :-D

I have to agree.  It's not so much the fact that the current code is in one gigantic file...it's that the the code being in one gigantic tends to encourage sloppy practices (not to say one can't write nicely factored code in one gigantic file).  Also, if you're ever going to get serious about unit tests, you'll need well factored code to facilitate testing all the various bits (and writing unit tests tends to force the issue of good factoring).

[ScriptGadget]

I have to agree.  It's not so much the fact that the current code is in one gigantic file...it's that the the code being in one gigantic tends to encourage sloppy practices (not to say one can't write nicely factored code in one gigantic file).  Also, if you're ever going to get serious about unit tests, you'll need well factored code to facilitate testing all the various bits (and writing unit tests tends to force the issue of good factoring).

Did someone says unit test? 

I haven't looked at the code yet, but I was looking for a bitcoin related project. I have a couple of launches this week (home project and a work project), but starting Monday I can pull down the code and take a look at adding some trivial unit tests to get things started. Does anyone have a serious problem with me using cppunit?

Update: Just spotted the Unit Test thread. I'll read-up.

[asmodehn]

Hi everyone,

I'm new here and new to bitcoin, but it looks like a pretty interesting project.

The main blocker for me to start to chip-in in at the moment, is the organisation of the code...
Building bitcoin more complex than it should, and building on other systems ( BSD and so on) is even trickier.

My personal opinion if that the project ( technically speaking ) needs some structure.
source code in one folder, configuration and build framework is a start ( even before unit testing hehe  )

Now the project is only using basic makefiles, without any configuration to detect dependencies and setting up options.
I'm willing to help here ( although I don't have much free time now ) and setup some multiplatform build process, as I am used to work on multi-platform C++ projects, and I can test on ubuntu and NetBSD.

Is someone already working on that ? has a decision be made about it ?
And is this here the right place to talk about that kind of topic ?

[tomcollins]

I would like to potentially get involved, but need to find a way to get started.

[jgarzik]

Work on the build process exists at git://github.com/jgarzik/bitcoin.git branch 'autotools'

[jpsoto]

I am a (moderately active) member of Drupal community.
http://drupal.org
Drupal community could be a good reference for Bitcoin community to evolve to an open software community with many contributors and a robust issue system.

Drupal's automatic test framework is a very very notable resource to be known. Please take a look
http://qa.drupal.org/
*Every* patch pulled to the git server is run against an increasing and huge amount of tests. Indeed, no bug patch is accepted if it does not include tests to reproduce and solve the bug.

[junomoneta]

Is there any formalization for the BTC core code development process? In particular, how is QC being addressed? Independent code review before each release?

My concern is that as BTC gathers steam and begins it become a target for central banks, regulators and other entrenched interests in the global economy some will almost certainly seek to subvert it by technical or human means. For example, back-doors or weaknesses that can be only exploited by those who paid for its installation. Its not beneath the intelligence arms of these governments to threaten to kill a developer's wife and kids and show him videos of other people they have done it to, etc.

The most important aspect to BTC is its potential for network effects. To achieve this it needs to establish and maintain trust. The more often an effective competitor to national fiat money is crushed the less likely the next will be successful. Therefore, its important that the BTC opportunity not be squandered by subversion from a government or their minions.

JM

[xf2_org]

Is there any formalization for the BTC core code development process? In particular, how is QC being addressed? Independent code review before each release?

My concern is that as BTC gathers steam and begins it become a target for central banks, regulators and other entrenched interests in the global economy some will almost certainly seek to subvert it by technical or human means. For example, back-doors or weaknesses that can be only exploited by those who paid for its installation. Its not beneath the intelligence arms of these governments to threaten to kill a developer's wife and kids and show him videos of other people they have done it to, etc.

Research how open source works

Each git commit has its own unique sha1 id, that builds upon the previous commit (also identified by sha1 id), much like bitcoin's block chain itself.

It will be obvious if anybody hacks github.com and adds unwanted source code changes.

[junomoneta]

Research how open source works

Each git commit has its own unique sha1 id, that builds upon the previous commit (also identified by sha1 id), much like bitcoin's block chain itself.

It will be obvious if anybody hacks github.com and adds unwanted source code changes.

I know how OS works. I also know how it possible to make very subtle changes to crypto code (For example, compromising a random number generator before a whitening stage to hide the result. This is how Racal Milgo, Crypto AG and Cylink compromised their commercial encryptors under orders of NSA in the mid-1990s). My concern is not a hacker making unwarranted or hidden changes but one of the 'trusted' BTC developers.

JM

[ripper234]

2. We're all bitcoin millionaires and billionaires (except of me, probably). Maybe it's time to hire 1-2 employees? Or establish a reward for bugs busters?

I don't think anybody who has worked on the code, except for Satoshi, has a lot of bitcoins.  I certainly don't.  I hope to earn some with Clearcoin....

Is this still true given the May price jumps? Without knowing how much you have or revealing how much I have, I would wager you have more than me even though I'm quite happy with my share.

Anyway, if you or anyone else in the development team would be motivated to work for a few bitcoins, I (and members of the forum) could always donate a few. I pledge 10 BTC to developing the core client (especially automatic backup & encryption, much needed features!)

Can we get more people in? And an address to donate to?

[xf2_org]

I know how OS works. I also know how it possible to make very subtle changes to crypto code (For example, compromising a random number generator before a whitening stage to hide the result. This is how Racal Milgo, Crypto AG and Cylink compromised their commercial encryptors under orders of NSA in the mid-1990s). My concern is not a hacker making unwarranted or hidden changes but one of the 'trusted' BTC developers.

Every change is hashed with a sha1 hash, building upon the last sha1-signed change.  It's easy to see whatever a dev makes a change, whether it's a hacker or a "trusted" BTC developer.  This is not a large concern.

[niklas_a]

Just adding my two (bitcoin) cents here. I'm interested in getting involved but a single Main.cpp file put me off. Maybe you are right in that a single cpp is the best, but it does come with a learning curve, at least for me.

[wumpus]

Just adding my two (bitcoin) cents here. I'm interested in getting involved but a single Main.cpp file put me off. Maybe you are right in that a single cpp is the best, but it does come with a learning curve, at least for me.

It's certainly not the desirable state.

Splitting up the headers and sources into sensible parts would be a good learning project for getting into the code, me thinks.

Also grouping configuration etc into data structures instead of lonely globals like now.

[xf2_org]

Splitting up the headers and sources into sensible parts would be a good learning project for getting into the code, me thinks.

Not really.  If you aren't already working with the code, it's unlikely you'll come up with a good split, instead just generating git noise.

[wumpus]

Not really.  If you aren't already working with the code, it's unlikely you'll come up with a good split, instead just generating git noise.

Don't be so elitist. People not yet in the project might have good ideas, and in the least it might start interesting discussions.

The Linux kernel also has 'kernel janitor' projects for this purpose.

Another example is that there are a crapload of compiler warnings when compiling with default gcc settings, someone needs to investigate them.

[xf2_org]

Not really.  If you aren't already working with the code, it's unlikely you'll come up with a good split, instead just generating git noise.

Don't be so elitist. People not yet in the project might have good ideas, and in the least it might start interesting discussions.

The Linux kernel also has 'kernel janitor' projects for this purpose.

The Linux kernel does not accept patches to rearrange the kernel tree from new developers, either

If such changes are not informed by experience of existing developers, then you break everyone's diffs for very little value.  Such "easy" changes do have costs.

[wumpus]

The Linux kernel does not accept patches to rearrange the kernel tree from new developers, either

I wasn't talking about completely rearranging the tree either. You're taking it way over the top. Changes can be small but still improve a lot. I think you agree that the current state is not optimal either?

So now we even have a few people that are implementing their own clients because they think the main client is a total unreadable mess. Of course, those will never finish, because it's much more work than they bargained for. Which means that lot of developer effort is wasted.

Apparently the project is in need of help (otherwise this topic didn't exist), so I'd think making it more accessible to new developers should be one of the priorities.

[Basiley]

yeah, there alot of derrivatives/forks from "Vanilla"(kernels from kernel.org) - from real-time-related things to SELinux-hardened and weird-arch-ported[sometimes its require insane alterations]. for example, many remember ans some can still use kernel with alternative shedulers or build with next-gen toolchain.