One of the benefits of being the oldest “Bitcoin 2.0” project is that we get to use our foundation of highly secure atomic transactions to then place some of the amazing work in smart contracts and distributed IT on that foundation. Eris Industries recently released their ErisDB and I really like it. It plugs into Tendermint’s blockchain consensus protocol to roll an insta-chain based on what could be described as proof-of-stake taken to logical maturity with a bonding requirement for transaction noding, what I call proof-of-bond. Tendermint allows any amount of chains with a minimum of 4 bonded verification parties to achieve Byzantine Fault Tolerance. ErisDB utilizes Docker to distribute application-logic code that is able to define the permissions of writing to your Tendermint blockchain du jour. Then it allows you to plug in a smart contract based in Solidity (Ethereum’s baby, since adopted by Counterparty, and then Eris, and now us). So now you can hardcode these logics based on blockchain events to give permissions to write to your Tendermint blockchain. 


Why am I shilling so hard for “competing” projects? Because this isn’t a Highschool Football team, this is technology, sometimes tech can be complementary. I have been looking at using Omnicore RPCs in conjunction with Node.js apps hosted on a VPS, not too complex. Problem is, that’s no dApp, that’s just an app, but now a bunch of projects are making it possible to easily do p2p blockchain-ified meta-web of things and glaiven.

Frink

No ETH or XCP required to execute computer programs in a decentralized way.

Consider the possibilities for combining ErisDB and Omnicore. You’ve got your Bitcoin blockchain with the Omnilayer Dex for monetary settlement and hedging. You’ve got your ErisDB writing to a Tendermint Chain as sort of the console-event-log of your dApp as a blockchain. Got that? Then the two chains can reference each other.

Tendermint requires some kind of bonded collateral as the basis for qualifying a node to stake changes. Therefore if you want your app to support multi-party transactions, there’s a couple ways to get that collateral on your local chain. The first way is to reference a balance on the Bitcoin blockchain, ideally that balance is locked by assurance contract in bitcoind, or as we have built, a move to “Reserve” status in Omnicore, a title reserved for balance used in limit orders, pending confirmation transactions, and futures contract margin. It should be possible for a Tendermint chain to write an issuance of $1000 for instance, by referencing an Omni balance that has 300 OMNI hedged at around $3.33 each. The ErisDB logic for writing Tendermint transactions can be tied to the known parameters of the lock used in Omnilayer. For the sake of fairness, you can do locks directly in bitcoind and MirrorX is working on that.

Now that you’ve got your bonding stake, you can participate in verifying the Tendermint transactions executed in accordance with the ErisDB logic to read/write, and smart contracts that codify such logic in a functionally guaranteed way. However, ideally logics should be factored out as much as possible to the overall flow model of your multi-blockchain application. Don’t worry that this seems complex, it’s just the plumbing that makes a trustless autonomous application possible to spawn and operate in perpetuity independent of its publisher.

Let’s consider how you could do the converse, have something written in the Tendermint chain parsed by an Omnicore node with the right script settings switched on, and then summarily have a pre-signed transaction template executed when the pre-defined conditions are heard from the Tendermint chain. The contents of the Tmint chain could also parameterize the contingent transaction signature. That transaction could:

– Issue something new with parameters.

– Issue more of something existent.

– Redeem something.

– Buy or sell something.

– Pay a dividend.

– Use a reserved balance that is thusly earmarked in an Omnicore transaction to make a payment to somewhere or a set of somewheres.

– To the extent that ErisDB is recording an ID registry with associated Bitcoin addresses, pay specific someones.

c8792b51b7633228418ae6a5664bd1bb1973a3d3be14fb824ef20cde7d5beec6

This would be all the smart contract layer Omnicore needs to do everything anyone else can do. But you’re doing it with Omnilayer, so it will be fast to plug-in for you and rock solid money movement for your users. Think of it like a wrapper framework.  

Now, I like to ask myself often, “how could this awesome thing I want to build but everyone better at software engineering than me is busy not building, be built by me?”   

Which brings me to the prototype of the decentralized banking system and futures contract that I am building for the Citi Mobile Challenge using these technologies.

I’ve got a busy month ahead as we launch the Omni Dex. Maybe I will not get to the futures contract and lean on OkCoin instead. Maybe I will not get to the more full decentralization of the app-layer logic and lean on simple Node.js running on my own server. Maybe the prototype has a private key dangerously rubber-stamping in the bowels of an Omnicore node running on such a server, lacking the implementation of the wrapper proposed above. We’ll see, but here’s how I’d build the world’s first production decentralized futures contract:

  1. Create pairs of smart properties as flexible issue, one is the short-side counterpart to the other. So for example I do two tx 54s that give me long and short OMNI/BTC contracts.
  2. I create two templates of an issuance and redemption transaction and set up the robo-signage in Omnicore.
  3. I use either a Omnicore-outside-blockchain wrapper (scaleable solution) or just Node logic running my side to parse for a Tendermint blockchain of a given signature.
  4. Fire up a Docker instance running ErisDB with a few smart contracts for writing what transactions to broadcast for Omnicore in the Tendermint whose defining handle I have passed to my node.
  5. The smart contract logic has to do with writing into the Tendermint chain every time there is a transaction for one or both of the two “contract” smart property tokens representing long and short positions. This records an index of trades in quantity at price P, time T*, with the nature of the trade (Both contracts opened, long opened/short closed, short opened/long closed, both contracts closed).
  6. The Omnicore uses the nature of the trade to write “grant” or “revoke” N contracts to the balances in question, based on a netting logic. The only thing that must be added to Omnicore then is, at a minimum, an integer parameter for a smart property that is 0 OMNI by default and asks how much OMNI does this smart property lock in Reserve balance per unit of the smart property. An optional parameter to specify another collateral type is viable, e.g. “USDT” for Tether-dollar collateralized contracts.
  7. The confirmed changes in balance record another index entry on Tendermint chain indicating the trade was not spoofed.
  8. Come a certain block height on the Bitcoin chain, a settlement algorithm works at the ErisDB logic level, parsing the Tendermint Index and triggering settlement events when it does. The ultimate settlement event goes through the chain, does the formula against the prices, nets everything, and posts the settlement roster on the Tmint chain.
  9. Omnicore has a batch simple-send filled in per the parse of the other chain’s settlement block.

That wasn’t even 10 steps.

*(Tendermint goes down to very short timescales, so a contract with enough leverage for reserving Omnilayer balances can potentially be high-frequency traded, just not ultra because the Omni collateral needs some confirmations to settle. This is the role I originally envisioned for Factom.)  
I won’t bore you with enumerating the rest of the dbanking function built off of the futures contracts, but it seems likely to be workable in this architecture.

State of the Layer: All Hands – Aug 25 2015

  • Patrick
    1. Co-ordinating re-brand with Polo, Masterxchange et al.
    2. Pitched dbanking to a bunch of LatAm bankers, mixed responses, but interesting to discuss!
    3. Came up the model to extend Omnicore functionality to ErisDB/Tendermint app layer, could allow rapid prototype of dfutuers and dbank as soon as early October.
    4. Beginning liquidity operations in the next week
    5. Set up website for testing
    6. Established our system d Marketing/Endowment strategy (Impact Bonds)
  • Sean
    1. OmniLayer Github Pages Site
      1. Incremental improvements
        1. See commits on source branch
      2. Conversations with Dexx about docs from Core
      3. Omni Core Issue #191
      4. Goal is to replace WIX site and incorporate documentation from all subprojects.
    2. OmniJ
      1. Upgrade to Gradle 2.6
    3. Consulting
  • Zathras and Dexx
    1. Executing roadmap toward launch

Previous State of the Layer Post: Aug 18 2015

State of the Layer: All Hands – Aug 25 2015

State of the Layer: All Hands – Aug 18 2015

  • Craig
    1. Omni Wallet Desktop release prep:
      1. Feature activation messages testing
      2. Omnicore build feedback and enhancements
      3. Multisig RPC utility (using Joshsoccer9’s use case)
      4. Omni Core testing guide to subreddit and blog
      5. https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/metadextestingguide.md
      6. Crowdsourced testing – Patrick?
      7. 0.0.10 RPC documentation: https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/src/omnicore/doc/rpc-api.md
    2. Additional protocol enhancements forthcoming
      1. Send All function (proposed by Ambisafe)
      2. Asset dependency and interaction (coming!)
  • Adam
    1. Omniwallet
      1. Continuing to handling support / monitor updates from last week
    2. p2sh scripts
      1. testing minor tweak for lazooz guys
    3. Consulting with 3rd party integrators
  • Marv
    1. sync’ed testdb, then got an error (disk read error?) and have to resync
  • Patrick
    1. Did LTB and Trace Mayer apperances
    2. Dex phase 3 – should we jump straight to an open Dex and set OMNI as the receipient of send-to-owner transactions from the exodus adderss which would receive fees on the Dex
    3. Testing program must be organized (reward verification scheme and distribution formula)
    4. MSC -> OMNI Re-brand must be implemented now.
    5. I talked up the liquidity aspect a lot on LTB so I must get some basic interactivity with RPC working in the next week, among other deadlines
  • Sean
    1. OmniJ
      1. Refactoring of number and enum classes. (reviewed by Dexx)
      2. Use OmniDivisble and OmniIndivisible classes in a few places (reviewed by Dex)
      3. Still working on publishing JARs to repo…
    2. bitcoinj-addons
      1. Move some Spock tests of bitcoinj over from OmniJ repo.
    3. Github Pages site
      1. Conversations about improving Omni’s web presence
    4. Consulting
  • Zathras
    1. Omni Core:
      1. Reviewing & testing much fantastic work from @dexX7, lots of great content including unconfirmed RPC support
      2. Added consensus checkpoint for 370,000
      3. Added new seedblocks list up to 370,000
      4. Few more bugfixes
      5. Rewritten alerting system fundamentally complete, few final minor tweaks
    2. Omni Chest:
      1. Continuing work on v6
      2. Testing various new API approaches
      3. Work on “API in a box” concept for AWS

Previous State of the Layer Post: Aug 11 2015

State of the Layer: All Hands – Aug 18 2015

State of the Layer: All Hands – Aug 11 2015

  • Craig
    1. Omni Wallet Desktop release prep:
      1. Feature activation messages testing
      2. Omnicore build feedback and enhancements
      3. Multisig RPC utility (using Joshsoccer9’s use case)
      4. Omni Core testing guide to subreddit and blog
      5. https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/metadextestingguide.md
      6. Crowdsourced testing?
      7. 0.0.10 RPC documentation: https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/src/omnicore/doc/rpc-api.md
    2. Additional protocol enhancements forthcoming
      1. Send All function (proposed by Ambisafe)
      2. Asset dependency and interaction (coming!)
  • Adam
    1. Omniwallet
      1. Continuing to handling support / monitor updates from last week
    2. Consulting
  • Marv
    1. Omniwallet
      1. a couple user support issues
    2. Omnichest.info
      1. menu bar items disappear in narrow width window
    3. Omnicore testing
      1. failed during initialization – likely due to Clamxav
  • Patrick
    1. Found Node Package for Python wrapping:https://www.npmjs.com/package/python – will use the existing Python implementation of RPC through this wrapper.
    2. Mustapha got very good survey feedback, need to compile with projections to begin crowdsale for Sierra Leone Liberty Group.
    3. Going to promote beta program this week plus do algo testing.
    4. Next week will get basic Dex liquidty live with some of the OMNI warchest.
    5. Metaliquid launching on Huobi/Okcoin, Bitmex/Polo (ether trading) over coming weeks
    6. Doing a panel in Miami with two other awesome people, representing digital dollars using 2.0 protocols and smart contracts.
  • Sean
    1. bitcoinj-addons
      1. README improvements (feedback from Dexx)
      2. Refactored to multi-project build (in prep for moving RPC client from OmniJ)
      3. Gradle scripts for publishing binaries (JARs) to Bintray.com
    2. OmniJ
      1. Started on Omni transaction parsing (previously OmniJ only had Tx building) — see Issue #94
      2. Other maintenance (including PR #93 from Dexx)
      3. Publishing JARs to Bintray.com/Omni any day now (using same code as in bitcoinj-addons)
    3. Consulting
  • Zathras
    1. Primarily focused on OmniChest.info:
      1. Further work on v6
      2. New API services delivered
      3. Migrated to new infrastructure (new servers)
      4. Performance management (problems caused by overusage of API by integrators)
    2. Omni Core:
      1. WIP Feature activation modifications to support client version in message
      2. WIP First draft of new alerting system supporting multiple alerts & feature activation

Previous State of the Layer Post: Aug 4 2015

State of the Layer: All Hands – Aug 11 2015

State of the Layer: All Hands – Aug 4 2015

  • Craig
    1. Board meeting to discuss a number of open items
      1. was scheduled for last Thursday, delayed
    2. Omni Wallet Desktop release prep:
      1. Feature activation messages testing
      2. Omnicore build feedback and enhancements
      3. Multisig RPC utility (using Joshsoccer9’s use case)
      4. Omni Core testing guide to subreddit and blog
      5. https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/metadextestingguide.md
      6. I want us to have a public release candidate build by this meeting next week.
    3. Additional protocol enhancements forthcoming
      1. Send All function (proposed by Ambisafe)
      2. Asset dependency and interaction (coming!)
  • Adam
    1. Omniwallet
      1. Continuing to handling support / monitor updates from last week
    2. Working with Sean to setup omnilayer.github.io
  • Marv
    1. http://www.dfs.ny.gov/legal/regulations/adoptions/dfsp200t.pdf
    2. staging.omniwallet.org – balance check just says “Loading…”
  • Patrick
    1. Looking at Crowdsourced Testing budget  and PR help via board budget to support launch
    2. Did a bunch of work for the Dev allocation bounties, plan for the market maker. Had some scheduling conflicts that lead to serial meeting reschedulings but we’ll come to quorum soon.
    3. Re-factored my trading app, now properly object-oriented and extensible.
    4. Got full websockets integration working, 200x performance increase.
    5. May be able to get some RPC calls integrated by next week for testing.
  • Sean
    1. OmniJ
      1. Send All transaction tests merged in (Dexx)
      2. Started OmniJ dev guide with UML class diagram of RPC clients
    2. bitcoinj-addons
      1. Published bitcoinj-addons repo with start of RPC server app
      2. Planning to migrate bitcoin-only RPC client classes from OmniJ to this repo.
    3. omnilayer.github.io statically-generated site.
      1. Proof-of-concept Github pages site with help from Adam
      2. Source is AsciiDoctor markdown, though Github markdown also supported.
      3. About page describing site
      4. Future home for tech documentation or replace www.omnilayer.org
      5. List of open issues in Github project
  • Zathras
    1. DexX’s work on consensus parameter classes finalized & merged
    2. New transaction type “Send All” implemented, awaiting spec finalization
    3. Feature activation by message completed and merged
    4. Further updates to Omnichest in preparation for v6

Previous State of the Layer Post: July 28 2015

State of the Layer: All Hands – Aug 4 2015

State of the Layer: All Hands – July 28 2015

  • Craig
    1. Board meeting to discuss a number of open items
      1. we still need a “foundation owned” P2SH address which the foundation can use to sign messages to activate features
    2. Feature activation messages
    3. Omnicore build feedback
    4. Multisig RPC utility (using Joshsoccer9’s use case)
    5. Publishing the Omni Core testing guide to subreddit and blog
      1. https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/metadextestingguide.md
  • Adam
    1. Omniwallet
      1. Continuing to handling support / monitor updates from last week
      2. staging login fixed
  • Marv
    1. Omnicore-Qt
      1. several failed attempts to initialize on OSX 10.10.4 latest: https://github.com/OmniLayer/omnicore/issues/151
    2. Omniwallet
      1. found staging login problem
  • Patrick
    1. Moving forward with Sierra Leone survey
    2. Updated model of Omni valuation with a Foundation-backed MM fund
    3. Created some requirement documents for MSC Board to lay out bounties
    4. Will be speaking at Payments Latin America again in Miami on the 24th/25th, highlighting Tether, Factom, dBanking w/ Omni and other tools to bank execs
  • Sean
    1. Continue to be focused on consulting projects
    2. Working on Omni transaction signing in OmniJ (Issue #78, PR #86, etc)
  • Zathras
    1. New consensus hashing system implemented & merged
    2. New checkpointing system implemented & merged
    3. Seed block filtering system finalized & merged
    4. New Preview builds with latest fixes and testnet restrictions fixed uploaded
    5. Initial MetaDEx guide published
    6. Further Omnichest.info work towards v6
    7. Further Omnichest.info API additions for JSON support of tx retrieval

Previous State of the Layer Post: July 21 2015

State of the Layer: All Hands – July 28 2015

State of the Layer: All Hands – July 21 2015

  • Craig
    1. 0.0.9.99-dev has been shared with the team for testing, report issues to: https://github.com/OmniLayer/omnicore/issues
      1. any major issues to discuss?
    2. TMSC consensus issue (raised by Sean): https://github.com/OmniLayer/omnicore/issues/134
      1. issue has been closed, as the consensus issue was to be expected, is now ignored
    3. we need a “foundation owned” P2SH address which the foundation can use to sign messages to activate features
      1. each foundation board member perhaps each has one key for the multisig (should Exodus be one of these?)
      2. also, who has access to sign the builds for distribution?
  • Adam
    1. Omniwallet
      1. Continuing to handling support / monitor updates from last week
    2. github
      1. private repos cleaned up
      2. plan downgraded to free
    3. Announcements mailing list
      1. announcement sent last week about omnicore 0.0.9.2
    4. Continuing cleanup of internal services
  • Patrick
    1. Experimenting with instancing websocket servers to propagate trade data
    2. First round of bounty requirements
    3. Almost ready to integrate Omnicore
  • Sean
    1. Focused on consulting projects last week
  • Zathras
    1. Further work on feature activation by message for Omni Core
    2. OmniChest v6 development for MetaDEx and v0.0.10 features
    3. Minor bugfixes for Omni Core

Previous State of the Layer Post:

July 14 2015

State of the Layer: All Hands – July 21 2015