I'm in my final year of college and I remember being in your exact situation 2 years ago. In my view you can adopt 2 strategies at this stage.
You need to understand the protocol first, and reading Satoshi's orginal paper, or any of the easier options is essential. It also helps a lot to understand the conceptual differences between bitcoin and other ...
I have a different approach to it. You can use this too.
Bitcoin uses Doxygen comments to explain the code.
You can take the most recent copy of the code, build class hierarchy yourself using Doxygen, and then navigate through the various classes.
The next step would be to build it and run it in -regtest mode.
Use gdb to add breakpoints, and inspect the ...
FYI the code under discussion is available here on GitHub.
-> is a member access operator in C++, just as . is. They both expect the name of an object's member on the right (e.g. a member function or variable). The difference is that . expects an object on the left, whereas -> expects a pointer to an object which it first dereferences.
The Bitcoin-qt source code grew out of the original code written by Satochi. The latter, in my opinion, is much cleaner and easier to read. I have a new book that analyzes the Statochi's original source code at lulu.com: A Dissection of Bitcoin
You will find that non-standard transactions are very hard to get into the block chain. Instead, encode the additional information as accounts and send a single satoshi to each account needed to convey your message. That way, you can use standard transactions.
Transaction 28ccf29cfcc9f82d42793db770e7c7894d61ccf3d18299f34bda2e54415da287 is a particularly ...
It just contains an apparently random collection of functions used by the program. It also declares some global structures such as the main lock, the transaction pool, orphan block tracking, and so on. It contains high-level block and transaction functions. Ironically, it does not contain the actual main function -- that's in init.cpp.
Recently I was in a situation where I had to work on Bitcoin-core c++ code base. Being from c# background, I had the same problem which you faced. I also looked into the solutions which everyone is suggesting, still, I want to give you a more precise solution for this question:
You need to understand the basic of c++ project structure.
You can, but you shouldn't. Bitcoin transactions should only contain the information needed for the world to verify your transaction. Anything else is essentially private information between the sender and the receiver, and would be useless bloat to the block chain (making it more expensive to maintain for everyone).
That doesn't mean you can't have ...
I want to do program that doing some calculations with bitcoin values.
I know bitcoin have 8 digits after decimal point (please correct me).
There is no decimal in bitcoin at code level. There is no "bitcoin" unit either. There is only satoshi. And it is best to always stick to integer types instead of floating point types for calculations.
The ECDSA digital signature scheme returns two values. To be specific, the X and Y values computed on the elliptic curve are returned.
In Bitcoin the signture is DER encoded, which is represented as a string containing the X and Y values and also some header data. But both X and Y can easily be extracted from it when reading the string from left to right.
libbitcoin is not, and was never a part of Bitcoin Core. Both are standalone implementations of the Bitcoin protocol.
Bitcoin Core, in its build process, will create a number of files named "libbitcoin_...". These are just locally generated files that are unrelated to the libbitcoin project.
Bitcoin Core does not have any files with the "hpp" extension. So ...
Although it does not speak directly to programmers.
The Khan academy has got a great set of conceptual videos about bitcoin internals
Forum user and Armory client developer etotheipi put together a few nice images covering some aspects of the Bitcoin protocol, mostly related to transaction construction and verification; see this forum thread.
Other than that, though, most of the documentation is in code only. If you're comfortable with another language, you could try looking at BitcoinJ, ...
Bitcoin statically links in all of its dependencies by default, because many of them are consensus-critical and cannot accept a different version. Therefore, you can distribute the binaries that make creates.
However, I would recommend setting up gitian deterministic builds.
It's a custom format that encodes both a signature, and a parameter that allows the public key to be reconstructed from it.
Given a signature (an (r,s) pair), and the message it signs, there can be up to 4 different public keys for which it is valid. To know which one, the number is encoded along the signature.
The first byte is this recovery parameter ...
We can find all instances in the code where the client will send a block message by searching for PushMessage("block". This is the only match:
void static ProcessGetData(CNode* pfrom)
This means that the standard client only ever sends a block message when specifically asked for it. That ...
The chainActive variable stores the best known block chain. But this is essentially just the chain of block headers, not the actual blocks themselves. To load the actual block from disk, use the ReadBlockFromDisk() function. But, be aware that this is an expensive function to use, it does not return immediately.
chainActive or chainActive.Genesis() 
LOCK(cs_main) causes the thread to stop execution until a lock can be obtained on cs_main. cs_main is an object representing a type/class/scope of lock. Once the lock is obtained, it lasts until the end of the LOCK statement's scope. (The LOCK macro creates an object on the stack, the destruction of which releases the lock.)
cs_main is already locked in ...
Bitcoin Core has its own arith_uint256 class for calculations on 256-bit unsigned integers. Its code to convert "bits" (so-called compact format) to arith_uint256 can be found in arith_uint256::SetCompact in the file arith_uint256.cpp.
So you could always just use its code directly. This might be a good idea because if your version differs in any way ...
I just found out there is a github where the code is updated.
The specific code for addr.cpp is this.
Compilation works with --static e.g. g++ -o addr addr.cpp $(pkg-config --cflags --libs --static libbitcoin).
There is no "makefile" command.
If you don't build the project, there is no way for you to debug it. The released binaries do not contain any debugging symbols so it will be very difficult for you to set breakpoints and see what is going on. So in order to do that, you will need to build the project from the source code that you downloaded. There are ...
I created an Altcoin based on this article. https://firstname.lastname@example.org/how-to-fork-bitcoin-c39139506443
The article mentions 13 steps but I changed only the message prefix.
$ git branch
$ git diff
+ pchMessageStart = 0xf1;
+ pchMessageStart = 0xb2;
+ pchMessageStart = 0xb3;
The transactions are passed in as a vector. Bitcoin Core's serialization framework understands that all vectors should be serialized with a compact sized unsigned integer preceding the serialization of the data within the vector itself.
The code you are linking to is for simulating network-like effects of various mining technologies and policies. It does not actually mine, and will not teach you about mining itself.
You may look up projects like cgminer of bfgminer for actual mining software.
SPV wallets typically keep track of what the best known block for each of their peers is as well, to make sure they are up to date and can assess the security of their transactions (# of confirmations). The way they do this is to start a counter initialized at the height given in the version message. And then when the node broadcasts a new inv (inventory) ...