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).
Topic: Core Bitcoin Development Help Wanted (Read 9286 times)
Gavin, are you guys incentivizing participation in bug squashing with federal reserve notes? If so, where do I mail them?
Try sending bitcoins instead.
It's cheaper/easier for me to use USD right now until we get our operation going =)
Gavin, are you guys incentivizing participation in bug squashing with federal reserve notes? If so, where do I mail them?
Try sending bitcoins instead.
Gavin, are you guys incentivizing participation in bug squashing with federal reserve notes? If so, where do I mail them?
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.
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.
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.
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.
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.
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.
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.
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.
Quote
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?
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 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.
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.
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
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
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.
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.
Work on the build process exists at git://github.com/jgarzik/bitcoin.git branch 'autotools'
I would like to potentially get involved, but need to find a way to get started.
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 ?
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 ?
Jump to: