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.
Bitcoin Core is widely considered as the "reference implementation" and it is certainly the most widely used implementation on the network. Without a written specification, the authoritative resource, if ...
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.
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
It is extremely difficult to write a specification for a complex format that is 100% watertight and has no poorly defined corner cases. Further even if the specification itself is watertight it's extremely difficult to implement it without making any mistakes. I can't find a link right now but I remember a study posted recently about differences in ...
CAmount is used for multiple purposes in Bitcoin Core, not just in transaction validation logic. It is also used to represent the net effect transactions have on wallet balance, for example, and that net effect is negative as often as it is positive.
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 ...
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 ...
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 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).
It doesn't matter. The old version has a 64-bit nonce and 64-bit counter, while the new one replaces it with a 96-bit nonce and 32-bit counter. For our purposes however, they can reasonably both be thought of as a single 128-bit number that should just never repeat.
The ChaCha20 implementation in Bitcoin Core is used as basis for the random number generator, ...
The amounts returned by Bitcoin Core are accurate. They are not actually doubles; they're just output that way for convenience. Bitcoin Core internally uses a int64 and the amounts are satoshis. When outputting for users, the int64 is used and a string formatter just puts a decimal point in the appropriate place. Since it already is exact, you just need to ...
1) libsecp256k1 to calculate the public key from a private key
2) Hash the result with Sha2/256 + RipeMD160
3) Add version byte and 4-byte checksum
4) Encode it using Base58. My minimal code would work.
So, it's not really simple
I think what you want is to use this function:
bool CCoinsViewMemPool::GetCoin(const COutPoint &outpoint, Coin &coin) const
You can find the definition here: https://github.com/bitcoin/bitcoin/blob/v0.17.0.1/src/txmempool.cpp#L885
It will set the Coin object you pass as an argument. For an example of usage, see bool CheckSequenceLocks(const ...
Have a look at libbtc (https://github.com/libbtc/libbtc).
There is a function btc_script_classify() which will return what script type it is (P2PK, P2PKH, P2SH, P2WPKH, P2WSH) and it will return data elements (usually the RIPEMD160 of the pubkey).
I don't know much about c++ or libbitcoin, but I found a public method in the bc::wallet::ec_public class
bool to_uncompressed(ec_uncompressed& out) const;
So I guess you can probably convert your ec_public to ec_uncompressed(which is just a byte_array) by
std::cout << "...