This removes the transaction-signing code from the hub internal codebase.
The only user for this was the API call signrawtransaction,
and a lot of unit testing code.
I'd argue that if the user needs to send a private key to the hub via
RPC for signing his transaction, then they are doing it wrong.
This also removes the duplicate test double_spend which tests
functionality also tested in the DoubleSpendProofTest.
As an aside, the flowee/utils library still has full signing capability
and we suggest using the TransactionBuilder API for that.
Protobuf seems to have an incompatible cmake every single release,
which makes including it with cmake itself stupid and indeed lead
to linking or even compile errors.
So, the point of not wanting to use protobuffers directly got again
proven in practice as its a messy thing in all regards.
This makes the unit test for our reimplementation of protobuf
parsing/building become optional. The unit test is the only one
that actually uses the protocol buffers stuff itself, as such
turning that off by default isolates our users from the mess it is.
Protocol Buffers interaction is just another serialization standard,
while its widespread it has fortunately mostly been kept out of
anything relevant or important. Mostly due to the fact that is
really quite bad from a technical perspective.
This adds simple and basic support for creating and parsing
protocol buffer messages, mostly to allow interoperability.
If you want quality: use the MessagBuilder/MessageParser ones instead.
To enable this means the buildsystem will build all the applications
as well as the libraries.
Applications are 'hub' / 'txVulcano' / 'indexer' etc.
Default this one is turned off.
This introduces a Mnemonic class for BIP39 (seed words)
validation as well as a HDMasterKey class with provides the
BIP32 & BIP43 support.
All tests went into the apputils unit test.
The test starts to become long to run and using the one main.cpp
hack we had removes our ability to select one test to run, so lets
go back to one executable per class.
The block-box tests have long ago lost their usefullness
and have all been replaced by c++ ones.
The big-box testing was always frowned upon, but it kinda worked
for the original Core codebase which was practically speaking 100%
single-threaded.
Flowee the Hub breaks lots of questionable assumptions.
For instance the assumption that sending a transaction to a node
via the p2p layer and then immediately sending a request over RPC for
the mempool will find that tx there.
Flowee uses an async p2p layer, and therefore that old assumption no
longer holds.
Also, its python. Which is painful to read.
This C++ library is a small framework which creates a full
http(s) server.
This is imported code from the qhttpengine open source project.
I modified some core components in order to make this framework
multi-threading and changed some APIs for cleanlyness. As such
it is not source compatible and getting it accepted upstream is
not realistic.
As boost testlib is extremely IDE unfriendly, as well as human
unfriendly with lots of macros for basic C++ functions (like methods!!)
this is better for me.
But the real reason is that its just unstable. I get double deletes
on some releases of boost and I'm missing plain features that all
other test frameworks have.
For instance a QCOMPARE shows what is expected vs what we got. Boost
just fails.
In QTestLib I can mark a test as "expect fail" an idea that boost
tried and failed (can easily create false positives).
Duplicate the test_bitcoin file into the common dir,
I hope to remove the original in future.
Make the common dir a new static lib and create a new
qtestlib based unit test out of the old doublespend unit test.
The old was based on levelDB which has scalability issues and stability
issues. (most often cited problem is corrupted database..)
This unspent output database I wrote is based on the idea that we need
never actually update any rows, which makes most old fashioned databases
a bad fit.
All we do is create rows and we forget rows. So lets design a DB to fit
that pattern.
tomFlowee
TomZ