Skip to content

@dexX7 dexX7 released this Feb 18, 2019

v0.4.0 is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases may not be compatible with new behaviour in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior to 0.4.0 is generally not advised as older versions may not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.13.2 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core may be supported.

Upgrading to a higher Bitcoin Core version is generally supported, but when downgrading from Bitcoin Core 0.15, Omni Core needs to be started with -reindex-chainstate flag, to rebuild the chainstate data structures in a compatible format.

Downgrading to a Bitcoin Core version prior to 0.12 may not be supported due to the obfuscation of the blockchain database. In this case the database also needs to be rebuilt by starting Omni Core with -reindex-chainstate flag.

Downgrading to a Bitcoin Core version prior to 0.10 is not supported due to the new headers-first synchronization.

Notable changes

Add new RPC: "omni_listblockstransactions"

The new RPC "omni_listblockstransactions" can be used to retrieve an unordered list of Omni transactions within a range of blocks:


omni_listblockstransactions

Lists all Omni transactions in a given range of blocks.

Note: the list of transactions is unordered and can contain invalid transactions!

Arguments:

Name Type Presence Description
firstblock number required the index of the first block to consider
lastblock number required the index of the last block to consider

Result:

[      // (array of string)
  "hash",  // (string) the hash of the transaction
  ...
]

Example:

$ omnicore-cli "omni_omni_listblocktransactions" 279007 300000

Fix RPC edge case of not identifying crowdsale purchase

When a "Simple Send" transaction is also a "Crowdsale Purchase", always return "Crowdsale Purchase" for "type", when using "omni_gettransaction".

Show "ecosystem" = "all", when all tokens are moved

When moving all tokens with the "Send All" transaction and no specific ecosystem is selected, show "all" for "ecosystem", when getting information about such a transaction with "omni_gettransaction".

Log failures when trying to restore state

When, due to whatever reason, a rescan of Omni Layer transactions is triggered during a start, the reason for the rescan is written to the log file.

Add system for random database consistency checks

During startup, the existence of a collection of historical transactions is checked to detect DB inconsistencies. In this case, all Omni Layer transcations are rescaned during the start.

Add checkpoint for block 562708

To further ensure consensus consistency, a more up-to-date checkpoint was added:

{
  "block": 562710,
  "blockhash": "0000000000000000001673ef66bfbc02946c1ff7f42e8aef72d875ab7044de1e",
  "consensushash": "0be8eadf798cc595db247b85617815c936a1e607ac8faab6dec44b2ee585bd51"
}

Internal database related code improvements

Pointer names of all databases were renamed and unified to match actual database names.

Change log

The following list includes relevant pull requests merged into this release:

- #773 Log failures when trying to restore state
- #769 Don't create two similar outputs, when funding transactions
- #768 Update version to 0.3.1.99 to indicate development
- #779 Refine documentation of new funding RPCs
- #835 Add new RPC: omni_listblockstransactions
- #848 Fix RPC edge case of not identifying crowdsale purchase
- #851 Unify pointer names of internal DBs
- #874 Fix log incompability of invalid datetime
- #878 Show "ecosystem" = "all", when all tokens are moved
- #879 Bump version to Omni Core 0.4.0
- #881 Add consensus hash for block 562708
- #882 Add system to check existence of historical transactions
- #884 Remove two transactions from probing
- #885 Rename Mastercoin to Omni Layer in error message
- #883 Add release notes for Omni Core 0.4.0

Credits

Thanks to everyone who contributed to this release, and especially Dmitry Petukhov from @Simplexum for his valuable contributions!

Assets 16

@dexX7 dexX7 released this Aug 26, 2018 · 43 commits to master since this release

v0.3.1 is a minor release and not consensus critical in terms of the Omni Layer protocol rules. Besides other improvemens, this release provides two new RPCs to create funded transactions and to pay fees from different sources, two new RPCs to query token wallet balances, and signficant stability and performance gains of Omni Core.

An upgrade is highly recommended, but not required, if you are using Omni Core 0.3.0.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior to 0.3.0 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.13.2 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core may be supported.

Upgrading to a higher Bitcoin Core version is generally supported, but when downgrading from Bitcoin Core 0.15, Omni Core needs to be started with -reindex-chainstate flag, to rebuild the chainstate data structures in a compatible format.

Downgrading to a Bitcoin Core version prior to 0.12 may not be supported due to the obfuscation of the blockchain database. In this case the database also needs to be rebuilt by starting Omni Core with -reindex-chainstate flag.

Downgrading to a Bitcoin Core version prior to 0.10 is not supported due to the new headers-first synchronization.

Notable changes

Wiki for guiding new users and developers

To help and guide new users and developers, a wiki was created. The wiki includes pointers to other resources such as the JSON-RPC documentation, an overview of startup and configuration options or build instructions. It also includes guides and answers to frequently asked questions:

https://github.com/OmniLayer/omnicore/wiki

Support for offline creation of raw Omni transactions

The raw transaction interface can be used to manually craft Omni Layer transactions. With this release, it is no longer necessary to use a fully synchronized client and an offline client can be used.

An overview of the JSON-RPC commands can be found here and a guide for the manual creation of a Simple Send transaction is available in the new wiki.

API to fund Omni Layer transactions from other sources

This release adds two new RPCs "omni_funded_send" and "omni_funded_sendall", which allow the creation of Omni Layer transactions, which are funded by a different source, other than the original sender.

This can be used to pay for transaction fees, when the sender only has a tiny fraction of coins available, but not enough to cover whole fee of a transaction:


omni_funded_send

Creates and sends a funded simple send transaction.

All bitcoins from the sender are consumed and if there are bitcoins missing, they are taken from the specified fee source. Change is sent to the fee source!

Arguments:

Name Type Presence Description
fromaddress string required the address to send the tokens from
toaddress string required the address of the receiver
propertyid number required the identifier of the tokens to send
amount string required the amount to send
feeaddress string required the address that is used for change and to pay for fees, if needed

Result:

"hash"  // (string) the hex-encoded transaction hash

Example:

$ omnicore-cli "omni_funded_send" "1DFa5bT6KMEr6ta29QJouainsjaNBsJQhH" \
    "15cWrfuvMxyxGst2FisrQcvcpF48x6sXoH" 1 "100.0" \
    "15Jhzz4omEXEyFKbdcccJwuVPea5LqsKM1"

omni_funded_sendall

Creates and sends a transaction that transfers all available tokens in the given ecosystem to the recipient.

All bitcoins from the sender are consumed and if there are bitcoins missing, they are taken from the specified fee source. Change is sent to the fee source!

Arguments:

Name Type Presence Description
fromaddress string required the address to send the tokens from
toaddress string required the address of the receiver
ecosystem number required the ecosystem of the tokens to send (1 for main ecosystem, 2 for test ecosystem)
feeaddress string required the address that is used for change and to pay for fees, if needed

Result:

"hash"  // (string) the hex-encoded transaction hash

Example:

$ omnicore-cli "omni_funded_sendall" "1DFa5bT6KMEr6ta29QJouainsjaNBsJQhH" \
    "15cWrfuvMxyxGst2FisrQcvcpF48x6sXoH" 1 "15Jhzz4omEXEyFKbdcccJwuVPea5LqsKM1"

For more information, see:

https://medium.com/omnilayer/introducing-funded-omni-layer-transactions-or-how-exchanges-can-save-money-f3f04161a6af


Two new RPCs to get and list all wallet balances

Omni Core v0.3.1 adds two new RPCs to get all token balances of the wallet and to list all token balances associated with every address of the wallet:


omni_getwalletbalances

Returns a list of the total token balances of the whole wallet.

Arguments:

Name Type Presence Description
includewatchonly boolean optional include balances of watchonly addresses (default: false)

Result:

[                           // (array of JSON objects)
  {
    "propertyid" : n,         // (number) the property identifier
    "name" : "name",            // (string) the name of the token
    "balance" : "n.nnnnnnnn",   // (string) the total available balance for the token
    "reserved" : "n.nnnnnnnn"   // (string) the total amount reserved by sell offers and accepts
    "frozen" : "n.nnnnnnnn"     // (string) the total amount frozen by the issuer
  },
  ...
]

Example:

$ omnicore-cli "omni_getwalletbalances"

omni_getwalletaddressbalances

Returns a list of all token balances for every wallet address.

Arguments:

Name Type Presence Description
includewatchonly boolean optional include balances of watchonly addresses (default: false)

Result:

[                           // (array of JSON objects)
  {
    "address" : "address",      // (string) the address linked to the following balances
    "balances" :
    [
      {
        "propertyid" : n,         // (number) the property identifier
        "name" : "name",            // (string) the name of the token
        "balance" : "n.nnnnnnnn",   // (string) the available balance for the token
        "reserved" : "n.nnnnnnnn"   // (string) the amount reserved by sell offers and accepts
        "frozen" : "n.nnnnnnnn"     // (string) the amount frozen by the issuer
      },
      ...
    ]
  },
  ...
]

Example:

$ omnicore-cli "omni_getwalletaddressbalances"

Information about freeze transactions added to "omni_gettransaction"

The RPC "omni_gettransaction" now has support for the new transaction types for freezing and unfreezing tokens, which were added in the last major release.

Fix behavior of "omni_listtransactions"

Previously, when trying to skip transactions with "omni_listtransactions", the list of transactions wasn't cut properly.

This behavior was fixed and proper cutting of the result is done.

Add field "issuerbonustokens" to "omni_getcrowdsale"

While the field "addedissuertokens" of the RPC "omni_getcrowdsale" shows the amount of issuer bonus tokens not yet emitted, the new field "issuerbonustokens" now also shows the amount of tokens already granted to the issuer as bonus of a crowdsale.

Show receiving destination, when sending to self

When no explicit recipient is given in transactions such as Simple Sends, the transactions are considered as send-to-self, and tokens are simply sent to the original sender. This is now also reflected on the RPC layer, which previously showed a blank field as recipient.

Always show frozen balance in balance RPCs

When queriying balances, previously the field "frozen" was only shown, when there were actually frozen tokens. The field is now always returned, even if there are no frozen tokens, to make an integration easier and more forseeable.

Add "name" field to "omni_getallbalancesforaddress"

This release adds the "name" field to the output of the RPC "omni_getallbalancesforaddress".

While token namens are by no way unique, or serve as identifier of a token, providing the name nevertheless can improve the user experience, because it may then no longer necessary to use a RPC like "omni_getproperty" to retrieve the name of a token.

Massive performance improvements of omnicored

Due to optimizations of omnicored, the daemon of Omni Core, which serves as backend for exchanges and other integrators, the time to scan and parse new blocks for Omni Layer transactions was massively improved. On a regular machine, the time to process a full block could have taken up to 1.5 seconds, which was reduced in this release to about 300 ms.

Storage of state during initial scanning

Currently the state of the Omni Layer is persisted for the last 50 blocks away from the chain tip.

This is fine in most cases, but during a reparse, when the chain is fully synchronized, no state is stored until the chain tip is reached. This is an issue, if the client is shutdown during the reparse, because it must then start from the beginning.

To avoid this, the state is permanently stored every 10000 blocks. When there is also an inconsistency, in particular because one or more state files are missing, the blocks are reverted until the next previous point. In practice, this may look like this:

image

Additionally state is no longer persisted before the first Omni Layer transaction was mined, which speeds up the initial synchronization up to this point.

Properly restore state, when rolling back blocks

There was an issue, which caused the client to reparse all Omni Layer transactions from the very first one, when blocks where rolled back, e.g. due to corrupted persistence files. This is a very time-consuming task and not necesary. In this release, the behavior was fixed and state is properly rolled back up to 50 blocks in the past, which significantly improves robustness of the client.

Avoid deadlock, when parsing transactions

There was an edge case, which could have resulted in a deadlock, freezing the client, when a new block was processed and RPC queries were executed at the same time. This expressed itself as seemingly random halts of the program, especially in an environment with many frequent RPC queries.

This, and the former improvements, make synchronizing a new Omni Core node, as well as maintaining one, much more frictionless.

Update checkpoints up to block 520000

Two new consensus state checkpoints were added to this release, to ensure the user has no faulty database.

Internal preperations for native Segregated Witness support

Omni Core and the Omni Layer support Segregated Witness scripts wrapped as script hash since the beginning, which can provide a significant cost saving.

However, there is no support for native Segregated Witness scripts, which are idenifiable by their bech32 encoding, yet.

This release includes internal preperations for native Segregated Witness scripts to pave the way for full support.

Improved internal database structure

A huge improvement of the internal database file structure was done in this release.

In particular database, rpc and wallet files are grouped by a common filename-prefix. This provides a better handling of the project and shows which files are related and which are not.

Change log

The following list includes relevant pull requests merged into this release:

- #520 Move, group and rename functions and files for better architecture
- #521 Update version to 0.3.99 to indicate development
- #567 Fix JSON input conversions, remove checks, when creating raw payloads
- #568 Add freezing transaction data to omni_gettransaction
- #576 Add screenshot and wiki to README
- #581 No longer print Exodus balance after startup
- #592 Fix cutting of omni_listtransactions
- #594 Add support for native SW to safe solver
- #596 Update checkpoints up until block 510000
- #593 Make parsing more robust by persisting state every 10000 blocks
- #630 Update checkpoint for block 520000
- #634 Fix fail safe iteration when forming ECDSA point
- #649 Fix .gitignore
- #650 Add field "issuerbonustokens" to "omni_getcrowdsale"
- #651 Update default value for end block of omni_listtransactions
- #658 Add API to create funded raw transactions
- #690 Fix erasing from persistence set
- #693 Make boost::multi_index comparators const
- #695 Fix documentation for "omni_sendissuancefixed" RPC
- #697 Move setting properties of send-to-selfs into parsing
- #711 Avoid deadlock, when parsing transcations
- #713 Add and update fields for RPC help
- #715 Skip wallet balance caching, when not in UI mode
- #722 Always show frozen balance in balance RPCs
- #724 Add RPC documentation for creating funded transactions
- #723 Add name field to omni_getallbalancesforaddress
- #716 Add two new RPCs to retrieve wallet balance information
- #725 Add table of contents to RPC documentation
- #727 Fix skipping balances, when using omni_getallbalancesforaddress
- #728 Sign and broadcast funded transactions in one go
- #741 Remove old reference to renamed file
- #744 Clarify that bitcoins are meant in funded RPCs
- #631 Bump version to Omni Core 0.3.1
- #632 Add release notes for Omni Core 0.3.1
- #746 Fix typo in release notes

Credits

Thanks to everyone who contributed to this release, and especially @lxjxiaojun, @fengprofile and @vagabondanthe for their valuable contributions!

Assets 18

@dexX7 dexX7 released this Dec 11, 2017 · 144 commits to master since this release

v0.3.0 includes new logic for the freeze tokens functionality.

v0.3.0 is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behaviour in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup of this new release historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.3.0 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.13.2 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.12 may not be supported due to the obfuscation of the blockchain database.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Consensus affecting changes

Freezing tokens for managed properties

Omni Core 0.3.0 contains a feature that, if an issuer chooses to enable, permits an issuer of a centrally managed token to freeze tokens residing at any address for that specific property. This feature is restricted to the managed token type (where the issuer retains control over the supply of tokens) and may not be used for any other token type (for example tokens issued via crowdsale or via fixed amount cannot be frozen).

Further, feature ID 14 adds a waiting period for a managed issuer to enable the freezing feature. Once activated a waiting period (currently 4096 blocks) is enforced between the 'enable freezing' transaction and the 'freeze tokens' transaction.

See also JSON-RPC API documentation.

Notable changes

Various bug fixes and improvements

Various smaller improvements were added Omni Core 0.2.0, such as:

  • Fixing log spam generated by unconfirmed transactions
  • Including the reason for a transaction being invalidated in the RPC response
  • Adds an RPC to hash all balances in the state

Change log

The following list includes relevant pull requests merged into this release:

- #480 Add checkpoint for block 470000
- #481 Add seed blocks for 460,000 to 470,000
- #482 Remove git created macros to make builds deterministic
- #483 Update alert keys
- #493 Add seed blocks for block 470,000 to 490,000
- #494 Add checkpoints for blocks 480,000 and 490,000
- #505 Fix log spam from unconfirmed transactions
- #507 Persist the parsing result and include the reason for tx invalidation in RPC response
- #508 Add omni_getbalanceshash RPC
- #511 Travis CI: move back to the minimal image
- #512 Reintroduce forced client upgrade
- #514 Enable freezing for centrally managed tokens
- #515 Bump version to Omni Core 0.3.0

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 18

@dexX7 dexX7 released this Jun 27, 2017 · 246 commits to master since this release

v0.2.0 is a release with minor changes and improvements based on Bitcoin Core 0.13.2.

This version is built on top of v0.0.12, which is a major release and consensus critical in terms of the Omni Layer protocol rules. If you are using an older version of Omni Core than v0.0.12, an upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behavior in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.0.12 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules. Downgrading to Omni Core 0.0.12 can require a reindex of the blockchain, and is not recommended.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.13.2 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.12 may not be supported due to the obfuscation of the blockchain database.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Imported changes and notes

Upgrade to Bitcoin Core 0.13.2

The underlying base of Omni Core was upgraded from Bitcoin Core 0.10.4 to Bitcoin Core 0.13.2.

Please see the following release notes for further details:

Important transaction fee behavior changes

Earlier versions of Omni Core (prior to 0.2.0) used Bitcoin Core 0.10.x as a base. Omni Core 0.2.0 however is based on a much newer version of Bitcoin Core (0.13.2) and thus inherits various changes and improvements to the handling of fees that have been added to Bitcoin Core over time.

It is highly recommended that users of Omni Core consider these fee changes and their chosen fee settings when upgrading to Omni Core 0.2.0, and test thoroughly to ensure that fee behavior is desirable and as expected.

Consideration of the modified behavior for the -paytxfee setting is especially important. Earlier versions of Bitcoin Core (and thus earlier versions of Omni Core prior to 0.2.0) would round the size of the transaction upwards to the nearest kilobyte when calculating the fee (for example a 250 byte transaction would be rounded up to 1 kB). This issue has been resolved in newer versions of Bitcoin Core, and so Omni Core 0.2.0 will no longer perform this rounding when calculating the fee. A comparison of the behaviors can be shown in the following, where an example paytxfee value of 0.001 BTC/kB has been set:

  • Omni Core prior to 0.2.0: A transaction with a size of 250 bytes will be rounded up to 1 kB, and so a fee of 0.001 BTC will be used
  • Omni Core 0.2.0: A transaction with a size of 250 bytes will not be rounded, and so a fee of 0.00025 BTC will be used

It is also worth noting that the fee estimation algorithms were updated, and thus the fees chosen when using -txconfirmtarget (along with the output of the estimatefee RPC) will likely be different in Omni Core 0.2.0 when compared to prior versions.

API changes

The behavior of the RPC omni_gettradehistoryforaddress was amended to return newest transactions first instead of oldest.

New project versioning scheme

Starting with this version of Omni Core, the versioning scheme becomes more intuitive, as it uses MAJOR.MINOR.PATCH from now on, whereby MAJOR indicates consensus affecting changes or other non-backwards-compatible changes, MINOR indicates new functionality in a backwards-compatible manner, and PATCH is used to indicate backwards-compatible bug fixes.

New project branch structure

The latest stable version of Omni Core can be found in the master branch on GitHub, while the version under development can be found in the develop branch. This provides a cleaner seperation of source code.

Consensus affecting changes

All changes of the consensus rules are enabled by activation transactions.

Please note, while Omni Core 0.2.0 contains support for several new rules and features they are not enabled immediately and will be activated via the feature activation mechanism described above.

It follows an overview and a description of the consensus rule changes:

Fee distribution system on the Distributed Exchange

Omni Core 0.2.0 contains a fee caching and distribution system. This system collects small amounts of tokens in a cache until a distribution threshold is reached. Once this distribution threshold (trigger) is reached for a property, the fees in the cache will be distributed proportionally to holders of the Omni (#1) and Test-Omni (#2) tokens based on the percentage of the total Omni tokens owned.

Once activated fees will be collected from trading of non-Omni pairs on the Distributed Exchange (there is no fee for trading Omni pairs). The party removing liquidity from the market will incur a 0.05% fee which will be transferred to the fee cache, and subsequently distributed to holders of the Omni token.

  • Placing a trade where one side of the pair is Omni (#1) or Test-Omni (#2) incurs no fee
  • Placing a trade where liquidity is added to the market (i.e. the trade does not immediately execute an existing trade) incurs no fee
  • Placing a trade where liquidity is removed from the market (i.e. the trade immediately executes an existing trade) the liquidity taker incurs a 0.05% fee

See also fee system JSON-RPC API documentation.

This change is identified by "featureid": 9 and labeled by the GUI as "Fee system (inc 0.05% fee from trades of non-Omni pairs)".

Send To Owners cross property support

Once activated distributing tokens via the Send To Owners transaction will be permitted to cross properties if using version 1 of the transaction.

Tokens of property X then may be distributed to holders of property Y.

There is a significantly increased fee (0.00001000 per recipient) for using version 1 of the STO transaction. The fee remains the same (0.00000001) per recipient for using version 0 of the STO transaction.

Sending an STO transaction via Omni Core that distributes tokens to holders of the same property will automatically be sent as version 0, and sending a cross-property STO will automatically be sent as version 1.

The transaction format of new Send To Owners version is as follows:

Field Type Example
Transaction version 16-bit unsigned 65535
Transaction type 16-bit unsigned 65534
Tokens to transfer 32-bit unsigned 6
Amount to transfer 64-bit signed 700009
Token holders to distribute to 32-bit unsigned 23

This change is identified by "featureid": 10 and labeled by the GUI as "Cross-property Send To Owners".

Notable changes

Avoid selection of uneconomic UTXO during transaction creation

In earlier version of Omni Core (prior to 0.2.0), when creating transactions with the Qt UI or the JSON-RPC API (for example with omni_send), then the coin selection algorithm may have selected unspent outputs, which are not economic to spend. This may have caused the creation of larger and more expensive transactions than necessary.

In Omni Core 0.2.0 this is addressed by excluding inputs during the transaction creation, which are more expensive to spend than they are worth. Please note the exclusion is directly related to the fee related configuration options of Omni Core, such as -paytxfee or -txconfirmtarget.

Performance improvements during initial parsing

Due to various improvements and optimizations, the initial parsing process, when running Omni Core the first time, or when starting Omni Core with -startclean flag, is faster by a factor of up to 10x. The improvements also have a positive impact on the time, when processing a new block.

New checkpoints and seed blocks up to block 460,000

To further speed up the inital parsing process, blocks without Omni transactions are skipped up until block 460,000. To avoid relying on a hardcoded list of seed blocks, Omni Core can be started with -omniseedblockfilter=0.

Easy access to specific consensus hashes when parsing

Previously to confirm a consensus hash for a particular block it was required to enable -omnidebug=consensus_hash_every_block during parsing to log the hash for every block which caused a significant slow down due to the extra work involved.

This leads to circumstances where to validate a single consensus hash it is neccessary to perform vastly more work than necessary.

This version adds a -omnishowblockconsensushash startup option which can be used to generate consensus hashes for specific blocks.

For example, to validate the checkpoint for block 450,000 without using seed block filtering we can use:

./omnicored --startclean --omniseedblockfilter=false --omnishowblockconsensushash=450000

Which will then cause a consensus hash to be generated for the corresponding block and written to the log. Multiple instances of the parameter can be used to specify multiple blocks to generate consensus hashes for.

Various bug fixes and improvements

Various smaller improvements were added Omni Core 0.2.0, such as:

  • Fix incorrect value from getTotalTokens when fees are cached
  • Remove forwarding of setgenerate to generate
  • Reduce test time to avoid hitting Travis CI time limit
  • Sanitize RPC responses and replace non-UTF-8 compliant characters
  • Set minimum fee distribution threshold and protect against empty distributions
  • Check for fee distribution when total number of tokens is changed
  • Fix missing include of test utils header
  • Fix two Omni Core related build warnings
  • Automatically remove stale pending transactions
  • Relax data type checks of omni_createrawtx_change
  • Fix possible lock contention in omni_getactivedexsells
  • Remove managed property check in Change Issuer RPC
  • Hardcode activations up to block 438500
  • Fix a number of bugs in the QT UI
  • Lock fetching and processing inputs while parsing
  • Run RPC tests with explicitly defined datadir and minimum logging

Change log

The following list includes relevant pull requests merged into this release:

- #436 Improve parsing performance
- #439 Fix incorrect value from getTotalTokens when fees are cached
- #440 Remove forwarding of setgenerate to generate
- #441 Reduce test time to avoid hitting Travis CI time limit
- #443 Sanitize RPC responses and replace non-UTF-8 compliant characters
- #447 Set minimum fee distribution threshold and protect against empty distributions
- #448 Check for fee distribution when total number of tokens is changed
- #451 Fix missing include of test utils header
- #450 Port code base to Bitcoin Core 0.13.2
- #453 Update splash screen to be similar to 0.0.11
- #454 Fix two Omni Core related build warnings
- #458 Add checkpoint for block 450,000
- #457 Add seed blocks for 440,000 to 450,000
- #456 Provide easy access to specific consensus hashes when parsing
- #460 Show newest transactions for omni_gettradehistoryforaddress
- #463 Automatically remove stale pending transactions
- #464 Relax data type checks of omni_createrawtx_change
- #465 Fix possible lock contention in omni_getactivedexsells
- #466 Add consensus hash for block 460,000
- #467 Add seed blocks for 450,000 to 460,000
- #468 Remove managed property check in Change Issuer RPC
- #470 Hardcode activations up to block 438500
- #471 Fix a number of bugs in the QT UI
- #472 Lock fetching and processing inputs while parsing
- #473 Avoid selecting uneconomic UTXO during transaction creation
- #474 Run RPC tests with explicitly defined datadir and minimum logging
- #460 Bump version to Omni Core 0.2.0 and add release notes

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 24

@dexX7 dexX7 released this Mar 21, 2017 · 4329 commits to master since this release

v0.0.12 greatly improves Omni Core's performance during the initial parsing, and it includes new logic for the fee distribution system, as well as for cross-property send-to-owner transactions.

v0.0.12 is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behavior in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.0.12 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.10.4 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Consensus affecting changes

All changes of the consensus rules are enabled by activation transactions.

Please note, while Omni Core 0.0.12 contains support for several new rules and features they are not enabled immediately and will be activated via the feature activation mechanism described above.

It follows an overview and a description of the consensus rule changes:

Fee distribution system on the Distributed Exchange

Omni Core 0.0.12 contains a fee caching and distribution system. This system collects small amounts of tokens in a cache until a distribution threshold is reached. Once this distribution threshold (trigger) is reached for a property, the fees in the cache will be distributed proportionally to holders of the Omni (#1) and Test-Omni (#2) tokens based on the percentage of the total Omni tokens owned.

Once activated fees will be collected from trading of non-Omni pairs on the Distributed Exchange (there is no fee for trading Omni pairs). The party removing liquidity from the market will incur a 0.05% fee which will be transferred to the fee cache, and subsequently distributed to holders of the Omni token.

  • Placing a trade where one side of the pair is Omni (#1) or Test-Omni (#2) incurs no fee
  • Placing a trade where liquidity is added to the market (i.e. the trade does not immediately execute an existing trade) incurs no fee
  • Placing a trade where liquidity is removed from the market (i.e. the trade immediately executes an existing trade) the liquidity taker incurs a 0.05% fee

See also fee system JSON-RPC API documentation.

This change is identified by "featureid": 9 and labeled by the GUI as "Fee system (inc 0.05% fee from trades of non-Omni pairs)".

Send To Owners cross property support

Once activated distributing tokens via the Send To Owners transaction will be permitted to cross properties if using version 1 of the transaction.

Tokens of property X then may be distributed to holders of property Y.

There is a significantly increased fee (0.00001000 per recipient) for using version 1 of the STO transaction. The fee remains the same (0.00000001) per recipient for using version 0 of the STO transaction.

Sending an STO transaction via Omni Core that distributes tokens to holders of the same property will automatically be sent as version 0, and sending a cross-property STO will automatically be sent as version 1.

The transaction format of new Send To Owners version is as follows:

Field Type Example
Transaction version 16-bit unsigned 65535
Transaction type 16-bit unsigned 65534
Tokens to transfer 32-bit unsigned 6
Amount to transfer 64-bit signed 700009
Token holders to distribute to 32-bit unsigned 23

This change is identified by "featureid": 10 and labeled by the GUI as "Cross-property Send To Owners".

Notable changes

Performance improvements during initial parsing

Due to various improvements and optimizations, the initial parsing process, when running Omni Core the first time, or when starting Omni Core with -startclean flag, is faster by a factor of up to 10x. The improvements also have a positive impact on the time, when processing a new block.

Change log

The following list includes relevant pull requests merged into this release:

- #449 Back port fixes & improvements from develop
- #455 Bump version to Omni Core 0.0.12.0-rel

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 20

@dexX7 dexX7 released this Nov 20, 2016

v0.0.11.2 is a bugfix release which resolves an issue where, in the case where a buyer accepts more than available for sale on the traditional distributed exchange, the RPC API reported an amount higher than available, and it fixes an issue with the planned feature of fee distribution system. This release also disables the alert system as per default.

v0.0.11.1 is a bugfix release which resolves a critical bug in the RPC API whereby under certain circumstances retrieving data about a sell offer may trigger a failsafe and cause the automatic shutdown of the client.

This version is built on top of v0.0.11, which is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behavior in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.0.11 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.10.4 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Consensus affecting changes

All changes of the consensus rules are enabled by activation transactions.

Please note, while Omni Core 0.0.11 contains support for several new rules and features they are not enabled immediately and will be activated via the feature activation mechanism described above.

It follows an overview and a description of the consensus rule changes:

Trading of all pairs on the Distributed Exchange

Once activated trading of any property against any other (within the same ecosystem) will be permitted on the Distributed Exchange.

Due to this change the existing trading UI in the QT version is no longer suitable and has been disabled for this release. Please use the RPC interface to interact with the Distributed Exchange in this release. The trading UI will be re-enabled in a future version to accommodate non-Omni pair trading.

This change is identified by "featureid": 8 and labeled by the GUI as "Allow trading all pairs on the Distributed Exchange".

Fee distribution system on the Distributed Exchange

Omni Core 0.11 contains a fee caching and distribution system. This system collects small amounts of tokens in a cache until a distribution threshold is reached. Once this distribution threshold (trigger) is reached for a property, the fees in the cache will be distributed proportionally to holders of the Omni (#1) and Test-Omni (#2) tokens based on the percentage of the total Omni tokens owned.

Once activated fees will be collected from trading of non-Omni pairs on the Distributed Exchange (there is no fee for trading Omni pairs). The party removing liquidity from the market will incur a 0.05% fee which will be transferred to the fee cache, and subsequently distributed to holders of the Omni token.

  • Placing a trade where one side of the pair is Omni (#1) or Test-Omni (#2) incurs no fee
  • Placing a trade where liquidity is added to the market (i.e. the trade does not immediately execute an existing trade) incurs no fee
  • Placing a trade where liquidity is removed from the market (i.e. the trade immediately executes an existing trade) the liquidity taker incurs a 0.05% fee

See also fee system JSON-RPC API documentation.

This change is identified by "featureid": 9 and labeled by the GUI as "Fee system (inc 0.05% fee from trades of non-Omni pairs)".

Send To Owners cross property support

Once activated distributing tokens via the Send To Owners transaction will be permitted to cross properties if using version 1 of the transaction.

Tokens of property X then may be distributed to holders of property Y.

There is a significantly increased fee (0.00001000 per recipient) for using version 1 of the STO transaction. The fee remains the same (0.00000001) per recipient for using version 0 of the STO transaction.

Sending an STO transaction via Omni Core that distributes tokens to holders of the same property will automatically be sent as version 0, and sending a cross-property STO will automatically be sent as version 1.

The transaction format of new Send To Owners version is as follows:

Field Type Example
Transaction version 16-bit unsigned 65535
Transaction type 16-bit unsigned 65534
Tokens to transfer 32-bit unsigned 6
Amount to transfer 64-bit signed 700009
Token holders to distribute to 32-bit unsigned 23

This change is identified by "featureid": 10 and labeled by the GUI as "Cross-property Send To Owners".

Other notable changes

Raw payload creation API

Omni Core 0.0.11 adds support for payload creation via the RPC interface.

The calls are similar to the send transactions (e.g. omni_send), without the requirement for an address or any of the balance checks.

This allows integrators to build transactions via the raw transactions interface.

Other API extensions

An optional parameter height can be provided, when using omni_decodetransaction, which is used to determine the parsing rules. If no height is provided, the chain height is used as default.

When retrieving feature activation transactions with omni_gettransaction, then additional fields are included in the result: "featureid", "activationblock" and "minimumversion".

The Omni Core client version is now also exposed under the new key "omnicoreversion", as well as inter via "omnicoreversion_int", when using omni_getinfo. The old key "mastercoreversion" remains for compatibility in this version.

The field "positioninblock" was added to RPCs retrieving or listing Omni transactions to provide visibility into the order of an Omni transaction within a block.

Increased OP_RETURN payload size to 80 bytes

The maximum payload for OP_RETURN outputs was increased to 80 byte.

At this point a majority of the network supports 80 byte payloads, so Omni Core can safely use the larger payload size. This can result in cheaper transactions, as there is no fallback to bare multisig encoding.

Improved consensus checks

Consensus hashing now covers much more of the state to provide wider coverage of the state. The state of properties, crowdsales and the Distributed Exchange are included in the new consensus hashing process.

Checkpoints have been updated in Omni Core 0.0.11 to reflect the new consensus hashing algorithm. Seed blocks (for faster initial transaction scanning) and checkpoints are included with Omni Core 0.0.11 up to block 410,000.

Various bug fixes and clean-ups

Various smaller improvements were added Omni Core 0.0.11, such as:

  • Grow balances to fit on "Overview" tab
  • Switch to "Bitcoin" tab in "Send" page when handling Bitcoin URIs
  • Improve and adjust fee warning threshold when sending transactions
  • Fix missing client notification for new feature activations
  • Fix Travis CI builds without cache
  • Fix syntax error in walletdb key parser
  • Fix too-aggressive database clean in block reorganization events
  • Fix issues related to omni_gettransaction and getactivedexsells

Change log

The following list includes relevant pull requests merged into this release:

- #226 Upgrade consensus hashing to cover more of the state
- #316 Support providing height for omni_decodetransaction
- #317 Expose feature activation fields when decoding transaction
- #318 Expose Omni Core client version as integer
- #321 Add consensus hash for block 390000
- #324 Fix and update seed blocks up to block 390000
- #325 Add capability to generate seed blocks over RPC
- #326 Grow balances to fit on overview tab
- #327 Switch to Bitcoin tab in Send page when handling Bitcoin URIs
- #328 Update and add unit tests for new consensus hashes
- #332 Remove seed blocks for structurally invalid transactions + reformat
- #333 Improve fee warning threshold in GUI
- #334 Update documentation for getseedblocks, getcurrentconsensushash, setautocommit
- #335 Disable logging on Windows to speed up CI RPC tests
- #336 Change the default maximum OP_RETURN size to 80 bytes
- #341 Add omni_getmetadexhash RPC call to hash state of MetaDEx
- #343 Remove pre-OP_RETURN legacy code
- #344 Fix missing client notification for new activations
- #349 Add positioninblock attribute to RPC output for transactions
- #358 Add payload creation to the RPC interface
- #361 Unlock trading of all pairs on the MetaDEx
- #364 Fix Travis builds without cache
- #365 Fix syntax error in walletdb key parser
- #367 Bump version to Omni Core 0.0.11-dev
- #368 Fix too-aggressive database clean in reorg event
- #371 Add consensus checkpoints for blocks 400,000 & 410,000
- #372 Add seed blocks for 390,000 to 410,000
- #375 Temporarily disable the trading UI
- #384 Add fee system RPC calls to API doc
- #385 Add RPC documentation for createpayload calls
- #386 Don't warn user about unknown block versions
- #377 Add release notes for Omni Core 0.0.11
- #376 Bump version to Omni Core 0.0.11-rc1
- #390 Add cross-property (v1) Send To Owners
- #395 Move test scripts into /src/omnicore/test
- #396 Add workaround for "bytes per sigops" limit
- #400 Change default confirm target to 15 blocks
- #398 Update release notes for 0.0.11-rc2
- #397 Bump version to Omni Core 0.0.11-rc2
- #402 Add seed blocks for 410,000 to 420,000
- #403 Add consensus hash for block 420,000
- #405 Use uint256 when calculating desired BTC for DEx 1
- #404 Bump version to Omni Core 0.0.11-rel
- #409 Protect uint256 plain integer math
- #411 Bump version to Omni Core 0.0.11.1-rel
- #419 Add consensus hash for block 430,000
- #420 Add seed blocks for 420,000 to 430,000
- #421 Fix edge case of DEx 1 over-accepts
- #422 Disable alert system as per default
- #423 Bump version to Omni Core 0.0.11.2-rel
- #426 Fix several bugs in fee system
- #429 Allow feature deactivation
- #431 Activate recent new features on testnet
- #432 Change the number of signatures for deactivation to 3
- #430 Update release notes for 0.0.11.2
- #435 Bump internal version to 1100201

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 21

@dexX7 dexX7 released this Aug 1, 2016 · 37 commits to omnicore-0.0.10 since this release

v0.0.11.1 is a bugfix release which resolves a critical bug in the RPC API whereby under certain circumstances retrieving data about a sell offer may trigger a failsafe and cause the automatic shutdown of the client.

This version is built on top of v0.0.11, which is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behavior in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.0.11 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.10.4 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Consensus affecting changes

All changes of the consensus rules are enabled by activation transactions.

Please note, while Omni Core 0.0.11 contains support for several new rules and features they are not enabled immediately and will be activated via the feature activation mechanism described above.

It follows an overview and a description of the consensus rule changes:

Trading of all pairs on the Distributed Exchange

Once activated trading of any property against any other (within the same ecosystem) will be permitted on the Distributed Exchange.

Due to this change the existing trading UI in the QT version is no longer suitable and has been disabled for this release. Please use the RPC interface to interact with the Distributed Exchange in this release. The trading UI will be re-enabled in a future version to accommodate non-Omni pair trading.

This change is identified by "featureid": 8 and labeled by the GUI as "Allow trading all pairs on the Distributed Exchange".

Fee distribution system on the Distributed Exchange

Omni Core 0.11 contains a fee caching and distribution system. This system collects small amounts of tokens in a cache until a distribution threshold is reached. Once this distribution threshold (trigger) is reached for a property, the fees in the cache will be distributed proportionally to holders of the Omni (#1) and Test-Omni (#2) tokens based on the percentage of the total Omni tokens owned.

Once activated fees will be collected from trading of non-Omni pairs on the Distributed Exchange (there is no fee for trading Omni pairs). The party removing liquidity from the market will incur a 0.05% fee which will be transferred to the fee cache, and subsequently distributed to holders of the Omni token.

  • Placing a trade where one side of the pair is Omni (#1) or Test-Omni (#2) incurs no fee
  • Placing a trade where liquidity is added to the market (i.e. the trade does not immediately execute an existing trade) incurs no fee
  • Placing a trade where liquidity is removed from the market (i.e. the trade immediately executes an existing trade) the liquidity taker incurs a 0.05% fee

See also fee system JSON-RPC API documentation.

This change is identified by "featureid": 9 and labeled by the GUI as "Fee system (inc 0.05% fee from trades of non-Omni pairs)".

Send To Owners cross property support

Once activated distributing tokens via the Send To Owners transaction will be permitted to cross properties if using version 1 of the transaction.

Tokens of property X then may be distributed to holders of property Y.

There is a significantly increased fee (0.00001000 per recipient) for using version 1 of the STO transaction. The fee remains the same (0.00000001) per recipient for using version 0 of the STO transaction.

Sending an STO transaction via Omni Core that distributes tokens to holders of the same property will automatically be sent as version 0, and sending a cross-property STO will automatically be sent as version 1.

The transaction format of new Send To Owners version is as follows:

Field Type Example
Transaction version 16-bit unsigned 65535
Transaction type 16-bit unsigned 65534
Tokens to transfer 32-bit unsigned 6
Amount to transfer 64-bit signed 700009
Token holders to distribute to 32-bit unsigned 23

This change is identified by "featureid": 10 and labeled by the GUI as "Cross-property Send To Owners".

Other notable changes

Raw payload creation API

Omni Core 0.0.11 adds support for payload creation via the RPC interface.

The calls are similar to the send transactions (e.g. omni_send), without the requirement for an address or any of the balance checks.

This allows integrators to build transactions via the raw transactions interface.

Other API extensions

An optional parameter height can be provided, when using omni_decodetransaction, which is used to determine the parsing rules. If no height is provided, the chain height is used as default.

When retrieving feature activation transactions with omni_gettransaction, then additional fields are included in the result: "featureid", "activationblock" and "minimumversion".

The Omni Core client version is now also exposed under the new key "omnicoreversion", as well as inter via "omnicoreversion_int", when using omni_getinfo. The old key "mastercoreversion" remains for compatibility in this version.

The field "positioninblock" was added to RPCs retrieving or listing Omni transactions to provide visibility into the order of an Omni transaction within a block.

Increased OP_RETURN payload size to 80 bytes

The maximum payload for OP_RETURN outputs was increased to 80 byte.

At this point a majority of the network supports 80 byte payloads, so Omni Core can safely use the larger payload size. This can result in cheaper transactions, as there is no fallback to bare multisig encoding.

Improved consensus checks

Consensus hashing now covers much more of the state to provide wider coverage of the state. The state of properties, crowdsales and the Distributed Exchange are included in the new consensus hashing process.

Checkpoints have been updated in Omni Core 0.0.11 to reflect the new consensus hashing algorithm. Seed blocks (for faster initial transaction scanning) and checkpoints are included with Omni Core 0.0.11 up to block 410,000.

Various bug fixes and clean-ups

Various smaller improvements were added Omni Core 0.0.11, such as:

  • Grow balances to fit on "Overview" tab
  • Switch to "Bitcoin" tab in "Send" page when handling Bitcoin URIs
  • Improve and adjust fee warning threshold when sending transactions
  • Fix missing client notification for new feature activations
  • Fix Travis CI builds without cache
  • Fix syntax error in walletdb key parser
  • Fix too-aggressive database clean in block reorganization events
  • Fix issues related to omni_gettransaction and getactivedexsells

Change log

The following list includes relevant pull requests merged into this release:

- #226 Upgrade consensus hashing to cover more of the state
- #316 Support providing height for omni_decodetransaction
- #317 Expose feature activation fields when decoding transaction
- #318 Expose Omni Core client version as integer
- #321 Add consensus hash for block 390000
- #324 Fix and update seed blocks up to block 390000
- #325 Add capability to generate seed blocks over RPC
- #326 Grow balances to fit on overview tab
- #327 Switch to Bitcoin tab in Send page when handling Bitcoin URIs
- #328 Update and add unit tests for new consensus hashes
- #332 Remove seed blocks for structurally invalid transactions + reformat
- #333 Improve fee warning threshold in GUI
- #334 Update documentation for getseedblocks, getcurrentconsensushash, setautocommit
- #335 Disable logging on Windows to speed up CI RPC tests
- #336 Change the default maximum OP_RETURN size to 80 bytes
- #341 Add omni_getmetadexhash RPC call to hash state of MetaDEx
- #343 Remove pre-OP_RETURN legacy code
- #344 Fix missing client notification for new activations
- #349 Add positioninblock attribute to RPC output for transactions
- #358 Add payload creation to the RPC interface
- #361 Unlock trading of all pairs on the MetaDEx
- #364 Fix Travis builds without cache
- #365 Fix syntax error in walletdb key parser
- #367 Bump version to Omni Core 0.0.11-dev
- #368 Fix too-aggressive database clean in reorg event
- #371 Add consensus checkpoints for blocks 400,000 & 410,000
- #372 Add seed blocks for 390,000 to 410,000
- #375 Temporarily disable the trading UI
- #384 Add fee system RPC calls to API doc
- #385 Add RPC documentation for createpayload calls
- #386 Don't warn user about unknown block versions
- #377 Add release notes for Omni Core 0.0.11
- #376 Bump version to Omni Core 0.0.11-rc1
- #390 Add cross-property (v1) Send To Owners
- #395 Move test scripts into /src/omnicore/test
- #396 Add workaround for "bytes per sigops" limit
- #400 Change default confirm target to 15 blocks
- #398 Update release notes for 0.0.11-rc2
- #397 Bump version to Omni Core 0.0.11-rc2
- #402 Add seed blocks for 410,000 to 420,000
- #403 Add consensus hash for block 420,000
- #405 Use uint256 when calculating desired BTC for DEx 1
- #404 Bump version to Omni Core 0.0.11-rel
- #409 Protect uint256 plain integer math
- #411 Bump version to Omni Core 0.0.11.1-rel

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 20

@dexX7 dexX7 released this Jul 21, 2016 · 42 commits to omnicore-0.0.10 since this release

v0.0.11 is a major release and consensus critical in terms of the Omni Layer protocol rules. An upgrade is mandatory, and highly recommended. Prior releases will not be compatible with new behavior in this release.

Please report bugs using the issue tracker on GitHub:

https://github.com/OmniLayer/omnicore/issues

Table of contents

Upgrading and downgrading

How to upgrade

If you are running Bitcoin Core or an older version of Omni Core, shut it down. Wait until it has completely shut down, then copy the new version of omnicored, omnicore-cli and omnicore-qt. On Microsoft Windows the setup routine can be used to automate these steps.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for approximately 15 minutes up to two hours. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted, but can not be resumed, and then needs to start from the beginning.

Downgrading

Downgrading to an Omni Core version prior 0.0.11 is generally not supported as older versions will not provide accurate information due to the changes in consensus rules.

Compatibility with Bitcoin Core

Omni Core is based on Bitcoin Core 0.10.4 and can be used as replacement for Bitcoin Core. Switching between Omni Core and Bitcoin Core is fully supported at any time.

Downgrading to a Bitcoin Core version prior 0.10 is not supported due to the new headers-first synchronization.

Consensus affecting changes

All changes of the consensus rules are enabled by activation transactions.

Please note, while Omni Core 0.0.11 contains support for several new rules and features they are not enabled immediately and will be activated via the feature activation mechanism described above.

It follows an overview and a description of the consensus rule changes:

Trading of all pairs on the Distributed Exchange

Once activated trading of any property against any other (within the same ecosystem) will be permitted on the Distributed Exchange.

Due to this change the existing trading UI in the QT version is no longer suitable and has been disabled for this release. Please use the RPC interface to interact with the Distributed Exchange in this release. The trading UI will be re-enabled in a future version to accommodate non-Omni pair trading.

This change is identified by "featureid": 8 and labeled by the GUI as "Allow trading all pairs on the Distributed Exchange".

Fee distribution system on the Distributed Exchange

Omni Core 0.11 contains a fee caching and distribution system. This system collects small amounts of tokens in a cache until a distribution threshold is reached. Once this distribution threshold (trigger) is reached for a property, the fees in the cache will be distributed proportionally to holders of the Omni (#1) and Test-Omni (#2) tokens based on the percentage of the total Omni tokens owned.

Once activated fees will be collected from trading of non-Omni pairs on the Distributed Exchange (there is no fee for trading Omni pairs). The party removing liquidity from the market will incur a 0.05% fee which will be transferred to the fee cache, and subsequently distributed to holders of the Omni token.

  • Placing a trade where one side of the pair is Omni (#1) or Test-Omni (#2) incurs no fee
  • Placing a trade where liquidity is added to the market (i.e. the trade does not immediately execute an existing trade) incurs no fee
  • Placing a trade where liquidity is removed from the market (i.e. the trade immediately executes an existing trade) the liquidity taker incurs a 0.05% fee

See also fee system JSON-RPC API documentation.

This change is identified by "featureid": 9 and labeled by the GUI as "Fee system (inc 0.05% fee from trades of non-Omni pairs)".

Send To Owners cross property support

Once activated distributing tokens via the Send To Owners transaction will be permitted to cross properties if using version 1 of the transaction.

Tokens of property X then may be distributed to holders of property Y.

There is a significantly increased fee (0.00001000 per recipient) for using version 1 of the STO transaction. The fee remains the same (0.00000001) per recipient for using version 0 of the STO transaction.

Sending an STO transaction via Omni Core that distributes tokens to holders of the same property will automatically be sent as version 0, and sending a cross-property STO will automatically be sent as version 1.

The transaction format of new Send To Owners version is as follows:

Field Type Example
Transaction version 16-bit unsigned 65535
Transaction type 16-bit unsigned 65534
Tokens to transfer 32-bit unsigned 6
Amount to transfer 64-bit signed 700009
Token holders to distribute to 32-bit unsigned 23

This change is identified by "featureid": 10 and labeled by the GUI as "Cross-property Send To Owners".

Other notable changes

Raw payload creation API

Omni Core 0.0.11 adds support for payload creation via the RPC interface.

The calls are similar to the send transactions (e.g. omni_send), without the requirement for an address or any of the balance checks.

This allows integrators to build transactions via the raw transactions interface.

Other API extensions

An optional parameter height can be provided, when using omni_decodetransaction, which is used to determine the parsing rules. If no height is provided, the chain height is used as default.

When retrieving feature activation transactions with omni_gettransaction, then additional fields are included in the result: "featureid", "activationblock" and "minimumversion".

The Omni Core client version is now also exposed under the new key "omnicoreversion", as well as inter via "omnicoreversion_int", when using omni_getinfo. The old key "mastercoreversion" remains for compatibility in this version.

The field "positioninblock" was added to RPCs retrieving or listing Omni transactions to provide visibility into the order of an Omni transaction within a block.

Increased OP_RETURN payload size to 80 bytes

The maximum payload for OP_RETURN outputs was increased to 80 byte.

At this point a majority of the network supports 80 byte payloads, so Omni Core can safely use the larger payload size. This can result in cheaper transactions, as there is no fallback to bare multisig encoding.

Improved consensus checks

Consensus hashing now covers much more of the state to provide wider coverage of the state. The state of properties, crowdsales and the Distributed Exchange are included in the new consensus hashing process.

Checkpoints have been updated in Omni Core 0.0.11 to reflect the new consensus hashing algorithm. Seed blocks (for faster initial transaction scanning) and checkpoints are included with Omni Core 0.0.11 up to block 410,000.

Various bug fixes and clean-ups

Various smaller improvements were added Omni Core 0.0.11, such as:

  • Grow balances to fit on "Overview" tab
  • Switch to "Bitcoin" tab in "Send" page when handling Bitcoin URIs
  • Improve and adjust fee warning threshold when sending transactions
  • Fix missing client notification for new feature activations
  • Fix Travis CI builds without cache
  • Fix syntax error in walletdb key parser
  • Fix too-aggressive database clean in block reorganization events

Change log

The following list includes relevant pull requests merged into this release:

- #226 Upgrade consensus hashing to cover more of the state
- #316 Support providing height for omni_decodetransaction
- #317 Expose feature activation fields when decoding transaction
- #318 Expose Omni Core client version as integer
- #321 Add consensus hash for block 390000
- #324 Fix and update seed blocks up to block 390000
- #325 Add capability to generate seed blocks over RPC
- #326 Grow balances to fit on overview tab
- #327 Switch to Bitcoin tab in Send page when handling Bitcoin URIs
- #328 Update and add unit tests for new consensus hashes
- #332 Remove seed blocks for structurally invalid transactions + reformat
- #333 Improve fee warning threshold in GUI
- #334 Update documentation for getseedblocks, getcurrentconsensushash, setautocommit
- #335 Disable logging on Windows to speed up CI RPC tests
- #336 Change the default maximum OP_RETURN size to 80 bytes
- #341 Add omni_getmetadexhash RPC call to hash state of MetaDEx
- #343 Remove pre-OP_RETURN legacy code
- #344 Fix missing client notification for new activations
- #349 Add positioninblock attribute to RPC output for transactions
- #358 Add payload creation to the RPC interface
- #361 Unlock trading of all pairs on the MetaDEx
- #364 Fix Travis builds without cache
- #365 Fix syntax error in walletdb key parser
- #367 Bump version to Omni Core 0.0.11-dev
- #368 Fix too-aggressive database clean in reorg event
- #371 Add consensus checkpoints for blocks 400,000 & 410,000
- #372 Add seed blocks for 390,000 to 410,000
- #375 Temporarily disable the trading UI
- #384 Add fee system RPC calls to API doc
- #385 Add RPC documentation for createpayload calls
- #386 Don't warn user about unknown block versions
- #377 Add release notes for Omni Core 0.0.11
- #376 Bump version to Omni Core 0.0.11-rc1
- #390 Add cross-property (v1) Send To Owners
- #395 Move test scripts into /src/omnicore/test
- #396 Add workaround for "bytes per sigops" limit
- #400 Change default confirm target to 15 blocks
- #398 Update release notes for 0.0.11-rc2
- #397 Bump version to Omni Core 0.0.11-rc2
- #402 Add seed blocks for 410,000 to 420,000
- #403 Add consensus hash for block 420,000
- #405 Use uint256 when calculating desired BTC for DEx 1
- #404 Bump version to Omni Core 0.0.11-rel

Credits

Thanks to everyone who contributed to this release, and especially the Bitcoin Core developers for providing the foundation for Omni Core!

Assets 20
Jul 11, 2016
Omni Core 0.0.11 release candidate 2
Jun 3, 2016
Omni Core 0.0.11 release candidate 1
You can’t perform that action at this time.