Releases: OmniLayer/omnicore
Omni Core v0.5.0
v0.5.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.
Note: the first time you run this version, all Omni Layer transactions are reprocessed due to an database update, which may take 30 minutes up to several hours.
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.5.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
Fix startup issue of Omni Core
During startup, when reloading the effect of freeze transactions, it is checked, whether the sender of a freeze transaction is the issuer of that token and thus allowed to freeze tokens. However, if the issuer of the token has been changed in the meantime, that check fails. Such a fail is interpreted as state inconsistency, which is critical and causes a shutdown of the client.
With this change, historical issuers are persisted and can be accessed for any given block. When there is an issuer check, it now checks against the issuer at that point, resolving the startup issue.
Please note: the internal database of Omni Core is upgraded, which triggers a reparse of Omni Layer transactions the first time this version is started. This can take between 30 minutes and a few hours of processing time, during which Omni Core is unusable!
Speed up RPC "omni_listpendingtransactions"
When adding a transaction to the mempool, a quick and unsafe check for any Omni Layer markers is done without checking transaction validity or whether it's malformed, to identify potential Omni Layer transactions.
If the transaction has a potential marker, then it's added to a new cache. If the transaction is removed from the mempool, it's also removed from the cache.
This speeds up the RPC omni_listpendingtransactions significantly, which can be used to list pending Omni Layer transactions.
Rename OMNI and TOMNI to OMN and TOMN
To be more algined with other symbols and tickers the following changes in wording are made:
Omni, referring to the native tokens of the Omni Layer protocol, becomesOmni tokensTest Omni, referring to the native test tokens of the Omni Layer protocol, becomesTest Omni tokensOMNI, referring to the symbol of Omni tokens, becomesOMNTOMNI, referring to the symbol of Test Omni tokens, becomesTOMN
While this is change is mostly cosmetic - in particular it changes the code documentation, RPC help messages and RPC documentation - it also has an effect of the RPCs omni_getproperty 1 and omni_getproperty 2, which now return a text with the updated token and symbol names.
Change log
The following list includes relevant pull requests merged into this release:
- #907 Update version to 0.4.0.99 to indicate development
- #910 Add marker cache to speed up omni_listpendingtransactions
- #925 Store historical issuers and use that data
- #908 Rename OMNI and TOMNI to OMN and TOMN
- #931 Bump version to Omni Core 0.5.0
- #932 Add release notes for Omni Core 0.5.0
Credits
Thanks to everyone who contributed to this release!
Omni Core v0.4.0
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
- Omni Core v0.4.0
- Upgrading and downgrading
- Notable changes
- Add new RPC: "omni_listblockstransactions"
- Fix RPC edge case of not identifying crowdsale purchase
- Show "ecosystem" = "all", when all tokens are moved
- Log failures when trying to restore state
- Add system for random database consistency checks
- Add checkpoint for block 562708
- Internal database related code improvements
- 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.
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 300000Fix 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!
Omni Core v0.3.1
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
- Omni Core v0.3.1
- Upgrading and downgrading
- Notable changes
- Wiki for guiding new users and developers
- Support for offline creation of raw Omni transactions
- API to fund Omni Layer transactions from other sources
- Two new RPCs to get and list all wallet balances
- Information about freeze transactions added to "omni_gettransaction"
- Fix behavior of "omni_listtransactions"
- Add field "issuerbonustokens" to "omni_getcrowdsale"
- Show receiving destination, when sending to self
- Always show frozen balance in balance RPCs
- Add "name" field to "omni_getallbalancesforaddress"
- Massive performance improvements of omnicored
- Storage of state during initial scanning
- Properly restore state, when rolling back blocks
- Avoid deadlock, when parsing transactions
- Update checkpoints up to block 520000
- Internal preperations for native Segregated Witness support
- Improved internal database structure
- 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.
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 hashExample:
$ 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 hashExample:
$ omnicore-cli "omni_funded_sendall" "1DFa5bT6KMEr6ta29QJouainsjaNBsJQhH" \
"15cWrfuvMxyxGst2FisrQcvcpF48x6sXoH" 1 "15Jhzz4omEXEyFKbdcccJwuVPea5LqsKM1"For more information, see:
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:
Omni Core v0.3.0
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
- Omni Core v0.3.0
- Upgrading and downgrading
- Consensus affecting changes
- Notable changes
- 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.
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!
Omni Core v0.2.0
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
- Omni Core v0.2.0
- Upgrading and downgrading
- Imported changes and notes
- Consensus affecting changes
- Notable changes
- 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.
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:
- Release notes for Bitcoin Core 0.11.0
- Release notes for Bitcoin Core 0.11.1
- Release notes for Bitcoin Core 0.11.2
- Release notes for Bitcoin Core 0.12.0
- Release notes for Bitcoin Core 0.12.1
- Release notes for Bitcoin Core 0.13.0
- Release notes for Bitcoin Core 0.13.1
- Release notes for Bitcoin Core 0.13.2
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.0...
Omni Core v0.0.12
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!
Omni Core v0.0.11.2
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
- Omni Core v0.0.11.2
- Upgrading and downgrading
- Consensus affecting changes
- Other notable changes
- 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.
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_gettransactionandgetactivedexsells
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 transacti...
Omni Core v0.0.11.1
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
- Omni Core v0.0.11.1
- Upgrading and downgrading
- Consensus affecting changes
- Other notable changes
- 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.
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_gettransactionandgetactivedexsells
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 n...
Omni Core v0.0.11
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
- Omni Core v0.0.11
- Upgrading and downgrading
- Consensus affecting changes
- Other notable changes
- 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.
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 s...