Bitcoin Forum

The list of possible new features and bugs at https://github.com/bitcoin/bitcoin/issues is getting longer every day; I'd like to see the bugs resolved before the bug list gets so long we all just start ignoring it.

So:  who is willing and able to help out?  Don't ask permission, just jump in, grab a bug that catches your interest, add comments to it as you start to figure out what the problem is (or isn't), and submit a PULL request when you have a fix.

Your reward will be recognition, admiration and respect.  It is time to take bitcoin from, essentially, a single-programmer project to a robust open source project with lots of contributors.

Alas, if I knew C++  :-\

Might dl the sources so that I can work on smaller bugs though: I'm a LAMP guy but if there are little things I might be able to help. Then again, the issue list looks like gobbledegook to me, so I might not be that much help!

You might want to sticky this and make the title less generic though: it looks like the usual "how does it work" clarification type posts :)

Do like me, start with labels =)
https://github.com/bitcoin/bitcoin/pull/32

That's really all I feel comfortable with (well actually not, I was wondering whether I should update locale files...)

Improving help is definitely helping-- thanks!

And it would be fantastic to get somebody who knows, or is willing to learn, git to step up and volunteer to submit translation file patches.

I'll soon be asking for building and testing help, too (after fixing another couple of bugs, I think it'll be time to pull non-controversial patches into the integration tree and start some serious testing to prepare for another release).

Damn, this is a project I'd really love to get involved with if I wasn't under so many persistent pressures... Lots of exciting areas to muck around in.

Various bugs fixed on branches listed at https://code.launchpad.net/~luke-jr
I'd be glad to redo them in Git if someone cares to mirror/move the Git-side of things to free software (such as Gitorious), rather than GitHub (which is anti-free software).

meh

Just post your to-be-pulled branches on the sanctified git server of your choice.

??? Can you post some more details ?

EDIT:
Never mind, found it out myself:

I know git, and have time on my hands (as evidenced by the number of typo corrections I've made recently in the wiki...).  I'd be willing to submit translation file patches if it doesn't require me being able to speak languages other than English...  Let me know what you need.


I only have Ubuntu on the computers here, but have various versions (10.04, 10.10, 11.04 pre-release) so can build and test on those.

In the mean time I'll take a look at the bug list and see if there's anything I can work on.  I have a fair bit of C++ experience, but am quite new to Bitcoin.

Two suggestions:

1. Not to touch anything and make "a week of refactoring".

I personally do not quite understand the code which is in one giant file main.cpp. I twice tried to start watch it but fell asleep in the middle. Git does not like this arrangement of the code too.

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 am concerned about errors that prevent realize listtransatstions ( https://www.bitcoin.org/smf/index.php?topic=2306.0  ). From a distance at least one bug look quite dangerous: https://github.com/bitcoin/bitcoin/issues/#issue/28

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.


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


The listaccounts bug is nearly fixed.  I cannot reproduce the dangerous-looking bug, even running bitcoind under the valgrind memory-checking tool (valgrind actually simulates machine instructions to catch memory access errors)-- tcatm seems to be the only person having the issue.

I've created a Gitorious project at http://gitorious.org/bitcoin/bitcoin (via git, git://gitorious.org/bitcoin/bitcoin.git )

Currently, its master branch mirrors the GitHub one, but with a few bugfixes I added.

I also have a "neutral" branch which has a (backward-compatible) RPC API upgrade to version 1 (the older being 0) which removes (in principle, but not code) the deprecated methods, and uses base units rather than floating-point decimal BitCoin values (this makes it neutral between decimal and tonal, makes it faster for devices without a FPU, and fixes possible accuracy problems due to unexpected floating-point approximations). Constructive design, API. and code review is welcome and appreciated.

Others are welcome to use Gitorious rather than GitHub for development as well; contact me if you need to be added to the Gitorious project (or if some senior developers want to take over the Gitorious project, I'm sure there's a way to transfer control of it, too).

This (http://gitorious.org/bitcoin/bitcoin/commit/c16b9402673cf7376c81cad4fe00fc2099e790a8 (http://gitorious.org/bitcoin/bitcoin/commit/c16b9402673cf7376c81cad4fe00fc2099e790a8)) doesn't look like a bug fix:


It looks like removing a feature that was deliberately added.

You should open a thread on the forum to discuss whether being able to make sub-cent payments using the RPC interface is something most people want.

Chris.

I'd love to have sub-cents payments both in the RPC and in the GUI. 

I added version tags (0.3.20 and 0.3.21 for now) to some issues and will try to keep them up to date so we'll always know what's blocking a release.

hi,

i can't find that tags, is possible can you tell me which commit is 0.3.20 and 0.3.21 ?

greeting's.

I'm working my way up to a home compiled version, but got confused.
Win and Unix uses db 4.7 but Mac uses db 4.8
Is this intended? As long as I don't trie to copy between the platforms it would work, but I was puzzeled.

Nice work!

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

Yeah.I was trying my best to say it out

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

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

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 (http://bitcointalk.org/index.php?topic=4277.msg62107#msg62107). I'll read-up.

Hi everyone,

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

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  :P )

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 ?

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

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

I am a (moderately active) member of Drupal community.
http://drupal.org (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/ (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.

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

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

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?

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.

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.

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.

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.

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.

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.

Gavin, are you guys incentivizing participation in bug squashing with federal reserve notes? If so, where do I mail them?

Try sending bitcoins instead. ;D

It's cheaper/easier for me to use USD right now until we get our operation going =)

Hey Gavin, You suggest we 'just jump in an take a bug', but some of the 'issues' conflict and require vision.

Take the wallet. I personally think it must be plaintext, which would solve all of the split/merge requests, simplify backup, etc. Each address/key pair could be individually encrypted in a radix64 block if that is desired. Others of course seem to strongly disagree (seems to conflict with generic key store importation, performance, and other 'issues').

Maybe someone (you?) needs to mark issues as ready-to-go, while others deserve to be thought-through. Otherwise, some hacker might jump in and plaintext the wallet and divide the datadir by public (block chain), private (wallet, addr), and clutter (logs).