v0.18.2

Software release notice

All nodes need to upgrade to 0.18.2

Reindexing

0.18.2 should not require reindexing when upgrading from 0.18.0 and 0.18.1

Overview

This is a consensus bug fix release, imported from the Steem 0.19.5

Bug Fixes

A field in withdraw_vesting_operation was not properly checked. This invalid op could halt the blockchain when the vesting withdraw was processed well after the op was made irreversible. Included ops are now no-ops to prevent the halt and new ops have the proper check to prevent this behavior in the future.

v0.18.1

Software release notice

Golos•Core is planning to release new SoftFork version 0.18.1.
This page provides a brief outline of some fixes and improvements in this version.

---

Added ability to interrupt a replay-procedure at any time

Bug description:
In case a replay-procedure was interrupted, then the restart of that procedure was performed from very beginning. It was no matter at what time the interrupt occurred. Because of the replay-procedure was taking too long, this was an inconvenience to users.

Solution:
It was decided to keep a system state immediately before interrupting the process. This allows users to rerun the process right from the point it was stopped.

Added flag for preventing automatic replay-procedure call

Problem description:
Sometimes users accidentally run wrong version of golosd that resulted in automatic restart of a replaying procedure and corruption of shared_memory.bin file. Moreover, there was no any way to repair the corrupted file.

Solution:
New flag replay_if_corrupted = false has been implemented in configuration file that prevents automatic replay-procedure call. The flag is set to “true” by default.

Improved way of setting dates in cli_wallet for proposed transactions

Problem description:
When were creating proposed transactions, it was necessary to specify the dates in full format. This was not always convenient.

Solution:
At now it is enough to specify an offset in seconds and then cli_wallet application itself will calculate the date relative to current time.
For example, a command line for specifying offsets will look as follows:

propose_builder_transaction 0 alice test "memo" "+3600" "+1800" true

Fixed bug in get_open_orders method of cli_wallet application

Bug description:
The get_open_orders method call was terminated every time with an error message, no matter when this interruption happened.

Solution:
This bug has been fixed in the get_open_orders method. At now the method returns correct result.

Fixed bug due to which the get_discussions_by_XXX methods returned incorrect results

Bug description:
Each method of the get_discussions_by_XXX family from tags plug-in always returned an empty result when an old post was specified by using start_author and start_permlink parameters.

Solution:
The bug has been fixed in the tags plug-in. At now all of get_discussions_by_XXX methods return correct results.

Renamed environment variables which are passed to the script golosd.sh

Problem description:
Some environment variables had kept their old names with STEEMD prefix, and and as a consequence of that, confused users.

Solution:
The environment variables which are passed to the script golosd.sh and having names starting with STEEMD prefix, were renamed in accordance with this table.

Old variable name	New variable name	Meaning
STEEMD_SEED_NODES	GOLOSD_SEED_NODES	Setting seed nodes file
STEEMD_WITNESS_NAME	GOLOSD_WITNESS_NAME	Setting witness account name
STEEMD_MINER_NAME	GOLOSD_MINER_NAME	Setting miner account name
STEEMD_PRIVATE_KEY	GOLOSD_PRIVATE_KEY	Setting witness private key
STEEMD_RPC_ENDPOINT	GOLOSD_HTTP_RPC_ENDPOINT	Setting RPC endpoint for HTTP
--	GOLOSD_WS_RPC_ENDPOINT	Setting RPC endpoint for WebSocket
STEEMD_P2P_ENDPOINT	GOLOSD_P2P_ENDPOINT	Setting p2p endpoint

Variable STEEMD_RPC_ENDPOINT has been splitted into two differ variables named as GOLOSD_HTTP_RPC_ENDPOINT and GOLOSD_WS_RPC_ENDPOINT.
The variable GOLOSD_HTTP_RPC_ENDPOINT uses for setting RPC endpoint for HTTP communication.
The variable GOLOSD_WS_RPC_ENDPOINT uses for setting RPC endpoint for WebSocket communication.

Created script for managing golosd

Problem description:
There was not possible to influence the daemon restart process in a docker container, that created inconvenience to users.

Solution:
Additional script has been created for managing the daemon restart process. In particular, it allows users to run replay procedure of a chain in a docker container. For example, a command line to run a replay looks as follows:

docker exec golos-default /usr/local/bin/golosdctl replay

Fixed bug due to which the get_content method returned garbage in result

Bug description:
The get_content method returned garbage in some fields of result in case either a post or comment were absent in database. Got result confused users.

Solution:
The bug has been fixed in the social_network plug-in. At now all fields in returned result contain zero values in case requested post or comment are absent in database.

Modified list_keys method of cli_wallet application for returning key type information

Problem description:
The list_keys method always returned a list of public-private key pairs without type and owner key information. Lack of such information created inconvenience to users.

Solution:
The list_keys method of cli_wallet application has been modified. Additional fields which contain information about type key and owner name key, have been added to return result of this method.

---

v0.18.0

GOLOS·CORE Equality HF·18 Release Notes

This page contains general information about a new BlockChain version from Golos·Core,
based on new realised features and named as HF·18. Golos·Core recommends all witnesses,
seed nodes and anyone else who uses the witness plug-in have to update to HF·18.

Release date is schedule for 20 June 2018 12:00:00 MSK

Reindexing

HF·18 requires reindexing from all previous versions, except v0.18.0RC3

Updating from previous version

See build instruction

New HardFork operations and opportunities

• 1. VESTS delegation
  • 1.1. Delegation operation
  • 1.2. Update delegation operation
  • 1.3. Delete delegation operation
  • 1.4. Account create with delegation operation
• 2. Preventing various abuse kinds of the VESTS delegation operation
• 3. Modified method for determining the cryptocurrencies ratio
• 4. Ability for users to edit their profile by using the posting key
• 5. Proposed transaction
  • 5.1. Create proposed transaction operation
  • 5.2. Update proposed transaction operation
  • 5.3. Delete proposed transaction operation
• 6. Ability for users to update their posts and comments regardless of when they were published
• 7. Expansion operation of the parameters list which values are set by delegates voting
• 8. Increasing system performance due to placing frequently and rarely used database fields in different objects
• 9. Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively
  • 9.1. Removed unused fields from some methods
  • 9.2. Index operations for blocks and accounts are placed in separate plug-ins
• 10. Using tags to create requests for obtaining the necessary information
• 11. Getting shared memory status
• 12. Ability to paginate private messages and send them out to the user's screen
• 13. Improving storage subsystem of chain blocks

---

1. VESTS Delegation

1.1. Delegation operation

This operation is used to delegate for a time a part of VESTS to another account as if that account owned this VESTS and could dispose it. The delegated VESTS can be back to lender after a time. The active key is required to perform this action.

1.2. Update delegation operation

This operation is used to update the VESTS amount. The active key is required to perform this action.

1.3. Delete delegation operation

This operation is used when the lender changes her/his decision and wants to withdraw back the delegated VEST. As soon as the operation starts the VEST will immediately be withdrawn in full and be back to lender after a time. The active key is required to perform this action.

1.4. Account create with delegation operation

This operation is used to create a new account while this time the creator can also delegate a part of her/his VESTS to the new account. The creator has to use the active key and pay the creation fee are required to perform this action.

2. Preventing various abuse kinds of the VEST delegation operation

This feature has been implemented in order to prevent various fraud operations (or abuses) related with transfering delegated VESTS from account to account, as well as cashing VESTS into Golos.

3. Modified method for determining the cryptocurrencies ratio

This feature has been implemented in order to provide more accurate pricing policy for Golos and GBG on the stock exchange. The meaning is while determining the cryptocurrencies ratio, only actual values are used in database.

4. Ability for users to edit their profile by using the posting key

This feature allows a user to edit the profile fields by using the posting key.

5. Proposed transaction

5.1. Create proposed transaction operation

This operation allows a user to propose a transaction on the blockchain which consists of multiple operations and requires approval of multiple accounts in order to execute. Each operation from the transaction requires an approve of the author whom the operation is intended. The active key is required to perform this action.

5.2. Update proposed transaction operation

This operation allows the author, as well as other participant of the transaction, to change their own decisions and update the signatures before the expiration time. The key type which is required to perform this action, depends on an operation in the proposed transaction.

5.3. Delete proposed transaction operation

This operation is used to stop performing the proposed transaction if it takes no sense in continuation. The proposed transaction may be deleted by either author or any participant. The active key is required to perform this action.

6. Ability for users to update their posts or comments regardless of when they were published

This feature allows the users to update their posts or comments regardless of when they were published and keep their in up to date.

7. Expansion operation of the parameters list which values are set by delegates voting

This operation is used to support a more extensive parameters list which values are determined by Golos delegates voting. The active key is required to perform this action.

8. Increasing system performance due to placing frequently and rarely used database fields in separate objects

The meaning of this fix is to place frequently and rarely used fields into separate objects. This provides loading into shared memory only the object with frequently used fields, not all of fields. It takes much less time for processing the blocks and allows to increase system performance, while voting.

9. Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively

9.1. Removed unused fields from some methods

The fix allowed to move the methods between plugins in order to release some unused fields from the methods and then delete them. This allowed also to reduce the load on used memory.

9.2. Index operations for blocks and accounts are placed in separate plug-ins

This fix allows the user to form a request for obtaining information about operations of the transactions (or blocks) without receiving unnecessary history of accounts. This allows also to decrease the server and memory loads and increase system performance.

10. Using tags to create requests for obtaining the necessary information

Methods that process tags as well as methods that provide access to root elements are placed in separate plug-ins. This reallocation allows the user to pull out just a needed part of the content while searching.

11. Getting shared memory status

This fix allows a user to form a request to the blockchain for getting memory status.

12. Ability to paginate private messages and send them out to user's screen

This feature allows a user to pull out her/his private messages from whole list of outgoing (or incoming) messages and paginate them while viewing.

13. Improving storage subsystem of chain blocks

This fix provides simultaneous access to read data from the file where is located a chain of packaged in a certain order signed blocks. Blocking access to the file is possible during the write operation only.

---

Release Candidate 0.18.0rc3

GOLOS•CORE

Expected release date is schedule for 20 June 2018 12:00:00 MSK

On this page:
HF•18: New calculate delegation parameters method in the release candidate RC3

---

The multipliers are no longer required

The method of defining the parameters which was implemented in the release candidate RC2, confused delegates. Therefore, modified RC3 release candidate for HF18 has been presented where the opinions of candidates has been taken into account.

Changes implemented in RC3:
In RC2 there were the multipliers to calculate delegation parameters. These are:

account_creation_fee  
create_account_with_golos_modifier  
create_account_delegation_ratio  
min_delegation_multiplier  

This method based on multipliers implementation allowed to make the system to be flexible, but a bit confusing. Therefore, it was decided to simplify the method of calculating the parameters. Absolute values are now used instead. These are:

account_creation_fee  
create_account_min_golos_fee  
create_account_min_delegation  
min_delegation  

To create an account without delegation just one parameter account_creation_fee is needed.
To create an account with delegation there are 2 new parameters that replace multipliers. The first one is create_account_min_golos_fee using to calculate a minimal fee value to be payed in GOLOS when is creating an account with delegation.
The second one is create_account_min_delegation using to calculate a minimal GP delegation amount when is creating an account with delegation. This value can be reduced if fee is greater than create_account_min_golos_fee.
The latest parameter min_delegation replased the third multiplier and used as absolute value. That is this parameter is set by delegates voting.
One more parameter create_account_delegation_time changed measure value from mks to sec. Too much measurement accuracy is not needed.

Release Candidate 0.18.0rc2

GOLOS·CORE

In this page:
Detected and fixed weak spots in release candidate HardFork HF·18

Expected release date is schedule for 20 June 2018 12:00:00 MSK

Fixed bug in program logic of updating the tags

After removing limit on editing posts and comments, it became possible to manipulate tag activiti. This allowed a user to continue doing the tags more popular even those posts, payment for which has already been completed.

This disadvantage was eliminated due to bug fixing in program logic of updating the tags.

Fixed bug in output of the method get_discussions_by_promoted

It became possible to appear a list of sponsored posts in result due to bug fixing in the method.

Eliminated problem in delegating Golos Power operation happened because of outdated method old_update_account_bandwidth

The method old_update_account_bandwidth did not take into account a delegated Golos Power and mainly repeated the update_account_bandwith logic. As a result it caused an additional load on the nodes. Moreover, unlike update_account_bandwith which checks bandwidth's value only in time signing a transaction, the old_update_account_bandwidth method did this for each transaction of already signed blocks.

To fix this problem the method old_update_account_bandwidth was removed and those methods which returned an account field, were modified. In their results the fields having form like a new_XXX_bandwidth were converted to fields looked like a XXX_bandwidth. Besides this, their results were added by lifetime_market_bandwidth field. The method get_account_bandwidth stopped returning a result if the bandwidthType parameter takes one of two values, such are "old_market" or "old_forum".

Eliminated system slowdown caused by load of nodes

Unlimited number of nested proposal transactions allowed a user to create too complicate logical structure. It caused an excessive load on nodes operation, blocking their access and, as following, slowing down the system.

In order to eliminate this deficiency a number of nested proposal transactions was limited by 2.

The method update_chain_properties was added to cli_wallet

To simplify a voting process the method update_chain_properties was added to cli_wallet. The fix allows delegates to change a key for signing blocks when setting parameters which determined by voting.

Limited using the method witness_update_operation

In the HF·18 version an update of parameters which is determined by voting, is performed by method chain_properties_update_operation. The method terminates this operation and will only be used to change an URL and delegate's key.

It was fixed because of the method does not allow to expand the list of parameters determined by voting. In future such behavior of the method would cause some difficulties.

Changed default value of multiplier

Default value of multiplier GOLOS_CREATE_ACCOUNT_WITH_GOLOS_MODIFIER has been decreased from 30 to 1. This value may be set via voting as well using the method chain_properties_update_operation. In case no voting its value takes 1.

This fix was done to avoid a sharp price spike of creating an account with the HF·18 version.

Note:
This editing was canceled after taking the delegates' decision. The multipliers are no longer used.

Implementation of experimental module Mongo

Experimental module Mongo has been added to main development branch to accelerate its development. At present stage the module does not provide loading all data from blockchain to Mongo.

Release Candidate 0.18.0rc1

GOLOS·CORE Equality HF·18 Release Notes

This page contains general information about a new BlockChain version from Golos·Core, based on new realised features and named as HF·18. Golos·Core recommends all witnesses, seed nodes and anyone else who uses the witness plug-in have to update to HF·18.

Reindexing

HF·18 requires reindexing from all previous versions.

Overview

HF·18 is a release with miscellaneous bug fixes enhancements and released new functionallity.

New features

• Golos Power delegation
• Preventing various abuse kinds of the Golos Power delegation operation
• HF•18 provides more flexible pricing policy on the exchange due to remove old data and use actual only for determining the exchange rate and the ratio of cryptocurrencies
• Ability for users to edit their profile by using the posting key
• Ability for users to propose a transaction which requires approval of multiple accounts in order to execute
• Ability for users to update their posts and comments regardless of when they were published

New technical capabilities

• Increasing system performance due to placing frequently and rarely used database fields in different objects
• Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively
• Using tags to create requests for obtaining the necessary information
• Getting shared memory status
• Ability to paginate private messages and send them out to user's screen
• Improving storage subsystem of chain blocks
  

Golos Power Delegation

This feature allows a user to delegate for a time unused part of Golos Power to another user as if she/he owned the Golos Power and could dispose it.The time-lending part of Golos Power will give the lender extra bandwidth and extra voting power for getting up a certain bonus.

It is also possible to withdraw the delegated Golos Power. This means in case of unforeseen circumstances the lender can change the delegated amount, as well as carry out the return of the delegated Golos Power in full.

The active key is required to perform these actions.

Preventing various abuse kinds of the Golos Power delegation operation

In order to prevent various fraud operations (or abuses) related with transfering delegated Golos Power from account to account, as well as cashing Golos Power into Golos, delaying operation is provided. It works as follows. This feature provides quick cashing Golos into Golos Power but requires a time delay in seven days for cashing the Golos Power into Golos.

The lender can also revoke the delegated Golos Power any time. In this case the delegated Golos Power will be withdrawn from borrower’s account immediately and returned to lender’s account in seven days.

HF•18 provides more flexible pricing policy on the exchange due to remove old data and use actual only for determining the exchange rate and the ratio of cryptocurrencies

In previous versions for determining rate of cryptocurrencies, such as Golos and GBG (Golden Backed by Golos), both new and old data were used. To fix this problem in HF•18 dynamic parameter was implemented. It shows the ratio and exchange rate of two kinds of cryptocurrencies. The value of this ratio is determined by delegates of the system. The course values proposed by delegates are stored in a database. Before determining new resulting value of the course all of old values are removed from the database and not used in calculation of the current course of Golos and GBG. The resulting value of the course is defined as the average value.

The feature provides more correct pricing policy for Golos and GBG on the stock exchange.

Ability for users to edit their profile by using the posting key

HF•18, unlike the previous version, allows a user to edit the profile fields by using the posting key. In previous versions it was possible to edit any profile field by using the active key only, and was not always acceptable.

In the HF•18 version, the profile fields are divided into two groups. The first group consists of fields which are the most significant profile data (keys: posting, active, owner and memo), and another group - the fields which are less significant, but often used (avatar, gender, location, etc.).

Now, to edit the first group of the fields the user has to use the active key as before. But it is not required anymore for editing other fields of the profile. The user can easily do it by using the posting key as well.

Ability for users to propose a transaction which requires approval of multiple accounts in order to execute

HF•18 allows a user to propose a transaction on the blockchain which consists of multiple operations and requires approval of multiple accounts in order to execute. Each operation from the transaction requires an approve of the author whom the operation is intended. At any time a participant of the transaction can either approve or decline any operation too.

When a sufficient number of approvals have been granted, the operations in the proposal are evaluated. For collection of the signatures an expiration time is assigned, after which the transaction is either canceled or executed. Even if the transaction fails, the proposal will be kept until the expiration time. The author, as well as other participants of the transaction, can change their decisions and update the signatures before the expiration time.

As soon as the proposed transaction get sufficient approvals, the proposal will be regarded as resolved, and all future updates will be invalid.

In case having a refused operation the participant may form a request to delete the proposed transaction. The proposed transaction may be deleted by either author or any participant.

Ability for users to update their posts or comments regardless of when they were published

In the previous versions of the blockchain there was a time limit, after which any comment and post could not be edited. Because of this reason, user's publications might become obsolete and be unactual. The authors instead of updating them had to publish similar posts in accordance with the current situation. In HF•18 version this inconvenience is absent and users should not worry about when they were published and can edit and update their posts at any time.

Increasing system performance due to placing frequently and rarely used database fields in separate objects

A post with the comments are located in a separate object on a disk. To process the object it needs to be moved from disk to shared memory. If the object is too large the process is slowed down due to pumping of pages.

The object contains rarely used fields, such as: name of author, title, tags, some texts and links to other objects. Besides, it also contains frequently used and updated fields, such as: counters of voted users and expected bonus.

While voting, the counters are often updated and to process the object it needs to be moved every time from the disk to shared memory. Moving large object takes a long time and therefore frequent voting slows down system operation.

In HF•18 to increase system performance it was solved as follows. The frequently used and rarely used fields have been replaced into two separate objects respectively. In this case only the object with frequently used fields is loaded into shared memory. It takes much less time for processing the blocks and allows to increase system performance, while voting.

Improving API protocol performance by reallocating some methods between plug-ins to use them more effectively

In previous version the methods, which provided getting lists of operations (in block, in transaction, on accounts ), were located in database_api plug-in. To get information about operations done by a user it was necessary to start account_history plug-in, which then started those methods in database_api. As a result the process took much time the user could get unneeded information.

In HF•18 some methods were reallocated between plug-ins. Two methods get_ops_in_block and get_transaction were moved from database_api plug-in to new separate operation_history plug-in to index operations in blocks and transactions. One more method get_account_history was moved from database_api to account_history to index account operations.

Such reallocation allows the user to form a request for obtaining information about operations of the transactions (or blocks) without receiving unnecessary history of accounts. In addition, it allows to decrease the server and memory loads and increase system performance.

Using tags to create requests for obtaining the necessary information

Searching information by using tag initiates index operations, which require lots of shared memory. Moreover, they search for various types of information, which is useless for core user group and can be useful for individual user only.

Since index operations spend significant resources, all methods which manage the operations, were moved from social_network plug-in to new separate plug-in named Tag. Other methods which provide access to root elements, were left in the social_network plug-in. Besides this, some unused fields were removed from their methods at all.

New optional vote_limit parameter was implemented in the blockchain to set the maximum number of voted users. By default this value is 10000.
Because of too big number of comments to the post it makes difficult to view and search for useful information. In this case a user can generate a request via using the tag to receive comments selected in...

Release Candidate 0.17.2rc1

Golosd

Automatic scaling of the shared memory is working correctly.

Fixes:

1. Add reserved_memory to database object for storing fragmented memory size, which can’t be used by boost multi_index container.
   Catch the bad_alloc exception and force the resizing of shared memory.

Performance improvements:

1. Move non-critical but heavy validations of a pushed transaction to read-lock section, so they can be done in multithread mode.
2. Move non-critical but heavy validations of signed blocks to read-lock section, so they can be done in multithread mode.
3. Add option enable-plugins-on-push-transaction to config.ini. To increase performance you can set value to false and it disables plugin notifications about operations in a pushed transaction, which should be included to the next generated block. Plugins doesn't validate data in operations, they only update its own indexes, so notifications can be disabled on push_transaction() without any side-effects.

Additional changes

1. Add get_database_info to database_api plugin. It shows total_size, free_size, used_size and reserved_size and record count in each index
2. Add call get_database_info to cli_wallet
3. Show RPC request time on debug level.

Plugins

Private_message plugin fixes

Golosd no longer falls when the private_message plugin is enabled

StatD statistics plugin.

Blockchain statistics plugin was renamed to statsd plugin.
Changes:

1. No longer stores data in the active chain state, which allows to save memory.
2. Sends statistics to statsd.

account_history plugin

1. The ability to filter operations is added. You can specify history-whitelist-ops and history-blacklist-ops parameters with a list of operations.
2. Added the parameter history-start-block, which specifies the block number from which the history record should start.

social_network plugin

Return active_votes in get_content_replies and get_all_content_replies requests.

market_history plugin

Added get_order_book_extended.

Build Flag

CLEAR_VOTES

The key of the precompiler is replaced by the configuration parameter clear-votes-before-block. The parameter specifies the block to which comment_votes should be deleted after the cashout window is closed. The default is 0, which keep votes in database. If you want to clear votes after closing of a cashout window, you should set a big value (for example, 4 000 000 000).

LOW_MEM

1. LOW_MEM build flag does not now create indexes from json_metodata: languages and tags, as it was before.
2. database :: push_virtual_operation now regardless of the LOW_MEM flag sends virtual operations to plugins. It is disabled by the new configuration parameter skip-virtual-ops. If parameter is set to true, then virtual operations will no longer be passed to the plug-ins for processing.

The tests became a little more.

Wallet

1. Got more powerful logging.
2. No longer falls on receiving of wrong http-requests.
3. Can auto-reconnect to the golosd on losing connection
4. Got an quit method in the interactive mode.
5. Return transaction ids in get_block

v0.17.1

Configurable timeouts for read/write locks.

For example, you have a high load node, which is used to get data from the blockchain. Such nodes should in any case accept signed blocks, but it can skip transactions for broadcasting, because they may come to the node in a signed block.

For more information #499

Automatically scale shared memory

There are two main goals:

1. To automate the scaling of the shared memory file. Now, you don't need to check free size of your shared memory.
2. To increase performance of accessing to data stored in shared memory file. Because in this case data are packed in near lying pages, and OS do not flush memory pages to load other memory pages with requested data

For more information #501

v0.17.1RC1

Fixed read/write-mutex work

Fixed read/write - mutex work is necessary for api seed node firstly and for the delegate nodes that use scripts.

v0.17.0

The hardfork is schedule for Wednesday, 4 April 2018 9:00 PM UTC (5:00:00 PM EDT)

1. Implement ability to use cli_wallet from the command line

Output the result of the work in the order of pushing commands.
We can add program option called "commands".
If cli_wallet is run this way: ./cli_wallet --commands="do_this&&do_that", then cli_wallet will execute command in sequence and will print result output of the commands execution in sequence also.
Interactive mod will be disabled, so after it will immediately terminate.
Example:

./cli_wallet --server-rpc-endpoint="ws://127.0.0.1:8091" --commands="set_password 1qaz && import_key XXX"

./cli_wallet --server-rpc-endpoint="ws://127.0.0.1:8081" --commands="unlock 1qaz && create_account hello hipe \"{}\" true && get_account hipe"

2. Support the definition of languages for post in json metadata.

3. Daemon’s logs output in JSON format

Log subsystem now has additional output mode in json-format, which can be used for post-processing with easy extracting fields from log records. To activate json-output you should replace the section log.console_appender with log.json_console_appender in config.ini.

4. Fixed unit-tests and add calculated economics unit-tests

We upgraded Steem unit-tests to Golos constants, and added additional unit-tests for checking switching to HF17.

5. New Parallel API

At first an instance of blockchain (golosd) could process only one API request queue. It was a reason of bottleneck in the API, which golosd node could execute. A new architecture design allows to process multi concurrent control for different queries API.

Key Features:

• Dynamically Specify Plugins to Load
• Automaticly Load Dependent Plugins in Order
• Plugins can specify commandline arguments and configuration file options
• Program gracefully exits from SIGINT and SIGTERM

Each plugin has a simple life cycle:

1. Initialize - parse configuration file options
2. Startup - start executing, using configuration file options
3. Shutdown - stop everything and free all resources

6. Linear rewards curve

As were discussed with community the rewards curve was switched to linear. With the introduction of a linear reward curve everyone will have a say directly proportional to their stake.

7. Comment reward beneficiaries

All content can now specify beneficiaries to receive a part of their author rewards. The beneficiaries are specified in the extension field of the comment_options_operation and is a sorted vector (by account name) of account name, weight pairs. The beneficiaries can only be specified once and must be specified before any votes are cast on the comment. Most apps are already adding a comment_options_operation in the transaction that creates the comment, so this should not be much of a challenge to add to existing apps

8. Single cashout window (1 week)

99% of votes are cast in the first 7 days after creation. This elimates the need for a second payout to accumulate value to a post and simplifies logic significantly.

9. The comment depth limit has been increased to 255.

The limitation was created in Steem (and inherited by Golos) to make UI design easier. We decided to upgrade this limit to 255, which can be easy increased to 64k in the future. 64k should be more than enough depth for anybody. (Reddit has a limit of 10,000)