v0.22.0RC1

GOLOS·CORE

The new HardFork 0.22.0 version

Golos·Core team announced the release of the HardFork 0.22.0 version, in which new functionalities are presented and failures of previous versions are fixed. Updates approved by majority votes of witnesses. The release will happen on 2019.08.15.

The changes for HardFork 0.22.0 version are uploaded to a separate branch. Golos blockchain volunteers can take advantage of the provided changes and independently implement them in the Golos blockchain. The changes include new features for the Golos blockchain, as well as solutions that eliminate failures found in previous versions.

---

The changes for the HardFork 0.22.0 version

• New great functionality — «workers», which includes the following procedures:
  • submitting a proposal (an idea);
  • implementation of the proposal;
  • report on the work done by the worker for evaluation it by witnesses;
  • evaluating the work done by the worker;
  • payment of rewards to the SOW author and to the worker for the work done;
  • determination of commission payments to be credited to the workers' fund;
  • protection of the workers fund from the lack of funds to pay for the work performed;
  • termination of payment if the work was accepted hastily;
  • involvement of interested users to raise funds for the implementation of proposals;
  • saving memory resources on witnesses’ nodes;
  • termination of work on the initiative of witnesses;
  • resumption of work on the initiative of the SOW author;
  • simplified procedure for reviewing proposals (ideas) already implemented at the time of their submission;
  • assigning a worker on the initiative of the SOW author.
• Wider range of deductions from delegation operations.
• The ability for delegates to set curatorial fees in a wide range.
• Fixed the bug prevented users from adding comments.
• Delegation of funds in two ways: with payments to the user's balance or to the balance of vesting.
• Involving users to support newbies.
• The new voting procedure for witnesses.

The new «Workers» functionality. Solutions implemented within the «Workers» functionality

The functionality «Workers» allows a user to directly participate in the development of the Golos blockchain technology. The user is provided with the following features:

• the user can submit a proposal for the implementation of a certain idea to increase the blockchain capabilities.
• the user can make a statement of work (hereinafter - SOW) for the implementation of the submitted proposal (this may also be a third-party proposal).
• the user can implement the proposal himself.

Golos witnesses evaluate the user's activities and the user is rewarded according to the result of these activities.

Submitting a proposal (idea) №1017

Solution: A post is created by user. The user marks this post as a proposal for the implementation of ideas in Golos. The user selects the type of the sentence - “task” (a brief idea that has not been executed yet outlined by verbal description) and “premade_work” (already including a specific implementation plan). The submitted proposal should be available for consideration by other users who discuss this proposal in the comments to his post, and evaluate it by voting for / against the post.

The implementation of the proposal №1019

Solution: The user creates a post with a Statement of Work (hereinafter: SOW) in which he describes the steps for implementation of the proposal. The user marks this post as SOW, indicating in it the amount of the payment to himself for the SOW compiled and to the performer (worker) for performing the work on this SOW.
Witnesses vote for SOW, and in case it becomes accepted, funds are allocated from the reward pool for work. The allocated funds are in a «frozen» state, which serves as a kind of guarantee of payment to the worker for his work.
The SOW author can choose a specific worker himself before starting to work on the specific SOW. If the SOW author does not specify the concrete worker, he may be charged by other user. If case the SOW author rejects the assigned worker, SOW post get closed automatically.

Publication of a report on the work done by the worker for witnesses’ evaluation №1022

Solusion: Upon completion of the work in accordance with the SOW, it’s author publishes a post (with a report mark) on the results of the work done. The result is evaluated by independent witnesses’ voting.

Evaluating the work done by the worker; №1023

Solution: Witnesses vote on the result of the work done on specific SOW. In case of acceptance of the work (outlined by the majority of upvotes) both the SOW author and the worker are rewarded. In case of failure to accept work (outlined by the majority of downvotes), the SOW is closed automatically.

Payment of rewards to the SOW author and to the worker for the work done №1024

Solution: Payments to authors and workers are carried out either at a time, or to separate parts in accordance with specific time intervals individually specified by the SOW author when filling the SOW data in.

Determination of commission payments to be credited to the workers' fund №1061

Solution: When voting, witnesses set the amount of deduction (in percent) from each of funds (posting reward fund, Vesting fund, witness’ fund) to the worker fund. The resulting percentage is determined by the median, like the other settings in chain_properties. There are no restrictions (limits) implied.

Protection of the workers fund from the lack of funds to pay for the work performed №1073

Solution: When witnesses’ voting for the SOW proposed takes place, the commission is forecasting whether there will be enough funds to pay for the work. In case of prediction of fund shortage, the SOW is not accepted.
When witnesses vote for SOW, the amount of reward for the work will be taken into account when forecasting the fund and adopting the other SOW.

Termination of payment if the work was accepted hastily №1105

Solution: In case the witnesses commission had mistakenly voted to accept the result of the work given in the report, and later realized that the decision was incorrect or simply premature, the payments already made will be cancelled.

Involvement of interested users to raise funds for the implementation of proposals №1107

Solution: In case a proposal is getting enough user attention, but lacks the worker pool fund for its realization, any user can contribute to this fund from his own balance sheet.

Saving memory resources on witnesses' nodes

№1126, №1169
Solution: The witness can enable or disable the automatic deletion of outdated information (for example, such information as voting results or payments for already closed SOW).

Termination of work on the initiative of witnesses №1258

Solution: Witnesses can vote to stop work if there are no results for this work.
The funds allocated for this work will be unlocked and allocated for other SOW when forecasting funds for them.

Resumption of work on the initiative of the SOW author

№1254
Solution: When being confident in achieving a positive result of the work, the SOW author can notify witnesses about this by labeling the «Work In Progress» status of the work in until it’s closed.
Such status does not restrict witnesses from further voting to discard the working process кegarding this SOW . However, setting this status notifies all the witnesses who will vote later.

Simplified procedure for reviewing proposals (ideas) already implemented at the time of their submission

№1270**
Solution: The author of the proposal creates a post with the «premade_work» mark. Only he is empowered to publish a SOW related to it which also serves as the result. After a SOW gets checking by witnesses, it is sent out for proceeding with rewards.

Assigning a worker on the initiative of the SOW author

№1281**
Solution: The author of the SOW may represent the worker to the witnesses even before accepting the work by them (for proposal with the «premade_work» type, the appointment of a worker is mandatory).

Miscellaneous

Wider range of deductions from delegation operations

№1008
Solution: The limit (maximum 80 %) on the restriction of interest for witnesses, which is delegated to the vesting, is excluded. Now the witnesses can set the boundaries of the percentage of fees for delegated vesting in the range from 0 to 100 %

The ability for delegates to set curatorial fees in a wide range

№1009
Solution: Exclusion of the limit (25 %) on the optional witnesses’ limiting of curatorial deductions. Now witnesses can set the boundaries of curatorial deductions in the range from 0 to 100 %.

Fixed the bug prevented users from adding comments №1010

...

v0.21.0

GOLOS·CORE

The new HardFork 0.21.0 version

Golos·Core team announced the release of the HardFork 0.21.0 version which contain only one operation — the voting witnesses procedure. Taking into account the results of the referendum of Golos tokenholders the witnesses have to vote for migration of Golos chain to the new environment — to the Golos application of the CyberWay blockchain. The release will happen on 2019.08.15.

The voting witnesses procedure

After updating the Golos software, the transaction will be created containing the voting witnesses procedure to transit the Golos chain.

If the number of witnesses who have agreed to make the transit is at least 16 (out of the first 19 in the list of witnesses), the consensus will be achieved on transition. As soon as consent is received from the 16th delegate (consensus building), the voting will be completed. In the current Golos chain will be recorded the fact of the consent of the witnesses to the transit.

After that, Golos blockchain will stop accepting transactions from users. That is, posts and comments publication, funds transferring and everything else will be stopped. In addition, the emission of tokens, distribution of payments, exchange of tokens will be stopped too.

The shutdown procedure will be started on the nodes of the witnesses who agreed to the transit. Before stopping the system, a snapshot (a dump) of the Golos system state will be taken on these nodes for transfer all the data to CyberWay.

Based on the dump data, the necessary calculations of tokens for further distribution will be carried out - Cyber and Golos (including the additional issue of Cyber tokens). In addition, the users will get the appropriate account names.

CyberWay will be launched from the main node with the dump data from current Golos chain. After the launch of the main node, the witnesses nodes, who voted for the transit, will join the network. CyberWay chain will be considered operational after the launch of the nodes of seven witnesses.

Each witness of the current Golos blockchain who votes for the transit and launches the node in the new CyberWay environment, automatically will get the status of a validator of CyberWay.

Deploying the Golos application

The Golos application is a part of the CyberWay genesis and therefore it is deployed automatically. No additional steps are needed to deploy the Golos application on the CyberWay blockchain.

Golos Power tokens belonging to the Golos account are fully delegated to the Golos application to ensure its operability.

v0.20.0

GOLOS·CORE

The new HardFork 0.20.0 version

Golos·Core announces the release of the next HardFork 0.20.0 version, which eliminated a bug in the programm code that caused Golos blockchain to stop functioning on the night of January 18, 2019.

Note:
Despite the fact that the HF 0.20.0 version does not require a reindex from all previous versions, it is recommended to perform the procedure replay of blockchain nodes with HF 19.0 version.

On the night of January 18, 2019, the Golos blockchain system had crashed. Golos Core team with support of the blockchain delegates managed to quickly identify and eliminate the cause of the system failure, as well as restore the blockchain’s operation. Below are the changes that were promptly implemented in blockchain program code of the HardFork 0.20.0 version.

---

Fixed program code for calculating the percentage of delegate deductions when voting for a post (the issue №1074)

Creditors for whom the calculating a percentage of curatorial rewards has been completed with overfow, will receive a remuneration in full despite the fact that the payment will be credited to balances of the curators. This decision was agreed with the affected curators and creditors.

Creditors for whom the calculating a percentage of curatorial rewards has been completed successfully will receive a remuneration in accordance with the calculated percentage

Banned of changing the percentage of payment from curator fees after voting starts (the issue №1075)

An author of post can repeatedly change the percentage of payment from curator fees. The author of the post will not be permitted to change this percentage as soon as a curator votes for the post.

The Golos Core team thanks the witnesses who took part in troubleshooting the Golos system, as well as those who promptly updated system on the nodes to recover the blockchain.

---

v0.19.1

GOLOS·CORE

The new SoftFork 0.19.1 version

***Golos·Core announces the release of the next SoftFork 0.19.1 version, which eliminated the shortcomings identified in the blockchain after releasing HF 19.0. ***

---

Identified and corrected deficiencies

Fixed bug in the results of calling API functions of family get_discussion_by_* (the issue #1005)

In the results obtained when calling API functions of the family get_discussions_by_ *, fields of predicted payments contained null values, for example:

“pending_author_payout_value”: “0.000 GBG”,
“pending_author_payout_gbg_value”: “0.000 GBG”,
…
“pending_payout_value”: “0.000 GBG”,
“total_pending_payout_value”: “0.000 GBG”,

The values of predicted payments on website golos.io also displayed null.

In SF 0.19.1, the plugins social_network, tags and follow were modified to fix the logic for calculating the predicted payments. This implementation has provided a correct display of field values of the get_discussions_by_ * functions.

Added the «reputation» field to result of calling API functions of the family get_discussion_by_* (the issue #1006)

The reputation field author_reputation was missing in results of the API functions of the get_discussion_by_ * family, due to which information about authors was incomplete.

In SF 0.19.1, changes were implemented in the api-library to ensure correct result.

Fixed an error that occurred when deleting obsolete data (the issue #1007)

When performing an operation in the social_network plugin to remove obsolete data, an error occurred, which broke down the replay process of chain with issuing messages like this one:

th_0  social_network.cpp:522 on_block
926859ms th_0 database.cpp:1325 notify_applied_block ] Caught exception in plugin: 1020200 missing_object: Missing object
Missing comment with id "25"
    {"type":"comment","id":25}
    th_0  database.cpp:660 get_comment
    {}

The cause of the error was an attempt to access an object that had already been deleted. This disrupted synchronization of a node with network. The bug is fixed in SF 0.19.1.

Improved control of transaction serialization result (the issue #823)

Sometimes the user needs to verify that a transaction is correctly serialized into a binary data stream (for example, when a node does not accept user-signed transactions) to get a hash amount..

The existing way to validate the serialization of a transaction is based on calling database_api :: get_transaction_hex. Disadvantage of this method is that the get_transaction_hex function also adds the signatures field to overall serialization result, which makes it difficult to verify the result. To verify correctness of the transaction hash amount and obtain transaction signature from it, a user needs to add the chain_id byte array to the result.

In SF 0.19.1, at the request of users, the transaction signature has been removed from result of the database_apt::get_transaction_hex function for serializing the transaction. It was decided not to add chain_id to the binary serialization result, as this value is already present in the response of database_api::get_config function.In addition, the API method database_api :: get_transaction_digest has additionally been implemented to extend functionality, whose result can be used to generate transaction signature on a client side.

---

v0.19.0

GOLOS·CORE

The new HardFork 19.0 version

Golos·Core announced the release of the next HardFork version 19.0, which introduces new functionality, as well as the shortcomings of previous versions. Updates approved by majority vote of witnesses.

Reindexing:
HF 19.0 requires reindexing from all previous versions.

---

Referral program implementation in the Golos blockchain (the issue #295)

Feature description
Witnesses proposed to implement a new functionality in HF-19.0 — to introduce a referral program to attract new users.

Solution
The referral program implementation provides for remuneration of users (referrers) who invited their friends or third parties through social networks to register on the blockchain (by viewing third-party publications or placing their own posts about the blockchain).

To implement the referral program in HF-19.0 the following operations were introduced:

• Creating a referral account for the invited user. Both a user who directly invited another user or a third-party account can be specified as a referrer for the referral account.
• Termination of the referral program by a referral through a redemption of her/his account. The operation allows a referral to redeem her/his account to stop paying a referrer.
• Obtaining an information about a referral.
• Obtaining an information about a referral by her/his comment or post.

Example to create a referral account name using cli_wallet:

create_account_referral test "0.200 GOLOS" "0.000001 GESTS" <referral account name> "{}" {"referrer": "test", "interest_rate": 900, "end_date": "2018-09-26T14:00:00", "break_fee": "0.000 GOLOS"} true

Here are:
referral — a referral account name;
referrer — a referral name;
interest_rate — referrer payout percentage of referral income multiplied by 100. Maximum payout percentage to the referrer is set by witnesses voting via the operation update_chain_properties(). Payments to the referrer are made through appointment of the referrer as a beneficiary in published posts;
end_date — end date of payments to referrer from referral income. Maximum payment period for a referrer is set by witnesses voting via the operation update_chain_properties();
break_fee — an amount of redemption by a referral of her/his account to stop payments to referrer. If the payment amount is 0, then an account cannot be redeemed. Maximum payout amount is selected by witnesses via the update_chain_properties() operation by median value.

2. Example of operation to stop paying a referrer:

break_free_referral <referral account name> true

3. To obtain an information about a referral via cli_wallet, the get_account command is used.
   To highlight the referral account in system, the following fields have been added to a response of the golos.api.getAccounts() API method:

    "referrer_account": "test",
    "referrer_interest_rate": 900,
    "referral_end_date": "2018-09-26T14:00:00",
    "referral_break_fee": "0.002 GOLOS"

During the referral program time for a referral account, field values correspond to fields from account_referral_options. After termination of the referral program, the fields take zero values.

4. To obtain an information about a referral by her/his comment or post, an object with the parameters account=<referrer name> and weight=<referrer_interest_rate> is added to the beneficiaries field. Payment to the referer is carried out taking into account these parameters.

Changing the method of calculating remuneration to curators (the issue #898)

Problem description

Voting for a post begins as soon as it is published. Amount of remuneration to curators for voting depends on the time of voting. In order to make voting via using robot programs ineffective, a time interval of 30 minutes is introduced. This is an auction window which is opened immediately as soon as the post is completed. The weight of vote given in the auction window was calculated by the formula

W = t / (30 × 60) × weight  

Here are:
t — voting time since window opening (in seconds);
(30 × 60) — window duration (in seconds);
weight — account weight.

In accordance with this formula, the resulting weight W decreases in proportion to early voting — earlier vote cast during the open window, gains less weight. In this case the missing (cut off) part of tokens is charged to author of the post. Therefore, voting during the open window is more beneficial to authors of posts.

Solution

It became possible to change the duration of the auction window by witnesses voting through the operation update_chain_properties().

In the HF-19.0 version (at witnesses suggestion) the algorithm for more flexible accrual of remuneration to curators has been improved, including:

• the auction window duration is to be a voted parameter and will be set by witnesses voting via the operation update_chain_properties();
• missing (cut off) part of tokens should be returned either to reward pool or to the curators who voted after closing the auction window.

Decision about where to direct the cut part of tokens, is made by a user.

For this purpose the following option comment_auction_window_reward_destination has been implemented in method comment_options_operation. The option accepts the following values:

• to_reward_fund — return tokens to rewards pool;
• to_curators — return tokens to curators who voted after closing the auction window;
• to_author — return tokens to autor (used for posts that were created before HF-19.0 release to provide backward compatibility).

Possibility for witnesses to adjust the time intervals reserved for posting, for leaving comments and voting (the issues #533, #1002)

Problem description

Now the time intervals allowed for posting, for leaving comments to the post and voting are 5 min, 20 and 3 seconds, respectively. Such tightly spaced intervals cause inconvenience to users. For example, in a time of 20 s, up to ten or more comments may appear, and witnesses have to spend too much time to answer them.

Feature solution
In the HF-19.0 version it is possible to change the length of the intervals (also known as windows) specifically reserved for posting, for leaving comments and for voting, as well as the ability to change the permissible maximum of publications, comments and votes left during these intervals. The parameters posts_window, posts_per_window, comments_window, comments_per_window, votes_window, votes_per_window are added to the operation update_chain_properties, which is configured with the blockchain. Having these parameters, witness can specify the duration of the intervals during which posting, leaving comments and voting are allowed, as well as the number of publications, comments and votes allowed during those intervals. The values of these parameters are determined by witnesses voting through the update_chain_properties() operation, the results of which are considered as median values.

In the HF-19.0 version the commenting window duration and the allowed number of comments left within this window are 200 s and 10 pcs respectively. The voting window duration and the permissible number of votes to be left within this window are 15 s and 5 pcs respectively.

In addition, in this very version, an algorithm that operates on limiting the excessive activity of users in posting, commenting and voting has been improved. The algorithm allows to perform various actions in a row without waiting for the completion of the 20-second interval until the start of the next action in a more flexible way. The algorithm implemented is based on the «battery» principle. The minimum frequency of actions taken is determined by the following formula:

V = window / items

Here are:
window — is the length of the interval allocated for a type of actions;
items — the number of publications, comments or votes left within the interval.

The median value is selected by sorting out the values specified by witnesses by two values: the minimum frequency of actions and the length of the window in which these actions can be performed.

The user can posting, leave comments or participate in voting depending on the availability of resources (charge) in his/her particular «battery». The algorithm records the time of appearance of the post and the contents of the charge of the «battery», consumed with leaving each comment to the post or vote.

Deduction of a piece of funds from the curator payment to accrual this piece to the Golos Power lender (the issue #756)

Problem description

The number of people willing to delegate the Golos Power tend to be small. Partly, due to the fact that the GP lender (GP investor) does not receive any deductions from curator fees and therefore does not receive a fee at all.

Feature solution
Version HF-19.0 includes the ability to regulate the percentage of deductions to the GP lender. The curator receiving the GP delegated (according to the results of the voting for the post) deducts a portion of the curatorial payments to the lender.
The algorithm of investors’ GP accrual is implemented in accordance with the following features:

1. Payment of remuneration to lenders with payments to curators (who receive the delegated VP by lenders) occurs simultaneously. The lender is charged a certain percentage of the payment to the curator. The amount of deduction to the lender is determined by the following formula:

lender’s remuneration = (curator’s remuneration) × (lender’s share in curator’s GP) × (percentage of lender’s contributions)
Here is:
lender's share in the curator’s GP = (number of delegated GP) / (total curator’s GP)

2. The percentage o...

v0.18.6

GOLOS·CORE

The new version SoftFork 0.18.6

Golos·Core announced the SoftFork 0.18.6 version release which eliminated previously existing defects in the system.

Reindexing:
SF 0.18.6 requires reindexing from all previous versions except version SF 0.18.4 and SF 0.18.5.

Bug description
In the previous version softfork-0.18.4, the order of arguments in the broadcast_transaction_with_callback method was changed. The argument at the first position was removed as unused. Because this method was used by third-party libraries, the absence of this argument caused problems. Failure was caused by requirement to check node softfork version to find what arguments should be used to call that method.

In the previous version softfork-0.18.5 the bug was incorrectly fixed.

Solution:
The removed argument has been returned back to the method broadcast_transaction_with_callback at its previous first position. The argument order and functioning of the libraries have been restored in this release. Additionally, one of checks in the method has been fixed too.

v0.18.5

GOLOS·CORE

The new version SoftFork 0.18.5

Golos·Core announced the SoftFork 0.18.5 version release which eliminated previously existing defects in the system.

Reindexing:
SF 0.18.5 requires reindexing from all previous versions except version SF 0.18.4.

Defects fixed in this release

Defect (Task№)	Abstract
943	Problem of creating a list of operations for operation_history plugin
936	The get_ops_in_block method, unlike the get_block method, did not provide information about virtual operations in block
948	Removed the first argument in the method broadcast_transaction_with_callback did not allow this method to be used in third-party libraries

Problem of creating a list of operations for operation_history plugin

Bug description
Some plugins, including operation_history, had difficulty setting options (keys).

For example, executing a command of the form “./golosd --=123” for keys history-blocks, history-start-block failed with the error message:
“Error parsing command line: option --history-blocks is ambiguous and matches different versions of --history-blocks”.

The error occurred when trying to run this command also with some other keys available in program_options.

Solution
The add_option method has been improved. Each of the plugins contains two objects program_options, this is either cli (command line options) or cfg (config file options). To declare a parameter, it has to be added to the cfg object with a required value.

The error cause was an additional declaration of parameters in cli, which caused duplicates in general list of parameters. The solution was based on removing the parameter declaration from the cli object.

The change is made to the following plugins:

• account_history;
• debug_node;
• follow;
• market_history;
• operation_history;
• statsd;
• witness.

The get_ops_in_block method, unlike the get_block method, did not provide information about virtual operations in block

Bug description:

The get_ops_in_block method did not provide information about virtual operations in a block in the return value.

Solution:

It was decided to generate the return value of the get_ops_in_block method similar to the return value of the get_block method. These two methods become identical in structure in this release. The operation_history plugin has been supplemented with the get_block_with_virtual_ops method.

Removed the first argument in the method broadcast_transaction_with_callback did not allow this method to be used in third-party libraries

Bug description
In the previous version of softfork-0.18.4, the order of arguments in the broadcast_transaction_with_callback method was changed. The argument at the first position was removed as unused. Because this method was used by third-party libraries, the absence of this argument caused problems. Failure was caused by requirement to check node softfork version to find what arguments should be used to call that method.

Solution:
The removed argument has been returned back to the method broadcast_transaction_with_callback at its previous first position. The argument order and functioning of the libraries have been restored in this release. Additionally, one of checks in the method has been fixed too.

Note:
More information about the changes can be found here:
https://wiki.golos.io/golosd/SoftFork/SF-0.18.5-Release_Notice.html

v0.18.4

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
  • Getting information from notifications about virtual operations in signed block
  • Getting information from notifications about transactions on a node which have already been signed but not yet placed in a block
  • Getting information about rewarding a person who signed a block
• Improved diagnostic error information
• Added new operations for processing private messages
• Improved functionality with reblogged post
  • Ability to comment on a reblog
  • Ability to delete reblogged post
• Ability to set the configuration file variables to store only needed information on a node
  • Ability to set the configuration file variables to store account metadata
  • Ability to set the configuration file variables to store the memo field in savings withdraws
  • Ability to set the configuration file variable to store changes in posts and comments taking into account the depth of history
  • Ability to set the configuration file variable to store information about rewards
  • Ability to set the configuration file variables to store required body volume of the post and comments
  • Ability to set the configuration file variable to remove obsolete information from blocks
  • Ability to tune the configuration file to specify required number of processed tags on API node
• Fixed old bug in cli_wallet application for the case, when an account had a multiple authorities
• Fixed bug in displaying the original blogger on the post feed
• Ability to filter the history of user operations

---

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.

Improved functionality with reblogged post

Problem description:
Golos provides a user with too little functionality for operations with reblogged post.

Ability to comment on a reblog

Problem description:
A user is not able to add a comment to reblogged post.

Solution:
Added additional fields to the operation that allow the user to add a comment to reblogged post.

Ability to delete reblogged post

Problem description:
A user is not given any option to delete a reblogged post.

Solution:
Added the new operation that allows a user to delete reblogged post information.

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 s...

v0.18.4RC1

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
  • Getting information from notifications about virtual operations in signed block
  • Getting information from notifications about transactions on a node which have already been signed but not yet placed in a block
  • Getting information about rewarding a person who signed a block
• Improved diagnostic error information
• Added new operations for processing private messages
• Ability to set the configuration file variables to store only needed information on a node
  • Ability to set the configuration file variables to store account metadata
  • Ability to set the configuration file variables to store the memo field in savings withdraws
  • Ability to set the configuration file variable to store changes in posts and comments taking into account the depth of history
  • Ability to set the configuration file variable to store information about rewards
  • Ability to set the configuration file variables to store required body volume of the post and comments
  • Ability to set the configuration file variable to remove obsolete information from blocks
• Fixed old bug in cli_wallet application for the case, when an account had a multiple authorities
• Fixed bug in displaying the original blogger on the post feed
• Ability to filter the history of user operations

---

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 comme...

v0.18.3

Software release notice

Golos•Core releases new SoftFork version 0.18.3.
This page provides a brief outline of some fixes and improvements in this version.

Reindexing

0.18.3 should not require reindexing when upgrading from 0.18.0, 0.18.1 and 0.18.2

Overview

This is an improvement of release v0.18.2 with consensus bug fix, which were imported from the Steem 0.19.5

Bug Fixes

A field with vesting shares in withdraw_vesting_operation was not properly checked. Now, it is checked on a pushing of transaction. And if an invalid operation was made irreversible then all negative effects are fixed on the vesting withdraw processing.