Yes, received it.
I will also look at these cpp files and the other blocks when I have more time.
The struct memory alignment problem is not a protocol problem but a parsing problem. Please don't spoil the project with protocol buffers (msgpack is leaner and nicer but still, you don't need it, just memcpy).
Just memcpy POD-wise with fixed-size data types into a temporary and copy from that instead of reinterpret_cast<>ing. Then it will be fine.
I don't know atm if you did that but don't cast or memcpy large objects because then alignment of member variables matters. Do it for every data type individually: memcpy uint64_t, uint32_t and such things and use use htonl and ntohl, single bytes can be read directly (obviously, because they don't require alignment). Floats are platform dependent and are problematic.
I would write serialization and parsing functions for your data types (or use msgpack if you don't want to do it by hand)
For example instead of
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.cpp#L48you would add a serialization function and a parsing function for
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/block.hpp#L11-L19by overloading a stream operator for serializing the member types and write a corresponding parser. You would have to write a cursor class that does bound checking and throws in case of bound violations. It is some work but it would play out nicely in the end. Or you just use messagepack (or protocol buffers if you really want to but I don't it). It depends on the number of objects you want to serialize and on the time you want to spend.
1. Unsafe reinterpret_cast conversion
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/api.cpp#L118 Maybe define another type which stores headers as byte sequence with getters? Then you can just initialize them with memcpy. These things need to be done ASAP.
2. No need for lambda callback
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L52 since this already happens in a separate thread, the value vector can be returned by the function instead of being a void function. Or better return failure and return the other values by modifying a reference but don't use a lambda.
3. Special attention has to be payed whether the total work computation is correct.
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L66 Do you have tests for this? This definitively needs some test and it needs to be wrapped into a function (which has to be tested) to be on the safe side. Instead of `totalWork+= base.pow((int)block.getDifficulty());` you need something like `totalWork.add(block.getDifficulty())` or `totalWork.add(block)`
4. Bad style:
https://github.com/mr-pandabear/bamboo/blob/1ac855ff08db053d5fe10803ec60f86f1227351d/src/core/header_chain.cpp#L76 Are there exceptions you don't know the type of? Don't do this to be on the safe side. If you know that your HTTP request only throw exceptions derived from std::exception then if there is another exception you do not expect, you should crash the program because it could be something strange that you would not find out about otherwise.
https://www.quora.com/What-does-crash-early-mean-in-software-engineering Never catch all. Actually you should not even catch std::exception but subclasses used in your HTTP client (if there are such, didn't check, otherwise it is a bad library).
Have no time now, will continue later.
