Omni layer Updated Details



  • State of the Layer: All Hands – Mar 28 2017


    • Craig
      1. Omni on Litecoin binaries status
        1. UI bug fixes worked on
        2. Release to private group this week?
      2. Answering questions about  multiple-blockchain support / BTC fork concerns
      3. Progress on Address tagging / Identity consortium
        1. Creating an omniwallet adapter for coreID
      4. Enhancements for integrators still being worked on
        1. Implement default “fee address” for exchange integrators
        2. Implement “send_many” style transaction for exchange integrators
      5. Electron wrapper for “local”(-ish) omniwallet
      6. Omniwallet DEx enhancements
        1. Protocol change to allow BTC->Token DEx?
        2. Interface updates for MetaDEx/OmniDEx
      7. Integrator communication for 0.0.12 release
      8. 0.2 Omni Core release status
    • Zathras
      1. Omni Explorer:
        1. Fixed XSS vulnerability detected by @Shannon & @Marv (reintroduced recently when data sanitation rules relaxed)
        2. Housekeeping sweep & actioned blockchain volume grow
      2. Omni Core:
        1. Continuing work refining the Omni Core Lite prototype (more feedback please!)
        2. Updated auditor to 0.0.12, fixed remaining bugs and currently running deep audit – ongoing (auditor needs performance optimization!)
    • Adam
      1. Omniwallet
        1. Handling support
        2. Added new wallet backup versioning in db
          1. Now handled by triggers so every change is backed up
        3. Looking into multisig/hardware wallets support
    • Patrick
      1. Tremendously productive week doing automation for BOND, completed application, in 2 weeks will hear from the *Central Bank* -of- Armenia
      2. Had a great time on FutureTech podcast
      3. www.equities.com joining the table in stock sponsorship, will help with marketing the stock transfer app, BITCF hit $0.28
      4. OMNI hit $9
      5. Ready to move on BTC->USDT features   
    • Sean
      1. Double-checked and accepted dexX7’s pull request for new Omni Core release.
      2. Mostly focused on consulting projects.
    • dexx
      1. Updated binary download links for 0.0.12 on omnilayer.org: https://github.com/OmniLayer/o...
      2. Sent out release announcements on dev and announce mailing lists
      3. Started porting address-index patch for 0.0.12
    • Marv
      1. Omniwallet
        1. Support
        2. Helped Adam do new wallet backup versioning

    Donate Me at following address

    Omni:13rM1mF8bqYHT3saqpFnqaWi6yJhDwqYnV

    BTC:1H9AFcYdZb6mt3wDHg1hc2AjnqrXzmv4xo



  • State of the Layer: All Hands – Apr 04 2017

    • Craig
      1. Omni on Litecoin binary release this week?
        1. UI bug fixes, Zathras updating Omni Lite logo
        2. Release to private groups first
      2. Extension Block compatibility assessment
        1. Duplicate soft fork methodology for cross-chain tokens?
      3. OmniWallet needed updates
        1. Managed issuance / grant / revoke for new issuers
        2. Lots of requests coming in
        3. Electron wrapper for “local”(-ish) omniwallet?
      4. Omniwallet DEx enhancements
        1. Protocol change to allow BTC->Token DEx?
        2. Interface updates for MetaDEx/OmniDEx
      5. Progress on Address tagging / Identity consortium
        1. Creating an omniwallet adapter for coreID
      6. Enhancements for integrators still being worked on
        1. Implement default “fee address” & Implement “send_many” style transaction
      7. Integrator communication for 0.0.12 release
      8. 0.2 Omni Core release status
      9. Prepare proposal for interested consulting firms on benefits of investment in Omni development
    • Zathras
      1. Omni Explorer:
        1. Added SSL (no data is sent to OE by users, but SSL helps privacy)
        2. Fixed a notification bug that caused incorrect warnings
        3. Fixed an outage when OC node (0.2-dev) became unresponsive, not found root cause yet
      2. Omni Core Lite:
        1. Major overhaul of the UI send tab, lots of improvements and lots of bugfixes
        2. Rebranded splash & about dialogs
        3. Generated Gitian builds of 0.0.3 Omni Core Lite for more internal testing
      3. General:
        1. Started taking a look at DexX’s atomic swaps stuff
    • Adam
      1. Omniwallet
        1. Handling support
        2. Looking into multisig/hardware wallets support
        3. Looking at managed issuance/management
    • Sean
      1. Back from travel and available this week.
    • dexx
      1. Ported address-index modifications for Omni Core 0.0.12: https://github.com/dexX7/bitco...
      2. Small fix to avoid incompatibility with Python bitcoinrpc package: https://github.com/OmniLayer/o...
      3. New exploration of guarded atomic swaps of Omni tokens
    • Marv
      1. Omniwallet
        1. Monitoring support
      2. Omniexplorer
        1. Submitting improvement feedback


  • State of the Layer: All Hands – Apr 11 2017

    1. Craig
      1. Scheduling conflict this week
    2. Zathras
      1. Omni Explorer:
        1. Fixed a bug with pagination when looking up a property
        2. Added some low level auditing capabilities to OmniEngine
      2. Omni Core:
        1. Fixed (finally!) a rare DExv1 bug that could cause lock contention when a new block is connected while omni_getactivedexsells RPC is processing accept offers (https://github.com/OmniLayer/omnicore/pull/465https://github.com/OmniLayer/omnicore/pull/467)
        2. Added checkpoint for block 460,000 (https://github.com/OmniLayer/omnicore/pull/466)
        3. Reviewed @dexx7s relax data type checks PR
      3. Omni Core Lite:
        1. Further branding changes (using new logo etc)
        2. Number of bugfixes on Send page
        3. Cleaned up overview page & fixed several bugs
    3. Adam
      1. Omniwallet
        1. Handling support
        2. Looking into multisig/hardware wallets support
        3. Looking at manage issuance/management
    4. Sean
      1. CI server running out of space
        1. Blockchain keeps on growing!
        2. Hoping to add space (with Adam) later this week.
    5. dexx
      1. Reviewed and merged: Add seed blocks for 450,000 to 460,000 https://github.com/OmniLayer/o...
      2. Reviewed and merged: Add consensus hash for block 460,000 https://github.com/OmniLayer/o...
      3. Reviewed and merged: Fix possible lock contention in omni_getactivedexsells https://github.com/OmniLayer/o...
      4. Submitted and merged: Relax datatype checks of omni_createrawtx_change https://github.com/OmniLayer/o...
      5. Small improvements of atomic swap scripts: https://github.com/dexX7/py-om...
    6. Patrick
      1. Blockchain Yield Index and charting
      2. BOND pending authorization on the coming Tuesday, preliminarily the regulatory support is in place for the approval
      3. Petitioning for near activation of the STO feature

    By,

    Adam



  • State of the Layer: All Hands – May 16 2017


    • Craig
      1. Tether arbs with taiwan customers has restored the price back to the peg
      2. Travel
        1. Will be in NY next week for Consensus / TokenSummit
        2. Will be in Israel the following two weeks for d10e, meeting with potential sponsors & partners
      3. Omni Core 0.2 status?
      4. Deloitte proposal?
      5. Protocol enhancement usage
        1. Uniquely Identifiable Tokens
          1. Getting a build of Omniwallet that supports digital objects
          2. Will be testing the prototype with specific use cases
        2. Core.ID / meta-data / address tagging
          1. Will be working with coretech devs on protocol integration
      6. Omnilayer.org redesign and content
        1. Will be engaging a designer
        2. We need to prep how-to’s, walkthroughs and descriptions
      7. Litecoin private release
        1. Emails to [email protected] has provided some feedback
      8. Integrators
        1. Made inquires about 0.0.12 update status
        2. Still need feedback from other large integrators
          1. Who else do we need?
    • Zathras
      1. Omni Explorer:
        1. Further patched Omni Engine to tolerate pending bug with unreleased 0.2.  Confirmed success (26 occurrences of bug, zero failures)
        2. Rewrote Omni Engine’s supporting library (DLL) to have a much larger debugging footprint in an effort to get more granular troubleshooting data
        3. Started work on Omni Explorer v8 (based on various user feedback over the last year & with a focus on multiple blockchain support)
      2. Omni Core:
        1. Updated Class D pull request based on feedback (thanks to @dexx7)
        2. Continuing the ongoing work on next features to support integrators (class D, central fees, sendmany etc)
    • Adam
      1. Omniwallet
        1. Handling support
        2. Worked with marv to improve db queries and speed up wallet load time
        3. Looking into multisig/hardware wallets support
        4. Looking at manage issuance/management
    • Sean
      1. bitcoinj-addons v0.2.3 due later this week
        1. Dependency updates only (some are important)
      2. OmniJ v0.5.1 due later this week
        1. Dependency updates
        2. Bug fixes and ecosystem compatibility updates
        3. Omniwallet REST client improvements (for OmniPortfolio, etc)
      3. OmniPortfolio v0.1.2 due next week
        1. Dependency updates
        2. Omniwallet balance query performance improvement
    • Patrick
      1. Assessing a new opportunity that would bring resources to the platform

    By,

    Adam



  • Omni layer State of the Layer: All Hands – May 30 2017

    1. Craig
      1. Traveling
    2. Zathras
      1. Omni Explorer:
        1. Fixed a bug with reorg protection that allowed a transaction to be entered twice in the database if the reorg occurred while the engine was not in sleep mode (eg while it was actively parsing)
        2. Updated the engine to improve handling of pending transactions (a new cache for transactions that are not yet in a block avoids burning compute resources by repeatedly reprocessing pending transactions over and over)
        3. Updated the engine to add additional locks & an extra temp table to hold processed blocks (avoids race condition that in rare circumstances may allow the API to return an apparently empty block when there are in fact Omni transactions in it)
      2. Omni Core:
        1. Fixed a number of bugs in the QT UI for v0.2 (https://github.com/OmniLayer/omnicore/pull/471https://github.com/OmniLayer/omnicore/pull/470)
    3. Dexx
      1. Reviewed Class D pull request: https://github.com/OmniLayer/o...
      2. Reviewed final pieces for the Qt UI: https://github.com/OmniLayer/o...
      3. Hardcoded activations up to block 438500: https://github.com/OmniLayer/o...
      4. Locked fetching and processing inputs while parsing: https://github.com/OmniLayer/o...
      5. Removed sigops workaround for wallet transactions: https://github.com/OmniLayer/o...
      6. Finalized Omni Core 0.2 release notes: https://github.com/OmniLayer/o...
      7. Created tutorial for creating raw Omni sends: https://gist.github.com/dexX7/...
    4. Adam
      1. Omniwallet
        1. Handling support
        2. Looking into multisig/hardware wallets support
        3. Looking at manage issuance/management
    5. Sean
      1. Bitcoinj-addons
        1. v0.2.3 released (CHANGELOG)
        2. Started work on v0.2.4-SNAPSHOT
      2. OmniJ
        1. v0.5.1 released (CHANGELOG)
        2. Started work on v0.5.2-SNAPSHOT
      3. OmniPortfolio
        1. 0.1.2-rc-1 released (privately, on Slack)
        2. Waiting for Omniwallet Bitcoin balance fetching improvements for 0.1.2 final release
        3. Ongoing improvements

    by,

    Adam



  • Omni core Release v0.2.0

    downlaod:



  • Omni core Release 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/issuesOmni Core v0.2.0

  • Upgrading and downgradingHow to upgrade
  • DowngradingCompatibility with Bitcoin Core
  • Imported changes and notesUpgrade to Bitcoin Core 0.13.2
  • Important transaction fee behavior changesAPI changes
  • New project versioning schemeNew project branch structure
  • Consensus affecting changesFee distribution system on the Distributed Exchange
  • Send to Owners cross property suportNotable changes
    • Avoid selection of uneconomic UTXO during transaction creationPerformance improvements during initial parsing
    • New checkpoints and seed blocks up to block 460,000Easy access to specific consensus hashes when parsing
    • Various bug fixes and improvementsChange log
    • CreditsRelease notes for Bitcoin Core 0.11.0
    • Release notes for Bitcoin Core 0.11.1Release notes for Bitcoin Core 0.11.2
    • Release notes for Bitcoin Core 0.12.0Release notes for Bitcoin Core 0.12.1
    • Release notes for Bitcoin Core 0.13.0Release notes for Bitcoin Core 0.13.1
    • Release notes for Bitcoin Core 0.13.2omni_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 masterdevelop branch. This provides a cleaner seperation of source code.

      Consensus affecting changes

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

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

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

      Fee distribution system on the Distributed Exchange

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

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

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

      See also fee system JSON-RPC API documentation.

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

      Send To Owners cross property support

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

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

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

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

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

      FieldTypeExample
      Transaction version16-bit unsigned65535
      Transaction type16-bit unsigned65534
      Tokens to transfer32-bit unsigned6
      Amount to transfer64-bit signed700009
      Token holders to distribute to32-bit unsigned23

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

      Notable changes

      Avoid selection of uneconomic UTXO during transaction creation

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

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

      Performance improvements during initial parsing

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

      New checkpoints and seed blocks up to block 460,000

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

      Easy access to specific consensus hashes when parsing

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

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

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

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

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

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

      Various bug fixes and improvements

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

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

      Change log

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

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

      Credits

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

      Download :https://github.com/OmniLayer/o...



  • Omni layer (Omni) Pre-Release omnij v0.5.3

    CHANGELOG: https://github.com/OmniLayer/O...

    Binaries are available on Bintray: https://bintray.com/omni/maven...


    Download:



  • Omni core (Omni) Release Wallet 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/o...

    Table of contents

    Upgrading and downgrading

    How to upgrade

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

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

    Downgrading

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

    Compatibility with Bitcoin Core

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

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

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

    Consensus affecting changes

    Freezing tokens for managed properties

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

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

    See also JSON-RPC API documentation.

    Notable changes

    Various bug fixes and improvements

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

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

    Change log

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

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

    Credits

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

    Download:

    https://github.com/OmniLayer/o...



  • State of the Layer: All Hands – Dec 19 2017


    1. Craig
      1. With 0.3 release complete need to start circling back up on Digital Objects (UIT/vAtomic )
    2. Adam
      1. Omniwallet
        1. Handling support
      2. Omnicore
        1. Helping with integrators as needed
      3. Planning for 2018 updates for Omni
        1. Increase social presence
        2. Brand awareness
        3. Looking for additional devs
    3. dexx
      1. During the last days, I prepared the 0.3 release with Z, uploaded the binaries, updated the website, sent out the announcements etc. Then I started with some rather large refactor of Omni Core to make it easier to get an understanding which parts are where.
      2. Working on the new website release
        1. Update released Dec 20


  • Omni layer - Community Updates & Project Updates

    Community Updates

    With the beginning of 2018 the Omni Foundation is kicking off the new year with a new attention to community. As our first course to this goal we are going to be holding an AMA on our reddit tomorrow, Jan 25, from 10am – 10pm UTC. We encourage you to join us with your questions about the Omni Protocol, the Foundation and the projects we are working on. We will have a few Team members from different time zones popping in/out throughout the day to respond to questions and discussions on Omni.

    Project Updates

    OmniExplorer.info

    Our block explorer website, OmniExplorer.info, will be undergoing some updates and changes over the next few weeks. The current maintainer of the site is stepping away to focus on more personal matters going forward and will not be able to continue its development. Additional information about the re-release of the new explorer will follow in the coming weeks.

    Omnicore

    Our reference client is now on version 0.3.0. There are many new features (both client side and protocol side) that we are working on and want to get released to the community this year. As with most projects development and accurate testing are a huge factor when it comes to releasing anything new. To that end we are currently looking for additional c++ developers familiar with bitcoin technology who would like to participate in and contribute to the project.  Any interested applicants can contact [email protected]

    Omniwallet

    Omniwallet continues on as usual. Once the OmniExplorer project is complete we hope to begin working on some much needed updates and improvements to streamline and improve the ease the use for most new comers.



  • Omni - State of the Layer: All Hands – Mar 13 2018


    Community

    After nearly a month of dedicated work we are pleased to provide this months update.  As promised our initial 2018 roadmap is now complete and available below. Along with this we are also excited to announce updates for several of our hosted projects.

    Want to engage more with Omni?

    Check us out on Reddit Telegram, and Twitter.

    Project Updates

    OmniExplorer

    The first phase of the redesigned Omni Explorer is now complete and in final review/testing. We anticipate it should be ready for release tomorrow. Built on react boilerplate this is a ground up rebuild. Designed to have a minimal initial load, data is loaded from our api server as needed. The next phase will finish the majority of the ‘coming soon’ placeholders. But for now the core dataset (address balances, history, transaction details, and property information) is available. Here is a little sneak peak of what to expect with the release:

    Teaser

    OmniAPI

    Now operational, our hosted api service is feeding data to the newly redesigned OmniExplorer. Over the next several days we will be updating and documenting available routes, endpoints and example calls to provide integrators with initial access to protocol data.

    Omniwallet/OmniEngine

    In preparation for the new explorer, our backend parser (omniEngine) has been updated and now supports unconfirmed/pending network transactions. This data is accessible and usable by both the new api server as well as Omniwallet. Users should notice pending transaction data a little more quickly now within wallets when receiving transactions from outside services.

    Omnicore

    As previously stated we are currently looking for additional c++ developers familiar with bitcoin technology who would like to participate in and contribute to the project.  Any interested applicants can contact [email protected]

    Roadmap:
    • Omni Core
      • Fees distributed to Omni holders from decentralized exchange
        • Decentralized trades not involving Omni are subject to a 0.05 % fee
        • This fee is distributed to all Omni holders
      • Optimizing transaction size
        • Shorter marker
        • Merging version and type fields
        • Using LEB128 to compress numbers
      • Non-fungible tokens
        • Creating, managing and sending uniquely identifiable tokens
      • Send-to-many transactions
        • Allows to bundle transactions
        • Requested by and very useful for exchanges
      • Crowdsales supporting bitcoin
        • Currently only tokens can be collected
        • Opens the road for native bitcoin based ICOs
      • Updating the architecture of Omni Core
        • Useful for thin clients
        • Paves the way for verification with VerSum or similar
    • Omni API
      • Update api documentation
      • Improve/add
        • Exchange information
        • Statistics and usage information
    • OmniExplorer
      • Refine UI/Styling
      • Improve Mobile design/rendering/size
      • Evaluate reporting/graphing/statistics/info options
    • OmniWallet
      • Refactor to use new OmniAPI
      • Enable better portability/usability in stand alone configurations
      • HD address/wallet support with recovery phrase
      • Hardware wallet integrations
    • Other items
      • Possible Electrum integration
        • Show token balances
        • Create and transfer tokens


  • Looks like your connection to Cryptocentral was lost, please wait while we try to reconnect.