Bitcoin Forum
March 30, 2017, 08:36:35 PM *
News: Latest stable version of Bitcoin Core: 0.14.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Core Bitcoin Development Help Wanted  (Read 8718 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 01, 2011, 03:10:21 PM
 #21

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?

How often do you get the chance to work on a potentially world-changing project?
1490906195
Hero Member
*
Offline Offline

Posts: 1490906195

View Profile Personal Message (Offline)

Ignore
1490906195
Reply with quote  #2

1490906195
Report to moderator
1490906195
Hero Member
*
Offline Offline

Posts: 1490906195

View Profile Personal Message (Offline)

Ignore
1490906195
Reply with quote  #2

1490906195
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1490906195
Hero Member
*
Offline Offline

Posts: 1490906195

View Profile Personal Message (Offline)

Ignore
1490906195
Reply with quote  #2

1490906195
Report to moderator
Jim Hyslop
Member
**
Offline Offline

Activity: 98


View Profile
March 08, 2011, 04:09:42 AM
 #22

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


Like my answer? Did I help? Tips gratefully accepted here: 1H6wM8Xj8GNrhqWBrnDugd8Vf3nAfZgMnq
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
March 09, 2011, 09:18:11 PM
 #23

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
ScriptGadget
Jr. Member
*
Offline Offline

Activity: 49


Clever saying.


View Profile
March 09, 2011, 10:32:29 PM
 #24

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?  Smiley

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.

My Canary: I will never ask for a loan or offer escrow services. If someone does with this account, consider it compromised.
asmodehn
Newbie
*
Offline Offline

Activity: 1


View Profile
March 26, 2011, 06:47:47 PM
 #25

Hi everyone,

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

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

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
Full Member
***
Offline Offline

Activity: 182


View Profile
April 09, 2011, 03:16:20 PM
 #26

I would like to potentially get involved, but need to find a way to get started.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
April 09, 2011, 05:13:52 PM
 #27

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

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jpsoto
Newbie
*
Offline Offline

Activity: 10


View Profile
April 26, 2011, 07:05:39 PM
 #28

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
Newbie
*
Offline Offline

Activity: 5


View Profile
April 29, 2011, 12:03:38 AM
 #29

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
Member
**
Offline Offline

Activity: 70


View Profile
April 29, 2011, 12:29:06 AM
 #30

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 Smiley

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
Newbie
*
Offline Offline

Activity: 5


View Profile
May 02, 2011, 06:11:17 AM
 #31


Research how open source works Smiley

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
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
May 14, 2011, 07:29:58 AM
 #32

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?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 14, 2011, 03:46:38 PM
 #33

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
Newbie
*
Offline Offline

Activity: 14


View Profile
May 16, 2011, 08:37:21 PM
 #34

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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
May 22, 2011, 12:18:01 PM
 #35

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 22, 2011, 04:17:02 PM
 #36

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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
May 22, 2011, 05:53:32 PM
 #37

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 22, 2011, 06:32:14 PM
 #38

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 Smiley

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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
May 22, 2011, 06:44:55 PM
 #39

The Linux kernel does not accept patches to rearrange the kernel tree from new developers, either Smiley
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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Basiley
Jr. Member
*
Offline Offline

Activity: 42


View Profile
May 23, 2011, 10:14:58 AM
 #40

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.
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!