Wallet - Standalone (Safex Cash/Token Only (No Migration or Bitcoin))
The Safex Cash/Token wallet continued to undergo improvements based on feedback from internal testing which took place 10 days ago. So there was continuation of bug fixing on this wallet. We are focusing to make this an end all solution that is polished and won’t need updating for some time.
We also discussed making a limited beta test release with some community members to gather some more feedback beyond our team in Belgrade. Although a nice sized list of bugs have already been ironed out.
Additionally, Uros started linking up the transaction history feature from the backend. This is among the final features that went into production last week aside from the bugs discovered during more mass internal testing.
Note: this wallet is not the V8, it is a wallet exclusively for safex cash and tokens.
C++ backend for the Safex Wallet (Standalone version)
Stefan took time to expose and test the transaction history module that goes together with the Safex Wallet discussed above. It’s working on MacOS, Windows, and Linux successfully and now in production on the GUI of the wallet.
Safexd - Safex Node
On the Safexd side of things just some refactoring, documenting, and commenting code took place. As well as planning for extending the internal testing environment to better accommodate all of the modules we are now working on.
In the past week Pavle had furthered research and developed conclusive approaches to storing multiple keys in the badger DB that he implemented. This is in preparation for being able to host a wallet that has more than one master set of keys. It is usual for CryptoNote implementations to only have a single key or “account” whereas, we believe that there is an advantage to being able to wield multiple keys in the same the instance of the wallet GUI.
Documentation and description of the systems was also added to the gosafex repositories on Pavle’s specific branch.
Safex Marketplace: Proof of Concept Phase
Marketplace development took a
strong turn in the past week. Marko, our lead developer on the marketplace protocol had been developing the base layer on which all commands for the marketplace will be processed.
He is applying the classic
Command Design Pattern where the base command interface is defined in the abstract class and each particular command will inherit and specialize execution, serialization and other necessary functionality.
Essentially, this step provides the blockchain nodes a method of serialization and decoding of messages to be processed into the blockchain. And within the commands
could be anything from sell items, to lock tokens, make accounts, among other features we can develop and implement on this foundational layer.
Comments on Recent Monero hardfork v10
We have made an assessment of the recent Monero Hardfork updates that took effect on Saturday. In the recent Monero hardfork there have been updates to the hashing algorithm. Since there Monero community has made a mandate to alter their system every six months: we have considered it and may include it in a future fork of our system.
Other changes that took place include: modification of the Block Weight algorithm since the Monero blockchain faced some issues of congestion, which currently do not affect us. It is a drastic modification, although we have it documented as a potential improvement we can incorporate in the future.
There are various speedups included in the Monero fork that we have documented and could include. A notable element is the addition of SSL for the RPC client. This is great because no longer is it necessary to set up a Reverse Proxy to support encrypted communications with a Safexd Node.
All of these changes that we find supportive to software progress we plan to incorporate in our Marketplace Update Hardfork in the near future.
Catch you all next week
On behalf of the Safex Development Team