Boolberry Monthly Progress Report: March
Development progress continues to move quickly. In the last month alone, we’ve restored sources to a valid state, set up new checkpoints, set up new seed nodes, upgraded build scripts, and fixed compilations issues for different compilers. While, at the same time, building new binaries for all supported platforms.
Seed nodes
For far too long now, this project has been without seed nodes. Due to the huge memory requirements of the seed nodes the previously specified servers did not ensure the stable operation of the daemons. In order to connect to the network, you used to need to launch the wallet with specific command line parameters. To fix this, we’ve gone and bought a couple of powerful servers and brought them to the support nodes that were also updated in the source files.
The source code, which was dotted with artifacts of unfinished developments by third-party contributors, is now shown in a consistent form and we’ve added actual checkpoints for faster synchronization and reduction of the size of the blockchain. In the most recent build, we’ve improved the scripts and deployed the build environment to all platforms, now the new builds go into the network and synchronize seamlessly.
Secure wallet for services like exchanges
Since all current trends indicate the need for increased security, we’ve decided to adopt crypto best-practices and implement offline signatures. Basically, this allows you to have the same wallet in two forms. The first is a tracking wallet generated from the standard wallet which tracks your balance but holds no information for spending money (it only keeps tracking key, not the spending key). This tracking wallet only knows how to track the movement of funds and when generating an unsigned transaction template. The second is the original wallet, designed for maximum security and used only to sign the generated transaction dolts. With no synchronization, it is very secure and designed to keep you protected.
In order to use offline signatures, we need to generate so called tracking wallet, by giving a command to the CLI wallet:
[Boolberry wallet 1Exxxx]: save_watch_only C:\home\wallets\boolberry\some_tracking_wallet.bbr 12345
Keys stored to:
C:\home\wallets\boolberry\some_tracking_wallet.bbr
Second parameter is the path to save the keys file, and the last one is for the password. Now, when the CLI wallet opens this wallet it can’t actually spend money from it.
Boolberry wallet v0.3.0.45(f6de429-dirty)
Open wallet watch only: 1HNJjUsofq5LYLoXem119dd491yFAb5g4bCHkecV4sPqigmuxw57Ci9am71fEN4CRmA9jgnvo5PDNfaq8QnprWmS5uLqnbq
Starting refresh…
When you give the “transfer” command to this view-only wallet it actually generates a transaction template which is stored in the file. Then it needs to be signed by full wallet:
[Boolberry wallet 1HNJjU]: transfer 0 1HNJjUsofq5LYLoXem119dd491yFAb5g4bCHkecV4sPqigmuxw57Ci9am71fEN4CRmA9jgnvo5PDNfaq8QnprWmS5uLqnbq 10
Transaction prepared for signing and saved into “unsigned_boolberry_tx” file, use offline wallet top sign transfer and then use command “submit_transfer” on this wallet to transfer transaction into the network
As it follows from the above text, unsigned tx data is stored in file unsigned_boolberry_tx. This file will now send to place where the full (offline) wallet runs it and passes this command to it:
[Boolberry wallet 1HNJjU]: sign_transfer unsigned_boolberry_tx signed_tx
transaction signed and stored to file: signed_tx, transaction <acfaca14faccad3c022666487d7268dee55ca5b1e2c4440d130396d79f41706a>, 389 bytes
And, finally, file signed_tx has to be copied back to tracking wallet and submitted by it to the network, specified both generated files:
[Boolberry wallet 1HNJjU]: submit_transfer unsigned_boolberry_tx signed_tx
transaction submitted, <acfaca14faccad3c022666487d7268dee55ca5b1e2c4440d130396d79f41706a>, 389 bytes
Wallet commands, aliases, and funding
Moving on, we’ve added CLI Wallet commands and RPC API for signing/validating random text messages with address (alias) keys. This is going to be used for the funding platform and other community features.
We think that it would be awesome for Boolberry community if all can we vote and swap ideas in our funding platform. This will only be used by holders of our cryptocurrency and due to the need to protect against spam we’re moving over to using aliases. With that in mind, we’ve implemented a mechanism for signing arbitrary text with the keys of the wallet (with the key of a specific address being spent). The signed text verifies the alias ownership.
We understand that this may not be the most user-friendly way to handle this in the short term. However, we have a long view here and are looking to improve functionality over time.
Now (while the corresponding functionality is not implemented in the GUI) you will need to enter the command in the console wallet in order to sign any text:
[Boolberry wallet 1Exxxx]: sign_text sefsdfsdfsdf
Generated signature:
text: “sefsdfsdfsdf” (h = <97ac0a4c2a98d20e6457e4159efbb4f5a17e3e8e799d8fcc6cd2a7ddd7c26515>)
Signature: 13f1c06008b7a4f789c3a1cd2acda963b82d43575958010a44b0149394725f0f315bfc8186939fb8c30bbd05299050a6b739ffda9f0bdc115cdff9831745ea0d
The text in the signature field will be the signature, proving that this text was signed by the owner of this address.
The signature validation is performed through the corresponding daemon API, but it can also be done through the CLI wallet command (in any arbitrary wallet that is not completely associated with the signing address)
[Boolberry wallet 1Exxxx]: validate_text_signature sefsdfsdfsdf 1EYwtnWJ6KUVgimquuzYsCfvM5hd2DMVD5qF8vRyNGcG2zac8K3Cq7kYn8YnaN43DuB8jqAsb6woCZir953QVrf61RH6cf1 13f1c06008b7a4f789c3 a1cd2acda963b82d43575958010a44b0149394725f0f315bfc8186939fb8c30bbd05299050a6b739ffda9f0bdc115cdff9831745ea0d
Validation result:
OK
We’ll cover the funding platform idea in the next few posts.
Finally
One of the most important pain points experienced with Boolberry is the crazy consumption of RAM associated with the lack of database. We gladly began work on eliminating this problem.
First of all, we adopted an architecture in which the kernel level is separated from the specific implementation of the database by the “adapter” pattern. In this way, various database implementations can be connected to the kernel through the appropriate providers. Since the kernel initially worked with stl containers, the adapter must be similar to std::vector, std::list, and std::map in functionality.
We already integrated LMDB 0.9.21 to the build system and working on implementation of the basement of DB adapter (changes can be tracked in: https://github.com/cryptozoidberg/boolberry/commits/lmdb branch).
At the same time, we started to port core to new db paradigm in separate branch found here: https://github.com/cryptozoidberg/boolberry/commits/lmdb_core
It’s been one productive month. We look forward to giving you another update soon.
