Skip to content

Releases: OmniLayer/omnicore

Omni Core v0.12.0

25 Oct 14:34
@dexX7 dexX7
v0.12.0.1
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
9f4b286
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.12.0 Latest
Latest

v0.12.0 is a major release and adds the ability to send tokens from one address to multiple receivers within one transaction.

This release is mandatory and changes the rules of the Omni Layer protocol. An upgrade is required.

Upgrading from Omni Core 0.11 does not require a rescan and can be done very fast with minimal interruption.

Please report bugs using the issue tracker on GitHub:

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

Table of contents

  • Omni Core v0.12.0
  • Upgrading and downgrading
    • How to upgrade
    • Downgrading
    • Compatibility with Bitcoin Core
  • Improvements
    • Send to many
    • Blocktime in RPCs
  • Change log
  • Credits

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.

When upgrading from a version older than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.11 does not require a rescan and can be done very fast with minimal interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.12.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it can be necessary to reprocess Omni Layer transactions.

Improvements

Send to many

This change adds the ability to construct and send send-to-many transactions.

Please note, this transaction type is not available on mainnet until after its activation. A notice will be posted on Twitter and the Omni Layer mailing list. Testing on testnet and regtest mode is available from the start.

What can you do?

  • Send send-to-many transactions
  • Construct payloads for send-to-many transactions
  • Parse and retrieve data of send-to-many transactions

What's new?

A new transaction type 7 is introduced to transfer multiple tokens of one property id to multiple receivers. Check out this link for a more detailed view.

Two new RPCs were added to facilitate the new feature:

  • omni_sendtomany to send send-to-many transactions via the user's wallet.
  • omni_createpayload_sendtomany to construct the plain payload. Note however, the rest of the transaction, in particular actually adding outputs for each receiver is still necessary.

What else is affected?

  • omni_gettransaction can be used to retrieve information about send-to- many transactions. The new fields receivers, which provides a list for every receiver, and totalamount are most relevant for this transaction. See the examples below.
  • The change output of Omni transactions is no longer random, but added to the end of the transaction. This affects all Omni transactions generated by this version of Omni Core.
  • The transaction history window of the Qt client properly shows send-to-many transactions.

Example 1:

You are a low level developer and want to manually craft transactions, then you can use the raw transaction interface of Omni Core. To construct the payload for a send-to-many transaction:

omni_createpayload_sendtomany 31 '[{"output": 2, "amount": "10.5"}, {"output": 3, "amount": "0.5"}, {"output": 5, "amount": "15.0"}]'

000000070000001f0302000000003e95ba80030000000002faf080050000000059682f00

Example 2:

You have tokens in your wallet, which you want to transfer to two receivers, three units to one, five units to the other one:

omni_sendtomany "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C" 3 '[{"address": "mnM5bS3qQTxZSHkgpp2LDcKYL5thWtqCD6", "amount": "3"}, {"address": "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C", "amount": "5"}]'

55d9f3eb56a5de5afef6b1d5dcdc2300d26d0aafcacbbfe387cba0983e0644fa

Example 3:

To then retrieve information about the transaction, you can use omni_gettransaction, which has the new fields receivers and totalamount.

omni_gettransaction 55d9f3eb56a5de5afef6b1d5dcdc2300d26d0aafcacbbfe387cba0983e0644fa

{
  "txid": "55d9f3eb56a5de5afef6b1d5dcdc2300d26d0aafcacbbfe387cba0983e0644fa",
  "fee": "0.00002420",
  "sendingaddress": "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C",
  "ismine": true,
  "version": 0,
  "type_int": 7,
  "type": "Send To Many",
  "propertyid": 3,
  "divisible": false,
  "receivers": [
    {
      "output": 1,
      "address": "mnM5bS3qQTxZSHkgpp2LDcKYL5thWtqCD6",
      "amount": "3"
    },
    {
      "output": 2,
      "address": "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C",
      "amount": "5"
    }
  ],
  "totalamount": "8",
  "valid": false,
  "invalidreason": "Not enough funds in user address",
  "blockhash": "1ca23be7bee5dc915e76292e78aa1b42d75e4a3819d91871e69b24d292930687",
  "blocktime": 1648120618,
  "positioninblock": 2,
  "block": 112,
  "confirmations": 1
}

Example 4:

Say you are a developer again and want to take a look at the above created transaction on a Bitcoin protocol level, then:

getrawtransaction 55d9f3eb56a5de5afef6b1d5dcdc2300d26d0aafcacbbfe387cba0983e0644fa 1

{
  "txid": "55d9f3eb56a5de5afef6b1d5dcdc2300d26d0aafcacbbfe387cba0983e0644fa",
  "hash": "d74b35b379f4796c918cc2475d4942f0a2e3caf9ae345488f56bac92384145ef",
  "version": 2,
  "size": 323,
  "vsize": 242,
  "weight": 965,
  "locktime": 0,
  "vin": [
    {
      "txid": "2a89b07484fe8aa2b3038d32e2888b9b30de4553e23136e324502a0f049ed6b1",
      "vout": 3,
      "scriptSig": {
        "asm": "00149cae6190b0802e646e93b9006b7239b036002ca0",
        "hex": "1600149cae6190b0802e646e93b9006b7239b036002ca0"
      },
      "txinwitness": [
        "30440220651224e5c625d8163cb6e2971f58b191109b5dc02fb821694ada765ab424b23602206cd8787258b3538f78f157ac6d1d520a21d3e1febda9477d77120e171d0225a301",
        "02d0c8e0f374949dae9c0855d56af23b4d64c3c128fe336cd36a5270b2898a9964"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 6f6d6e69000000070000000302010000000000000003020000000000000005",
        "hex": "6a1f6f6d6e69000000070000000302010000000000000003020000000000000005",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000546,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 4aead0759e716330b6c76ffaa4be6d27124efcef OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9144aead0759e716330b6c76ffaa4be6d27124efcef88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mnM5bS3qQTxZSHkgpp2LDcKYL5thWtqCD6"
        ]
      }
    },
    {
      "value": 0.00000540,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_HASH160 b213aa3f6789fa2dca904d41d2bc4877d8437aa4 OP_EQUAL",
        "hex": "a914b213aa3f6789fa2dca904d41d2bc4877d8437aa487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C"
        ]
      }
    },
    {
      "value": 4.99981210,
      "n": 3,
      "scriptPubKey": {
        "asm": "OP_HASH160 b213aa3f6789fa2dca904d41d2bc4877d8437aa4 OP_EQUAL",
        "hex": "a914b213aa3f6789fa2dca904d41d2bc4877d8437aa487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2N9UopnCBgbC6wAjMaiqrBZjmgNFiZccY7C"
        ]
      }
    }
  ],
  "hex": "02000000000101b1d69e040f2a5024e33631e25345de309b8b88e2328d03b3a28afe8474b0892a03000000171600149cae6190b0802e646e93b9006b7239b036002ca0feffffff040000000000000000216a1f6f6d6e6900000007000000030201000000000000000302000000000000000522020000000000001976a9144aead0759e716330b6c76ffaa4be6d27124efcef88ac1c0200000000000017a914b213aa3f6789fa2dca904d41d2bc4877d8437aa4879a1bcd1d0000000017a914b213aa3f6789fa2dca904d41d2bc4877d8437aa487024730440220651224e5c625d8163cb6e2971f58b191109b5dc02fb821694ada765ab424b23602206cd8787258b3538f78f157ac6d1d520a21d3e1febda9477d77120e171d0225a3012102d0c8e0f374949dae9c0855d56af23b4d64c3c128fe336cd36a5270b2898a996400000000",
  "blockhash": "1ca23be7bee5dc915e76292e78aa1b42d75e4a3819d91871e69b24d292930687",
  "confirmations": 1,
  "time": 1648120618,
  "blocktime": 1648120618
}

The above examples were created locally in regtest mode.

Blocktime in RPCs

The attribute "blocktime" was added to the matches of MetaDEx trades, when using the RPCs "omni_gettrade", "omni_gettradehistoryforaddress" and "omni_gettradehistoryforpair".

Change ...

Read more
Assets 14

Omni Core v0.11.0

03 Jul 16:13
@dexX7 dexX7
v0.11.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
1c0ae8a
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.11.0

v0.11.0 is a major release and adds the ability to issue non-fungible token and to delegate the management of a token.

The delegation of token management will go live with block 702250, which is expected to be on or about 26rd September, 2021.

This release is mandatory and after the activation of the new features, the rules of the Omni Layer protocol are changed and incompatible with older versions of Omni Core. An upgrade is required.

A note will be shown within Omni Core and on the Omni Layer Twitter, when new features are activated.

Table of contents

  • Omni Core v0.11.0
  • Upgrading and downgrading
    • How to upgrade
    • Downgrading
    • Compatibility with Bitcoin Core
  • Improvements
    • Non-fungible tokens
    • Delegate management of tokens
    • Move CI test builds to Cirrus
  • Change log
  • Credits

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.

When upgrading from a version older than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.9.0, 0.8.2, 0.8.1 or 0.8.0 does not require a rescan and can be done very fast without interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.11.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Improvements

Non-fungible tokens

This release adds the ability to create managed tokens with a unique index, grant data, issuer data and holder data. Grant data is set on issuance, issuer data and holder data can be set at any point by the current issuer or holder respectively. Grant data repurposes the memo field used in grant transactions that were not previously used other than to set data on the blockchain.

This feature needs to be enabled with an activation transaction.

Two new transaction types were added:

  • 5: "Unique Send"
  • 201: "Set Non-Fungible Token Data"

Overview

A new token type "unique" was added, which can be specified when creating a new managed token with "omni_sendissuancemanaged". Unique, or non-fungible tokens, can individually be identified, sent or enhanced with extra data. This can be useful to represent art, real estate or other digital or real world items on the blockchain. Individual units of a non-fungible token can be transferred with "omni_sendnonfungible".

RPC changes

New RPCs:

Updated RPC:

Delegate management of tokens

This release adds the delegation of issuance authority to a new address, for the issuance, freezing or unfreezing of units of a managed token.

This feature needs to be enabled with an activation transaction.

Two new transaction types were added:

  • 73: "Add delegate"
  • 74: "Remove delegate"

Overview

Alice is the issuer of token and wants to delegate the issuance of new token units to Bob. She then uses "omni_sendadddelegate" to empower Bob. Alice won't be able to issue new units until she removes Bob as delegate. She doesn't give up her ability to name or remove delegates and she remains to be the one who can enable or disable freezing of units. On a more practical level, this feature can be useful, if a token was issued from a regular non-multisig address and a multisig-address is used as delegate.

Rules overview

When adding a delegate:

  • The property must be managed.
  • The sender of the transaction must be the issuer.
  • When adding a delegate, when there is already one, the old one is overwritten.
  • When a delegate is set, only the delegate can issue, revoke, freeze or unfreeze units.
  • Only the issuer can enable or disable freezing.

When removing a delegate:

  • To remove a delegate, the property must be managed
  • The sender of the transaction can be the issuer or the delegate itself.
  • The property has a delegate and the delegate matches the one to remove.
  • The delegate to remove must be named explicitly.

RPC changes

New RPCs:

Updated RPC:

Move CI test builds to Cirrus

Automated testing was moved from Travis CI to Cirrus CI.

Change log

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

- #1219 Trim Gitian build targets
- #1220 Move test builds to Cirrus
- #1223 Show Omni version in Qt and CLI
- #1207 Feature Non-Fungible Tokens
- #1224 Add opcode when calculating Omni class
- #1227 Query address for all NFTs without specifying property ID
- #1228 Add support to add a delegate for managed issuance
- #1231 Gitian Linux confi8g: replace arm 32-bit with arm64 (aarch64)
- #1232 Bump release version to 0.11
- #1234 Update RPC docs for delegated issuance
- #1233 Update release notes for Omni Core 0.11

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell and Sean Gilligan.

Assets 14

Omni Core v0.10.0

12 Apr 10:07
@dexX7 dexX7
v0.10.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
9b4fd95
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.10.0

v0.10.0 is a major release and updates the underlying version of Bitcoin Core from 0.18.1 to 0.20.1. This comes with a significant number of changes. In this version recovering from a hard shutdown or crash was also greatly improved.

While this release is not mandatory and doesn't change the consensus rules of the Omni Layer protocol, an upgrade is nevertheless recommended.

Due to the upgrade from Bitcoin Core 0.18.1 to 0.20.1, this version incooperates many changes, so please take your time to read through all release notes carefully.

Upgrading from 0.9.0, 0.8.2, 0.8.1 or 0.8.0 does not require a rescan and can be done very fast without interruption.

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.

When upgrading from an older version than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.9.0, 0.8.2, 0.8.1 or 0.8.0 does not require a rescan and can be done very fast without interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.8.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Improvements

Built on top of Bitcoin Core 0.20.1

The underlying base of Omni Core was upgraded from Bitcoin Core 0.18.1 to Bitcoin Core 0.20.1.

Please read the following release notes for further details very carefully:

Improved coin selection, when sending Omni Layer transactions

When creating and sending Omni Layer transactions, a certain transaction fee must be paid in Bitcoin.

During transaction creation, the amount of fee needed is estimated. In the past, this estimation was rather genereous, resulting in a failure during transaction creation, even when enough Bitcoin were available to create a transaction. In this release, the fee estimation was optimized.

Better recovery from hard shutdowns or crashes

After a hard shutdown, kill or crash, Omni Core sometimes lost it's database, because it was not properly saved and became corrupted. Restoring from an old state was not possible, which resulted in a very time consuming process of reparsing old transactions.

With this release, Omni Core is able to properly recover from an older state, without the need of a very time consuming reprocessing of old transactions.

Additional testing

More tests were added to Omni Core.

Change log

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

- #1186 Bitcoin 0.20.1
- #1191 [tests] check free DEx behaviour against DEx spec
- #1193 Omni overview updates
- #1194 Add Free DEx and fee cache tests
- #1197 Integrate Bitcoin Core 0.20 patches
- #1198 Additional changes missing from 0.20 merge
- #1199 Qt disable wallet change in main window
- #1200 Update version to 0.9.99 to indicate development
- #1201 Reduce amount selected for use in transactions
- #1210 cli tool: add Content-Type application/json
- #1213 If watermark not in block index load from state files
- #1214 Bump version and tests to 0.10
- #1215 Add release notes for Omni Core 0.10
- #1219 Trim Gitian build targets

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell.

Assets 13

Omni Core v0.9.0

12 Oct 22:23
@dexX7 dexX7
v0.9.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
3c5633d
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.9.0

v0.9.0 is a major release and uses Segregated Witness wrapped in P2SH for newly generated addresses per default. It also adds two new transaction types to anchor arbitrary data in the blockchain. As an experimental feature, several new commands were added to support querying any Bitcoin balance.

While this release is not mandatory and doesn't change the consensus rules of the Omni Layer protocol, an upgrade is nevertheless recommended.

Upgrading from 0.8.2, 0.8.1 or 0.8.0 does not require a rescan and can be done very fast without interruption.

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.

When upgrading from an older version than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.8.1 or 0.8.0 does not require a rescan and can be done very fast without interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.8.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Improvements

Use wrapped Segrated Witness scripts for new addresses

When using getnewaddress new addresses are generated with Segrated Witness scripts wrapped in P2SH. On mainnet, those addresses start with a 3 instead of 1. This upgrade lowers transaction fees significantly and should not break integrations.

In case you need to fall back to the legacy address generation, please start Omni Core with addresstype=legacy configuration option.

New transactions to anchor arbitrary data

Two new transaction types were added to anchor arbitrary data on-chain. This allows the creation of overlay protocols on top of the Omni protocol, or can simply be used to store any form of data in the blockchain.

Example of sending and pulling data

Sending the hex-encoded data 497420776f726b7321:

$ omnicore-cli "omni_sendanydata" "2N5bnBsaVdPBuK5xKCQ5ZTXnofBfwSxU2Th" "497420776f726b7321"
4c9776f28e7015e840a05cb0955c22fd6917cf264032ad694e5d1ee0d8ebf745

After a confirmation:

$ omnicore-cli "omni_gettransaction" "4c9776f28e7015e840a05cb0955c22fd6917cf264032ad694e5d1ee0d8ebf745"
{
  "txid": "4c9776f28e7015e840a05cb0955c22fd6917cf264032ad694e5d1ee0d8ebf745",
  "fee": "0.00003240",
  "sendingaddress": "2N5bnBsaVdPBuK5xKCQ5ZTXnofBfwSxU2Th",
  "ismine": true,
  "version": 0,
  "type_int": 200,
  "type": "Embed any data",
  "data": "497420776f726b7321",
  "valid": true,
  "blockhash": "7c1e8be2c48fa6062b2b8ff6de7b2e1bc14b7d281d961979ed195a86399abd75",
  "blocktime": 1599469254,
  "positioninblock": 1,
  "block": 367,
  "confirmations": 1
}

For more details, please see the descriptions of the new RPCs:

Experimental querying of any Bitcoin balance

A new optional database was added, which allows the user to query any Bitcoin balance or list transactions of any addresses. Please note, this feature is experimental and not enabled per default. To enable the new database, restart Omni Core with experimental-btc-balances=1 configuration option.

When enabling this option, Omni Core creates a new database for Bitcoin balances. This step can take a very long time of up to multiple days on mainnet. More than 300 GB of additional disk space are required!

Please see the descriptions of the new RPCs for more details:

Please also note, this feature is experimental and may provide inaccurate results.

Several test and under the hood improvements

To prepare Omni Core for Bitcoin Core 0.20+, OpenSSL was removed and replaced. OmniJ related tests were upgraded to use JDK 11. New tests for funded transactions were added and old bash tests were converted to the newer functional test framework. Additional checks and safe guards were implemented.

These changes improve the robustness and reliability of Omni Core.

Change log

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

- #1142 Remove OpenSSL usage from Omni source
- #1146 Travis OmniJ tests: upgrade to JDK 11 (from JDK 8)
- #1153 Check Omni token balance is consistent after reorg
- #1155 Add tests for CreateFundedTransaction
- #1159 Convert bash test scripts to functional test framework
- #1163 Set default address type to P2SH_SEGWIT
- #1166 Add new transaction type to embed any data
- #1168 Support adding a receiver address for "any data" transactions
- #1169 Avoid overflow on reindex with debug enabled
- #1165 Add bitcore indexing
- #1173 Bump version to 0.9.0
- #1175 Add description for -experimental-btc-balances
- #1179 Move lock to blockOnchainActive
- #1177 Add documentation for address index RPCs
- #1181 Return error, when using bitcore RPCs without addrindex
- #1176 Add release notes for Omni Core 0.9.0

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell.

Assets 12

Omni Core v0.8.2

08 May 10:04
@dexX7 dexX7
v0.8.2
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
516f4bd
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.8.2

v0.8.2 is a minor release and adds new RPCs to interact with the distributed exchange, which can be used to trade any tokens for bitcoins. It also incorporates significant performance improvements for the initial synchronization and upgrading from older versions of Omni Core.

Upgrading from 0.8.1 does not require a rescan and can be done very fast without interruption.

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.

When upgrading from an older version than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.8.1 does not require a rescan and can be done very fast without interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.8.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Improvements

New RPCs for the distributed exchange

Three new RPCs were added to create, update and cancel orders on the distributed exchange:

omni_sendnewdexorder

Creates a new sell offer on the distributed token/BTC exchange.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
propertyidforsale number required the identifier of the tokens to list for sale
amountforsale string required the amount of tokens to list for sale
amountdesired string required the amount of bitcoins desired
paymentwindow number required a time limit in blocks a buyer has to pay following a successful accepting order
minacceptfee string required a minimum mining fee a buyer has to pay to accept the offer

Result:

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

Example:

$ omnicore-cli "omni_sendnewdexorder" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "1.5" "0.75" 50 "0.0001"

omni_sendupdatedexorder

Updates an existing sell offer on the distributed token/BTC exchange.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
propertyidforsale number required the identifier of the tokens to update
amountforsale string required the new amount of tokens to list for sale
amountdesired string required the new amount of bitcoins desired
paymentwindow number required a new time limit in blocks a buyer has to pay following a successful accepting order
minacceptfee string required a new minimum mining fee a buyer has to pay to accept the offer

Result:

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

Example:

$ omnicore-cli "omni_sendupdatedexorder" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "1.0" "1.75" 50 "0.0001"

omni_sendcanceldexorder

Cancels existing sell offer on the distributed token/BTC exchange.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
propertyidforsale number required the identifier of the tokens to cancel

Result:

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

Example:

$ omnicore-cli "omni_sendcanceldexorder" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1

omni_senddexpay

Create and broadcast payment for an accept offer.

Please note:
Partial purchases are not possible and the whole accepted amount must be paid.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
toaddress string required the address of the seller
propertyid number required the identifier of the token to purchase
amount string required the Bitcoin amount to send

Result:

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

Example:

$ omnicore-cli "omni_senddexpay" \
    "35URq1NN3xL6GeRKUP6vzaQVcxoJiiJKd8" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "15.0"

Other RPC improvements

  • Active orders on the distributed exchange are now properly listed with the omni_getactivedexsells RPC.
  • Parsing of the ecosystem parameter of the omni_sendissuancecrowdsale, omni_sendissuancefixed, omni_sendissuancemanaged, omni_createpayload_issuancefixed, omni_createpayload_issuancecrowdsale, omni_createpayload_issuancemanaged RPCs was fixed.
  • Parsing of the redeemkey parameter of the omni_createrawtx_multisig RPC was fixed.
  • When the node is not synchronized, omni_decodetransaction needs to be provided with all inputs. If they are missing, a proper error message is now shown.
  • The fields issuer, creationtxid, fixedissuance and managedissuance are now included, when using omni_listproperties.
  • Spelling and language improvements.

Reporting vulnerabilities

A security policy was created. To see instructions on how to report a vulnerability for Omni Core the Omni Layer protocol, please see SECURITY.md.

Change log

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

- #1100 doc: set ecosystem as numeric
- #1102 Fix parsing of redeemkey of omni_createrawtx_multisig
- #1103 Fix typo: depreciated -> deprecated
- #1114 Split string to maintain property ID
- #1115 Add seperate RPCs for each DEx 1 action
- #1116 Bump version to Omni Core 0.8.2
- #1118 Add error text for omni_decodetransaction, when inputs are missing
- #1119 Add more information when listing tokens
- #1120 Add security policy
- #1121 Corrections to display of DEx info
- #1125 Pay exact amount for indivisible tokens
- #1117 Update release notes for Omni Core 0.8.2

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell.

Assets 12

Omni Core v0.8.1

25 Mar 09:38
@dexX7 dexX7
v0.8.1
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
ea3a781
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.8.1

v0.8.1 is a minor release and includes significant performance improvements for the initial synchronization and upgrading from older versions of Omni Core.

A consensus affecting issue in an earlier version of Omni Core has been identified, which may cause some transactions to be executed twice. This has been addressed and fixed in the previous major version 0.8.0.

The first time you start this version from a version older than 0.8.0, the internal database for Omni Layer transactions is reconstructed, which may consume several hours or even more than a day. Please plan your downtime accordingly.

Upgrading from 0.8.0 does not require a rescan and can be done very fast without interruption.

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.

When upgrading from an older version than 0.8.0, the database of Omni Core is reconstructed, which can easily consume several hours. During the first startup historical Omni Layer transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. The progress of the initial scan is reported on the console, the GUI and written to the debug.log. The scan may be interrupted and can be resumed.

Upgrading from 0.8.0 does not require a rescan and can be done very fast without interruption.

Downgrading

Downgrading to an Omni Core version prior to 0.8.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Imported notes

Performance improvements

Due to persistence optimizations the initial time to synchronize a new Omni Core node, upgrading from an older version than 0.8.0 or rebuilding Omni Core's database with the -startclean startup option is significantly improved.

In our tests, the time to build the internal database of Omni Core was reduced by a factor up to 4x.

Transaction replays

An issue has been discovered that affects all 0.6 and higher versions of Omni Core.

The result of this issue is that some transactions may be executed twice. The effect is that tokens will be credited and debited more than once, leaving some token balances lower or higher than they should be. No new money can be created with this issue.

This problem goes back to an update of Omni Core 0.6 in August 2019 and since then, while not necessarily exclusive, transactions of the following blocks may have been executed twice:

619141, 618465, 614732, 599587, 591848, 589999, 578141

The first startup of the 0.8.0 release will trigger a full reparse of all blocks, after which balances will be restored to their correct state. This will remove additional tokens credited by this error and any transactions which include them. This step can take several hours or more than a day.

Searching for affected transactions

To exchanges, wallet operators, and any integrators who use another database on top of Omni Core to track transactions or balances, we can suggest the following options for checking the validity of your transaction history. Each of the following options have different time or technical requirements and produce varying levels of details.

Neither option is required, if you solely use Omni Core to track balances and transaction histories, as after the first start of Omni Core 0.8.0, it's internal state is correct.

Option 1:

  • Time Commitment: Least
  • Technical Commitment: Least
  • Details: Least
  • Reliability: fair
  • Steps:
    • Before shutting down your existing node:
    • Pause all incoming/outgoing transactions for your hot/cold wallets
    • Run omnicore-cli omni_getallbalancesforaddress <hot/cold wallet address>
    • Record the balances for the addresses
    • Stop your client, upgrade to 0.8 according to the upgrade instructions of this release, relaunch and let synchronize and reparse
    • After synchronization and reparse is complete rerun the omni_getallbalancesforaddress command and compare the balances reported to the previously saved balances. (Optionally, during the parse you can also compare the saved balances to balances reported on omniexplorer.info)
    • If balances match before and after you are most likely not affected (see footnote below)
    • If you notice a discrepancy it is advised you proceed with verification via Option 2 below

Footnote: If your hot wallet utilizes the send all transaction type for sweeping this method may produce a false favorable result. You should proceed with option 2 below for optimal verification.

Option 2:

  • Time Commitment: Most
  • Technical Commitment: Moderate
  • Details: Full
  • Reliability: Most
  • Steps:
    • Stop your client, upgrade to 0.8 according to the upgrade instructions of this release, relaunch and let synchronize and reparse
    • After synchronization and reparse is complete:
    • Compile a list of all deposit transaction hashes, amounts you have processed since before you upgraded to 0.6 or later (~roughly around Aug 2019).
    • Using omnicore-cli omni_gettransaction <txhash> reprocess the list of transaction hashes checking:
    • The transaction is still valid response['valid']
    • The transaction amount matches the amount you recorded/processed in your database response['amount']
    • Note: If your service supports deposits from 'send_all' transactions you will need to adjust the amount field to check for all amounts in the response['subsends'] array of the transaction
    • For any transaction that does not match the previous two conditions, flag it for manual followup and check the discrepancy between the updated client output and the details of what you processed in the database.

Change log

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

- #1077 Move mastercore_handler_block_begin and use chain height
- #1079 Bump DB version to force reparse
- #1080 Bump version to 0.8.0
- #1082 Update release notes for Omni Core 0.8.0
- #1084 Avoid MakeWallet() when compiled without wallet
- #1086 Remove redundant function declaration in test
- #1090 Only evaluate fee cache, when it's activated
- #1091 Don't store state every block, when syncing or rescanning
- #1095 Bump version to Omni Core 0.8.1
- #1097 Update release notes for Omni Core 0.8.1

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell and Antoine Le Calvez (from coinmetrics.io).

Assets 12

Omni Core v0.8.0

02 Mar 15:14
@dexX7 dexX7
v0.8.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
6a26edf
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.8.0

v0.8.0 is a major release and an upgrade is required.

A consensus affecting issue in an earlier version of Omni Core has been identified, which may cause some transactions to be executed twice. This has been addressed and fixed in this release.

More information about this issue will be announced on https://blog.omni.foundation/.

The first time you start this version, the internal database for Omni Layer transactions is reconstructed, which may consume several hours or even more than a day. Please plan your downtime accordingly.

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.

When upgrading from an older version, the database is reconstructed, which can easily consume several hours.

During the first startup historical Omni transactions are reprocessed and Omni Core will not be usable for several hours up to more than a day. 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.8.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Imported notes

Transaction replays

An issue has been discovered that affects all 0.6 and higher versions of Omni Core.

The result of this issue is that some transactions may be executed twice. The effect is that tokens will be credited and debited more than once, leaving some token balances lower or higher than they should be. No new money can be created with this issue.

This problem goes back to an update of Omni Core 0.6 in August 2019 and since then, while not necessarily exclusive, transactions of the following blocks may have been executed twice:

619141, 618465, 614732, 599587, 591848, 589999, 578141

The first startup of the 0.8.0 release will trigger a full reparse of all blocks, after which balances will be restored to their correct state. This will remove additional tokens credited by this error and any transactions which include them. This step can take several hours or more than a day.

Searching for affected transactions

To exchanges, wallet operators, and any integrators who use another database on top of Omni Core to track transactions or balances, we can suggest the following options for checking the validity of your transaction history. Each of the following options have different time or technical requirements and produce varying levels of details.

Neither option is required, if you solely use Omni Core to track balances and transaction histories, as after the first start of Omni Core 0.8.0, it's internal state is correct.

Option 1:

  • Time Commitment: Least
  • Technical Commitment: Least
  • Details: Least
  • Reliability: fair
  • Steps:
    • Before shutting down your existing node:
    • Pause all incoming/outgoing transactions for your hot/cold wallets
    • Run omnicore-cli omni_getallbalancesforaddress <hot/cold wallet address>
    • Record the balances for the addresses
    • Stop your client, upgrade to 0.8 according to the upgrade instructions of this release, relaunch and let synchronize and reparse
    • After synchronization and reparse is complete rerun the omni_getallbalancesforaddress command and compare the balances reported to the previously saved balances. (Optionally, during the parse you can also compare the saved balances to balances reported on omniexplorer.info)
    • If balances match before and after you are most likely not affected (see footnote below)
    • If you notice a discrepancy it is advised you proceed with verification via Option 2 below

Footnote: If your hot wallet utilizes the send all transaction type for sweeping this method may produce a false favorable result. You should proceed with option 2 below for optimal verifications.

Option 2:

  • Time Commitment: Most
  • Technical Commitment: Moderate
  • Details: Full
  • Reliability: Most
  • Steps:
    • Stop your client, upgrade to 0.8 according to the upgrade instructions of this release, relaunch and let synchronize and reparse
    • After synchronization and reparse is complete:
    • Compile a list of all deposit transaction hashes, amounts you have processed since before you upgraded to 0.6 or later (~roughly around Aug 2019).
    • Using omnicore-cli omni_gettransaction <txhash> reprocess the list of transaction hashes checking:
    • The transaction is still valid response['valid']
    • The transaction amount matches the amount you recorded/processed in your database response['amount']
    • Note: If your service supports deposits from 'send_all' transactions you will need to adjust the amount field to check for all amounts in the response['subsends'] array of the transaction
    • For any transaction that does not match the previous two conditions, flag it for manual followup and check the discrepancy between the updated client output and the details of what you processed in the database.

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell.

Assets 12

Omni Core v0.7.1

21 Jan 08:24
@dexX7 dexX7
v0.7.1
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
5fe9840
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.7.1

Omni Core 0.7.1 paves the way for trading any asset on the Omni Layer for Bitcoin in a decentralized fashion. It adds new commands to accept and execute orders on the distributed exchange.

Please note, if you have not yet upgraded from 0.6 or earlier versions: Omni Core 0.7 changed the code base of Omni Core from Bitcoin Core 0.13.2 to Bitcoin Core 0.18.1. Once consensus affecting features are enabled, this version is no longer compatible with previous versions and an upgrade is required. Due to the upgrade from Bitcoin Core 0.13.2 to 0.18.1, this version incorporates many changes, so please take your time to read through all previous release notes carefully. The first time you upgrade from Omni Core 0.6 or older versions, the database is reconstructed, which can easily consume several hours. An upgrade from 0.7 to 0.7.1 is seamless.

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.

When upgrading from an older version, the database is reconstructed, which can easily consume several hours.

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.7.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Imported changes and notes

Allow any token to be traded for Bitcoin

Right now the native distributed exchange of the Omni Layer protocol supports trading Omni and Test Omni for Bitcoin.

With this version, any token can be traded and there are no longer any trading restrictions. Please see the documentation for the related RPCs:

As well as the specification of the Omni Layer protocol:

Please note: this consensus change is not yet activated, but included in this release. An announcement will be made, when this feature is activated.

Updates to omni_senddexaccept to accept orders

The RPC omni_senddexaccept was updated to properly pay transaction fees, when accepting an offer on the distributed exchange.

omni_senddexaccept

Create and broadcast an accept offer for the specified token and amount.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
toaddress string required the address of the seller
propertyid number required the identifier of the token to purchase
amount string required the amount to accept
override boolean required override minimum accept fee and payment window checks (use with caution!)

Result:

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

Example:

$ omnicore-cli "omni_senddexaccept" \
    "35URq1NN3xL6GeRKUP6vzaQVcxoJiiJKd8" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "15.0"

New command omni_senddexpay to execute orders

To pay for an offer after it was successfully accepted, a new command omni_senddexpay was added.

omni_senddexpay

Create and broadcast payment for an accept offer.

Arguments:

Name Type Presence Description
fromaddress string required the address to send from
toaddress string required the address of the seller
propertyid number required the identifier of the token to purchase
amount string required the Bitcoin amount to send

Result:

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

Example:

$ omnicore-cli "omni_senddexpay" \
    "35URq1NN3xL6GeRKUP6vzaQVcxoJiiJKd8" "37FaKponF7zqoMLUjEiko25pDiuVH5YLEa" 1 "15.0"

rpcallowip option changes

The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).

Updates to the Omni Core logo

To show the synergy between the Omni Layer protocol and Bitcoin, the Omni Core logos were slightly changed to also include the Bitcoin logo:

Several stability and performance improvements

In some rare cases locking issues may have caused the client to halt. This version comes with several stability and performance improvements to resolve these issues.

Change log

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

- #1048 omni_senddexaccept pass min fee to CreateTransaction
- #1052 Add RPC DEx call to pay for accepted offer
- #1054 Debug and concurrency updates
- #1060 Only use wtxNew if fSuccess true
- #1064 New icons and default splash
- #1066 Prepare release of Omni Core v0.7.1
- #1068 Update release notes for v0.7.1

Credits

Thanks to everyone who contributed to this release, especially to Peter Bushnell and all Bitcoin Core developers.

Assets 12

Omni Core v0.7.0

06 Nov 23:43
@dexX7 dexX7
v0.7.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
d54ff30
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.7.0

v0.7.0 is a major release and changes the code base of Omni Core from Bitcoin Core 0.13.2 to Bitcoin Core 0.18.1. Once consensus affecting features are enabled, this version is no longer compatible with previous versions and an upgrade is required.

Compared to Omni Core v0.6.0 and previous versions, v0.7.0 enhances it's distributed exchange and supports trading of any asset or token for Bitcoin. This version also fixes locking issues and the RPCs for funding transactions as well as omni_listtransactions.

Due to the upgrade from Bitcoin Core 0.13.2 to 0.18.1, this version incooperates many changes, so please take your time to read through all release notes carefully. The first time you run this version, all the database is reconstructed, which can easily consume several hours.

To avoid downtime of your system, running both versions on two instances is recommended and once v0.7.0 is up-to-date and it's behavior was confirmed to work, a hot swap may be done.

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.

When upgrading from an older version, the database is reconstructed, which can easily consume several hours.

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.7.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Imported changes and notes

Upgrade to Bitcoin Core 0.18.1

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

Please read the following release notes for further details very carefully:

Allow any token to be traded for Bitcoin

Right now the native distributed exchange of the Omni Layer protocol supports trading Omni and Test Omni for Bitcoin.

With this version, any token can be traded and there are no longer any trading restrictions.

Please note: this consensus change is not yet activated, but included in this release. An announcement will be made, when this feature is activated.

Omni specific user-agent

As per default, starting with this version, Omni Core will identify itself as /Satoshi:0.18.1 (Omni:0.7.0)/.

With the configuration option -omniuseragent=0 will hide the client as regular Bitcoin Core node.

getinfo deprecated

The getinfo RPC has been deprecated. Each field in the RPC
has been moved to another commands output with that command also giving
additional information that getinfo did not provide. The following table
shows where each field has been moved to:

getinfo field Moved to
"version" getnetworkinfo()["version"]
"protocolversion" getnetworkinfo()["protocolversion"]
"walletversion" getwalletinfo()["walletversion"]
"balance" getwalletinfo()["balance"]
"blocks" getblockchaininfo()["blocks"]
"timeoffset" getnetworkinfo()["timeoffset"]
"connections" getnetworkinfo()["connections"]
"proxy" getnetworkinfo()["networks"][0]["proxy"]
"difficulty" getblockchaininfo()["difficulty"]
"testnet" getblockchaininfo()["chain"] == "test"
"keypoololdest" getwalletinfo()["keypoololdest"]
"keypoolsize" getwalletinfo()["keypoolsize"]
"unlocked_until" getwalletinfo()["unlocked_until"]
"paytxfee" getwalletinfo()["paytxfee"]
"relayfee" getnetworkinfo()["relayfee"]
"errors" getnetworkinfo()["warnings"]

Fee estimation improvements

Fee estimation has been significantly improved with Bitcoin Core 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the estimatesmartfee and estimaterawfee RPCs (See PR 10199).

Changes to internal logic and wallet behavior

  • Internally, estimates are now tracked on three different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
  • Estimates can now be conservative or economical. Conservative estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. Economical estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
  • By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See PR 10589).
  • Estimates can now be made for confirmation targets up to 1008 blocks (one week).
  • More data on historical fee rates is stored, leading to more precise fee estimates.
  • Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
  • The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.

Changes to fee estimate RPCs

  • The estimatefee ...
Read more
Assets 12

Omni Core v0.6.0

14 Sep 18:55
@dexX7 dexX7
v0.6.0
This tag was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
9937c54
This commit was signed with the committer’s verified signature.
dexX7
GPG key ID: 7675E31CF5719832
Learn about vigilant mode.
Compare
Choose a tag to compare
Omni Core v0.6.0

v0.6.0 is a major release and changes the code base of Omni Core from Bitcoin Core 0.13.2 to Bitcoin Core 0.18.1. No Omni Layer consensus rules were changed and the consensus behavior of this version is identidcal with Omni Core v0.5.0. An upgrade is not required, but recommended in an experimental environment.

Due to the upgrade from Bitcoin Core 0.13.2 to 0.18.1, this version incooperates many changes, so please take your time to read through all release notes carefully. The first time you run this version, all the database is reconstructed, which can easily consume several hours.

To avoid downtime of your system, running both versions on two instances is recommended and once v0.6.0 is up-to-date and it's behavior was confirmed to work, a hot swap may be done.

There is no harm in skipping this version, as it's consensus behavior is identical to Omni Core v0.5.0. If you are running v0.5.0, there is no need for an update.

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.

When upgrading from an older version, the database is reconstructed, which can easily consume several hours.

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.6.0 is not supported.

Compatibility with Bitcoin Core

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

However, it is not advised to upgrade or downgrade to versions other than Bitcoin Core 0.18. When switching to Omni Core, it may be necessary to reprocess Omni Layer transactions.

Imported changes and notes

Upgrade to Bitcoin Core 0.18.2

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

Please read the following release notes for further details very carefully:

getinfo deprecated

The getinfo RPC has been deprecated. Each field in the RPC
has been moved to another commands output with that command also giving
additional information that getinfo did not provide. The following table
shows where each field has been moved to:

getinfo field Moved to
"version" getnetworkinfo()["version"]
"protocolversion" getnetworkinfo()["protocolversion"]
"walletversion" getwalletinfo()["walletversion"]
"balance" getwalletinfo()["balance"]
"blocks" getblockchaininfo()["blocks"]
"timeoffset" getnetworkinfo()["timeoffset"]
"connections" getnetworkinfo()["connections"]
"proxy" getnetworkinfo()["networks"][0]["proxy"]
"difficulty" getblockchaininfo()["difficulty"]
"testnet" getblockchaininfo()["chain"] == "test"
"keypoololdest" getwalletinfo()["keypoololdest"]
"keypoolsize" getwalletinfo()["keypoolsize"]
"unlocked_until" getwalletinfo()["unlocked_until"]
"paytxfee" getwalletinfo()["paytxfee"]
"relayfee" getnetworkinfo()["relayfee"]
"errors" getnetworkinfo()["warnings"]

Fee estimation improvements

Fee estimation has been significantly improved with Bitcoin Core 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the estimatesmartfee and estimaterawfee RPCs (See PR 10199).

Changes to internal logic and wallet behavior

  • Internally, estimates are now tracked on three different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
  • Estimates can now be conservative or economical. Conservative estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. Economical estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
  • By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be 'bumped' if the fee conditions change rapidly (See PR 10589).
  • Estimates can now be made for confirmation targets up to 1008 blocks (one week).
  • More data on historical fee rates is stored, leading to more precise fee estimates.
  • Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
  • The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.

Changes to fee estimate RPCs

  • The estimatefee RPC is now deprecated in favor of using only estimatesmartfee (which is the implementation used by the GUI)
  • The estimatesmartfee RPC interface has been changed (See PR 10707):
    • The nblocks argument has been renamed to conf_target (to be consistent with other RPC methods).
    • An estimate_mode argument has been added. This argument takes one of the following strings: CONSERVATIVE, ECONOMICAL or UNSET (which defaults to CONSERVATIVE).
    • The RPC return object now contains an errors member, which returns errors encountered during processing.
    • If Bitcoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
  • A new...
Read more
Assets 18