bitshares/bitshares-core forked from cryptonomex/graphene

This is a protocol upgrade release. All nodes should upgrade before 2018-07-19 14:00:00 UTC.

Note: in the previous release (2.0.180425) we fixed a serious bug.

• If you're upgrading from 2.0.180425 to 2.0.180612, you don't need to do anything special;
• if you're upgrading from a release earlier than 2.0.180425 to 2.0.180612, please check release notes of 2.0.180425 to see if you need to perform additional steps.

Consensus changes

• BSIP26: Refund Order Creation Fee in Originally Paid Asset when order is cancelled
• BSIP27: Asset Issuer Reclaim Fee Pool Funds
• BSIP29: Require owner authority to change asset issuer
• BSIP30: Always Allow Increasing Collateral Ratio If Debt Not Increased
• BSIP31: Update Short Position's Margin Call Price After Partially Called Or Settled
• BSIP32: Always Match Orders At Maker Price
• BSIP33: Maker Orders With Better Prices Take Precedence
• BSIP34: Always Trigger Margin Call When Call Price Above Or At Price Feed
• BSIP35: Mitigate Rounding Issue On Order Matching
• BSIP36: Remove expired price feeds on maintenance interval
• BSIP37: Allow new asset name to end with a number
• BSIP38: Add target collateral ratio option to short positions
• Bugfix #184: Potential something-for-nothing fill bug
• Bugfix #214: Proposal cannot contain proposal_update_operation
• Bugfix #453: Multiple limit order and call order matching issue
• Bugfix #588: Virtual operations should be excluded from transactions
• Bugfix #868: Clear price feed data after updated a bitAsset's backing asset ID
• Bugfix #890: Update median feeds after feed_lifetime_sec changed
• [Bugfix #922 / #931 / #970] Fixed missing checks when updating a smart coin's bitasset options E.G. force settlement delay, backing asset ID or etc;
• [Bugfix #942] Fixed missing asset authorities check for "from" account when claiming from a withdraw permission.

API changes

• extensions field of call_order_update_operation changed from an array to an object, which affects all related API's E.G. get_block, get_account_history, get_relative_account_history and etc. Due to this, old version of cli_wallet won't be compatible with new API nodes when that operation would occur in result.
• [Issue #862, PR #872] Improved pagination of list_assets node API
• [Issue #863, PR #871] Node get_ticker API now returns time stamp of latest block instead of server time
• [Issue #811, PR #861] Added get_full_account command/API to cli_wallet

Other changes

• [FC PR #36] Support Boost 1.64-1.65

• [FC PR #43] Fixed a memory leak issue in TCP socket destruction

• [FC PR #44] Fixed Diffie-Hellman shared key computation (related to memo encryption)

• [Issue #727, PR #880] Added stack trace printing when node crashes (only for boost 1.65)

• [Issue #878, PR #927] Made number of I/O threads configurable (can be manual or auto)

• [Issue #805, PR #840 / #919 / #937] Improved logging level and messages; added logging options about log-rotation

• [Issue #837, PR #848 / #839] Added cli_wallet to Docker

• [PR #938] Fixed an issue that may cause the node to store incorrect block ID to disk when switching forks

• [Issue #582, PR #813] Fixed macOS witness node crash issue when being used as an API server

• [Issue #776, PR #816 / #955] Fixed missing notification to RPC clients when changes occurred on some types of objects

• [Issue #888, PR #954] Fixed an integer overflow issue when checking whether a price feed has expired

• [Issue #864, PR #865] Fixed a cli_wallet transaction signing issue when creating proposals with transaction builder

• [Issue #859, PR #801 / #817] Fixed macOS and Ninja build errors introduced in last release

• [Issue #136, PR #928] Fixed an asset supply calculation error in test case

• [Issue #943, PR #869 / #945] Improved a few assertion error messages

• [PR #850] Removed unused asset cache from cli_wallet

• [PR #918] Fixed in-code documentation for set_desired_witness_and_committee_member_count command/API in cli_wallet

• [PR #804] Refactored node.cpp and application.cpp for easier testing

• [PR #851 / #853 / #854 / #855] Fixed several compiler warnings

Contributors

• @abitmore
• @jmjatlanta
• @oxarbitrage
• @pmconrad
• @xeroc
• @cifer-lee
• @ihla
• @zhuliting
• @Zapata

SHA256 checksum

• BitShares-Core-2.0.180612-x64-cli-tools.zip: Windows
  • 549d7b31404ef4ef4bd17854859efc4ead536e69df6c3284f773cbf15b04fe9f
• BitShares-Core-2.0.180612-macOS-cli-tools.tar.gz: macOS
  • 83384a90afe0b47f578caeedff881f8e067218ede2333fa2adfeb8f99d7267c7

This is a bugfix release.

In this release we fixed a bug in account history plugin, which may result in incorrect operation history IDs being stored under certain circumtances. Account history is mainly used by 3rd-party businesses for integration.

This bug doesn't affect consensus or chain security.

Who need to upgrade, and what to do

Businesses (E.G. exchanges, payment processors, gateways or merchants) who're running witness_node with track-account option, if rely on correctness of operation history object IDs (1.11.x) returned by witness_node to identify transactions, are likely affected.

Please:

1. upgrade the node, and
2. restart the node with --replay-blockchain parameter, and
3. carefully check historical data which was retrieved from the old node and processed in the past, compare it to new data returned by upgraded node, deal with the differences if needed, and
4. perhaps review business data process logic.

Please be aware that the 3rd step is important for businesses to avoid processing same transaction (E.G. a deposit) more than once. After restarted with --replay-blockchain, history object IDs may have changed. For example, before restart, get_relative_account_history [account_name] 0 1 0 may return an operation history ID 1.11.123456789 which indicates a deposit, but after restart, operation history ID of the same deposit may have changed to 1.11.123456700.

All earlier versions are affected.

Who are not affected

Here are some cases likely not affected by the bug. However, for your own safety, please make decision by your own.

• The bug doesn't affect delayed_node, so data stored and returned by delayed_node is always correct. IDs stored in witness_node can be different than those stored in delayed_node. If a business only reads data from delayed_node, it's not affected.

  • However, if the business also reads data from witness_node, it can be affected.

• Businesses that don't rely on correctness of 1.11.x IDs to identify transactions, for example those identify transactions by transaction IDs or signatures, are likely not affected, so don't need to upgrade.

• Nodes that were not running with track-account option are not affected, so no need to upgrade.

  • Nodes running with default options are in this categary.
  • Public seed nodes, API nodes and witnesses should be in this categary.

• Personal nodes that are not interested in history object IDs are probably affected, but usually don't need to upgrade.

More info about the bug

The bug was in account history plugin, if track-account option is used in a node, when forking occurs (E.G. due to network latency issues), the node may unintendedly skip some IDs. After that, incorrect IDs will be stored and then be returned when being queried. A restart with --replay-blockchain may correct IDs of existing/historical data, but doesn't prevent new incorrect IDs from being stored.

After upgraded and replayed, the node won't skip IDs, so will always store correct IDs.

Related issue and pull request: #585, #873.

SHA256 checksum

• BitShares-Core-2.0.180425-x64-cli-tools.zip: Windows
  • ee6687979a1dabf7ea19cdbdd717929292d091caae9bfe3c1b09fb6464f39180