Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

v0.18.4RC1

Pre-release
Pre-release
Compare
Choose a tag to compare
@afalaleev afalaleev released this 10 Aug 07:51
· 200 commits to master since this release
v0.18.4RC1
f8a38d8
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Software release notes

GOLOS·CORE

The new SoftFork 0.18.4 version

Golos•Core has announced the new SoftFork version 0.18.0 has been released.
This page provides a brief outline of some fixes and improvements in this version. The updates are approved by a majority vote of witnesses.

Reindexing
SF 0.18.4 requires reindexing from all previous versions.

Additional information in the notifications about signed blocks

In previous versions of SoftFork, a user could subscribe to receive up-to-date information about new blocks created in the blockchain. The information contained in received notifications was not complete enough.
This problem is solved in the 0.18.4 version and now the user can get much more information about new blocks in the blockchain.

Getting information from notifications about virtual operations in signed block

Problem description:
To get the notification, a user had to call the set_block_applied_callback() method. The received notification contained only information about the signed block and did not contain information about virtual operations in this block.

Solution:
A new parameter type has been added to the set_block_applied_callback() method. Depending on the set value of this parameter, the user can get the following information about signed block:
— signed block;
— block header;
— virtual operations contained in the block;
— signed block and virtual operations contained in this block.

Now the user can get not only the most complete information about the signed block, but also set its content at his discretion.

Getting information from notifications about transactions on a node which have already been signed but not yet placed in a block

Problem description:
The blocks contain information about transactions that have already been signed and approved for their execution. If the transaction has been appeared on a node, but not yet approved for execution (not yet placed in a block), the block will not contain information about one. So, in previous version a user could not get information about such transactions by simple calling the set_block_applied_callback() method.

Solution:
New operation implemented in the version 0.18.4. This operation will send a message to the user about the new transactions on a node that have yet not been approved for execution. To subscribe to this type of notification, the user has to call the API method set_pending_transaction_callback().

Getting information about rewarding a person who signed a block

This is a new feature:
A new virtual operation is implemented in the blockchain. The operation notifies a user about rewarding (in GESTS) a person who signed a block. This is a producer of the block, which may be one of the following persons:
— a witness included in the approved list of witnesses;
— a witness, randomly chosen;
— a miner.

The virtual operation is stored in a block history and can be requested by the API method get_ops_in_block () to get the information about a block producer reward.

Improved diagnostic error information

Problem description:
Error messages did not contain enough information to understand a cause of their occurrence.

Solution:
All errors are divided into 12 categories. Based on these categories, a hierarchy of error classes is formed. These error classes contain an error's code that is passed to the user in the JSON API response. Specific errors within each category are also separated by an additional field. Specific message is generated for each field. Therefore, an error message contains more detailed information, including a description of the hierarchical structure level of a block where the error occurs. The messages can be easily analyzed by a user.

Added new operations for processing private messages

The new multifunctional plugin private_message_operations is created which provides additional abilities in processing private messages including the following ones:
— to send/receive messages to/from other users without using tokens;
— to get the history of messages by setting a user name or by using a filter;
— to get a list of users whom the messages were sent;
— to edit or delete messages which have already sent;
— and other ones.

Ability to set the configuration file variables to store only needed information on a node

Problem description:
The user is interested to store only the information on a node she/he needs, for example, account metadata, the memo in savings withdraws, the latest changes in posts and comments taking into account the depth of history, information about rewards. To do this, it does not need to create the node in full configuration, but only in the LOWMEM configuration. Therefore, the user had to rebuild the node in the LOWMEM configuration each time to save needed information.

Ability to set the configuration file variables to store account metadata

Solution:
Added new variables store-account-metadata and store-account-metadata-list into the configuration file config.ini. The user can set the values of these variables when it is necessary to enable or disable the storage of account metadata. The user can also set the list of accounts for which metadata will be stored. From now on the user has to rebuild the node only once after setting configuration file variables.

Ability to set the configuration file variable to store the memo field in savings withdraws

Solution:
Added new variable store-memo-in-savings-withdraws into the configuration file config.ini. The user can set a value of this variable when it is necessary to enable or disable the storage of the memo field in saving withdraws. From now on the user has to rebuild the node only once after setting configuration file variable.

Ability to set the configuration file variable to store changes in posts and comments taking into account the depth of history

Solution:
Added new variable store-comment-last-update into the configuration file config.ini. The user can set a value of this variable to store the most important information in the fields last_update and active. Later, the user can quickly access the stored information without searching it (for example, get the latest update information for specified post and for specified period only). From now on the user has to rebuild the node only once after setting configuration file variable.

Ability to set the configuration file variable to store information about rewards

Solution:
Added new variable store-comment-rewards into the configuration file config.ini. The user can either disable this variable to minimize memory usage on a node or enable it to store the information about rewards without rebuilding the node. From now on the user has to rebuild the node only once after setting configuration file variable.

Created new structure comment_reward_object for accumulating the rewards information with the following fields:
— total_payout_value (in GBG);
— author_rewards (in GOLOS);
— author_gbg_payout_value (partly in GBG);
— author_golos_payout_value (partly in GOLOS);
— author_gests_payout_value (partly in GESTS);
— beneficiary_payout_value (in GBG);
— beneficiary_gests_payout_value (in GESTS);
— curator_payout_value (in GBG);
— curator_gests_payout_value (in GESTS).

Ability to set the configuration file variables to store required body volume of the post and comments

Solution:
Added new variables comment-title-depth, comment-body-depth, comment-json-metadata-depth and set-content-storing-depth-null-after-update into the configuration file config.ini. The user can set the values of these variables to specify the desired (necessary) volume of a post content and comments to store them for a long time.
The 1-3 parameters specify the storage of the title, body and metadata in the JSON format of the post, respectively.
The lastest parameter is used to store a post content or comments after they were updated.
The user can deactivate either all of the components or just any of them to reduce memory usage. The user can also activate all of the components to store post content until there is a payment for the post.

Ability to set the configuration file variable to remove obsolete information from blocks

Problem description:
As soon as a post was closing, all the votes given for this post and stored in the blocks were to be removed (to clear a memory). This process was done as follows.
Removal all of votes was carried out to a certain block. The block was rigidly fixed and then all obsolete votes were removed from state system for that block. After removing votes for the block, new votes were again accumulated for this block and soon became unnecessary. So, obsolete votes were not completely removed.

Solution:
New variable clear-votes-older-n-blocks was implemented in configuration file config.ini. The variable value N is set by a user and can take one of the following values:
N=0 — which means removing the votes immediately after closing a post;
N>0 — which means keeping the votes before N block and removing the votes from blocks older than N;
N=-1 — which means removing the votes does not occur.

Note:
The new option was implemented at the request of witnesses.

Fixed old bug in cli_wallet application for the case, when an account had a multiple authorities

Bug description:
A transaction that was created by a multiple authorities account, could only be signed with the account keys from the account_authslist. When the main account was trying to use own key for signing the transaction, the application cli_wallet issued an error message.

Bug fix:
The method sign_transaction has been modified in the file wallet.cpp. This bug has been fixed and from now on the application cli_wallet works correctly.

Fixed bug in displaying the original blogger on the post feed

Bug description:
A user who subscribed to view posts of only certain blogger, could see other bloggers on the post feed.
This bug occured in the case when a blogger, for which the user had a subscription, reposted work of another blogger, for which the user had no subscription. As a result, the user could see another blogger on the post feed. The user was confused because of there was no any explain information on the post feed.

Bug fix:
This bug was fixed in the 0.18.4 version. In case when a blogger reposts someone's work, an additional message displays on the post feed like the following message: "reblogged_by: someone".

Ability to filter the history of user operations

Problem description:
The account_history contains information about a large number of operations, many of which are not directly related to the account (for example, votes for the account's post, repetitive operations that create a noise). To find the necessary operations it was necessary to create several requests to the server and discard unneeded operations on the client part.

Solution:
Added a parameter (including special values ALL/REAL/VIRTUAL) for the API-method get_account_history to choose operations are to be returned or excluded, and also to choose "direction of operation".
Added filtering operations which allowed the user to get needed operation type.
Added filter_account_history command to the cli_wallet application, which taked four parameters and called the get_account_history API-method inside.
Added the track-account option to configuration file, which allowed to specify one or more account.
The solution allows the user to obtain only needed operations (for examle, post-, transfer- or vote-operations only).

Assets 2
Loading