Omni layer Updated Details

  • About Omni

    Omni is a platform for creating and trading custom digital assets and currencies. It is a software layer built on top of the most popular, most audited, most secure blockchain -- Bitcoin. Omni transactions are Bitcoin transactions that enable next-generation features on the Bitcoin Blockchain. Our reference implementation, Omni Core is an enhanced Bitcoin Core that provides all the features of Bitcoin as well as advanced Omni Layer features.

    • Easily create custom currencies and assets directly on the Bitcoin Blockchain
    • Blockchain-based crowdfunding
    • Trade assets peer-to-peer on the Blockchain
    • Easy to use, secure web wallets available
    • Fully-validating desktop wallet and client based on Bitcoin Qt
    • Easy to integrate server daemon based on Bitcoin Core
    • Over 10M USD in asset market cap on the layer as of Feb '16
    • Integrated with top Bitcoin and Alt-coin Exchanges
    • Tether Dollars backed by Bank Trust, redeemable for SWIFT at and

    Start with a web application or a software download


    Free, hosted Web Wallet

    · You control your private key

    · Send & receive Bitcoin & Omni assets

    · Create assets, launch crowdsales, & trade on the distributed exchange.


    · Omni Blockchain Explorer

    · View Omni transactions on the Bitcoin Network

    · Lookup Omni asset (smart property) information

    · View asset trading on the Distributed EXchange (DEX)

    Omni Core:

    · Fully-validating Desktop Wallet

    · A superset of Bitcoin-Qt

    · Mac, Windows, and Linux

    · Native, cross-platform user interface

    · Peer-to-peer Distributed Exchange Trading


    · Omni Core server daemon, with RPC interface

    · A superset of bitcoind

    · Mac, Windows, and Linux

    · Omni protocol Reference implementation

    · Used by leading cryptocurrency exchanges

    Github Projects

    Omni Protocol Specification

    The Specification for the Omni Layer Protocol.

    Omni Core

    The Omni reference implementation. A C++ superset of Bitcoin Core.


    Hosted wallet server (Python) with AngularJS front-end.


    Java/JVM Omni Client


    Node.js-based JSON-RPC client for Omni Core.


    Visit the OmniLayer organization on Github to see other projects.


    Read the Omni Team Blog:

    Argue with us on Reddit:

    Join our Facebook group:

    Follow us on Twitter:


    Holy Transaction

    Universal cryptocurrency wallet with instant exchange

    Enterprise Blockchain Software

  • State of the Layer: All Hands – Nov 8 2016

    • Craig
      1. DEx activation
        1. OmniWallet readiness
    • Adam
      1. Omniwallet
        1. Continuing to handle support
        2. Continuing to work on staging updates/fixes
    • Patrick
      1. Multiple articles for press placements
      2. Polishing
      3. Lost some days to bureaucracy
      4. Finishing up tutorials
      5. Calls with promising new issuers – need to review strategy with multisig
      6. Scripting work to test fees on testnet, need proper activation on testnet to employ the script
    • Marv
      1. Omniwallet
        1. User support
        2. OmniDex testing
    • dexx
      1. Updated version and release notes to prepare Omni Core v0.0.11.2
      2. Tagged, built and verified Omni Core v0.0.11.2:
      3. Automated testing of 0.13 port is green, the port is 95 % complete:
      4. Discussed the way forward for fee system with zathras
    • Zathras
      1. General:
        1. Resolved out of space issue on partner Omni Core instance
        2. Renewed domain name for another year, will redirect to
        3. General discussion various topics (fees/MDEx) / transaction testing
      2. Omni Core:
        1. Ran Gitian build process to generate binaries for (
        2. Fixed several bugs with the fee system ( – thanks dexx7!)
        3. Looking at crash recovery – simulating segfaults issue seems to be with SP watermark rollback, investigating further
        4. Testing variable ints, have a prototype encoder/decoder. Using existing main ecosystem payloads to test with:
          1. Total history of 107,610 Simple Send transaction payloads. If sent:
            1. Using standard Class C Payloads: 1,721,776 bytes
            2. Using Compressed Class D Payloads: 731,172 bytes
            3. Savings: 990,604 bytes (42.47% of standard size / 57.53% reduction)
          2. Total history of 816 Trade transaction payloads. If sent:
            1. Using standard Class C Payloads: 22,876 bytes
            2. Using Compressed Class D Payloads: 14,668 bytes
            3. Savings: 8,208 bytes (64.12% of standard size / 35.88% reduction)
        5. Ported old stale Auditor branch to and fixed up the bugs introduced by the port (
        6. Investigating possibility of a safe-mode
    • Sean
      1. bitcoinj-addons 0.2.1 released (RPC client now tested and working on Android)
      2. Namecoin SPV lookup beta released that uses bitcoinj-addons
      3. OmniJ
        1. More changes for Bitcoin 0.13 port of Omni Core
        2. Migration from _MP to omni_ method names (Issue #121)
    • Judith
      1. Ongoing Communication with projects
      2. Preparing for Hackathon

  • State of the Layer: All Hands – Nov 15 2016

    • Adam
      1. Omniwallet
        1. Continuing to handle support
        2. Continuing to work on staging updates/fixes
    • Patrick
      1. Omniwallet testing/tickets
      2. In a historic week of chaotic global consciousness, tapped into meme-machine to produce 4 excellent press pieces, two for Bitcoin press, two for mainstream, and we’re talking top-tier mainstream outlets. It’s gonna be lit.
      3. Working on multisig tutorial based on revised RPCs
      4. Testnet activation for cross-property STO and fees to run my scripts and gen the data we need to confidently sign off on activating those.
    • Marv
      1. Omniwallet
        1. User support
        2. OmniDex testing, UI design w/ Adam
    • dexx
      1. Ported remaining unit tests and raw transaction API for 0.13 port – it’s basically feature complete
      2. Reviewed and merged fee system fix from Zathras for
      3. Hardcoded activations for all recent features on testnet for – it’s ready for new tag + binaries
    • Zathras
        1. Fixed sender/receiver transposed on DEx v1 purchase (thanks Marv)
        2. Fixed server error when trade is invalid (thanks Adam/Marv)
        3. Fixed server error when trade is unconfirmed (thanks Patrick)
        4. Fixed missed trade matches when tradee is filled immediately
        5. Fixed display bug showing 100% sold for invalid trades
        6. Clarified some wording
      2. Omni Core
        1. Submitted Safe mode code (Feature Deactivation)
    • Sean
      1. OmniJ 0.5.0 later today (removing support for Omni Core pre
      2. Draft OLEs coming tomorrow
        1. OLE-001 Omni Layer Enhancements Overview
        2. OLE-002 Omni Layer Enhancements Process (based on BIP process)
      3. General support and advising

  • State of the Layer: All Hands – Nov 22 2016

    • Craig
      1. Sponsorship update (CoreTech)
      2. Experimental financial products
      3. Omniwallet status
      4. Litecoin client
      5. Press releases
      6. Identity
    • Adam
      1. Omniwallet
        1. Continuing to handle support
        2. Continuing to work on staging updates/fixes
          1. Only major bug left is chart display
          2. Need feedback from everyone to ensure no other bugs/stopping points
    • Patrick
      1. Multisig Tutorial
      2. Important Business Development – 3 really good projects
      3. Work on OmniArb.js
      4. Preparing affiliate marketing efforts for Omni assets
    • Marv
      1. Omniwallet
        1. User support
        2. OmniDex testing, UI design w/ Adam
      2. Omniexplorer
        1. A few feature requests, bug reports
    • dexx
      1. Tagged, built and released Omni Core v0.0.11.2:
      2. Will publish 0.13 port with latest additions and rebased on top of 0.13.1 soon
    • Zathras
      1. Omni Core:
        1. Submitted PR to change the number of signatories for emergency deactivations to 3 (
        2. Generated binaries via Gitian for (
        3. Ongoing work on Class D (variable length integers) for smaller transactions
      2. Omni Explorer:
        1. Fixed some ‘could not reliably determine trade status’ errors for trades before All-Pairs went live
        2. Fixed new engine crash bug on unconfirmed trades in mempool
        3. Added breakdown of token reserved balances when looking up addresses (feature request from @marv)
        4. Upgraded daemon to Omni Core
        5. Back-ported old MasterChest RequestStat API to OE for backwards compat when domain redirected to OE IP next week
    • Sean
      1. OmniJ 0.5.0 released (turned out to be a bit more work than expected)
      2. Working on OLEs today.
    • Judith
      1. Ongoing Communication with projects
      2. Preparing for Hackathon

  • State of the Layer: All Hands – Nov 29 2016

  • Omniwallet Updates, OmniDex Trading Interface Launched

    Just in time for the Holidays Omniwallet is pleased to present several updates, overhauls and the OminDex. The OmniDex interface ties in with the recently activated functionality on the Omni Protocol and now allows a completely decentralized interface for users to Trade Any Omni Issued Asset for any other Omni Issued Asset.User Offers are automatically matched against any existing open offer at the corresponding rate. Additionally, if you don’t see an offer for a pair you want to sell/buy you can open the new market just as easily by placing the first offer for that pair.Getting started is as simple as navigating to the ‘Exchange’->’OmniDex’ tab in the interface:

    From there you’ll be presented with the option to choose your preferred ‘Market Currency’ and then the existing Markets with open offers will be displayed. A full Getting Started Guide has been added to the knowledge base/wiki.Additional updates and changes include fee estimation, simplified fee configuration, updated and improved websocket library/feeds, auto websocket reconnection and resubscription (No more stale data when something restarts), improved balance feeds, and misc some bug fixes.So get out there and start placing your Offers!

  • State of the Layer: All Hands – Dec 06 2016

    December 7, 2016 Adam

    • Craig
      1. Automated DEx trading
      2. Next releases
    • Adam
      1. Omniwallet
        1. OmniDex Interface launched
        2. Continuing to handle support and feedback from launch
    • Patrick
      1. Trying to test btc spend and fail-safing of Dex trading system
      2. Finishing email automation tool for fulfilling orders of a product through a website (vending machine w/ some KYC)
      3. Final Omniwallet testing last week
      4. Futures contract interviews
      5. Feedback on making Dex phase one open to non-OMNI pairs
      6. Design to automate Dex phase one trading in Omniwallet
    • Marv
      1. Omniwallet
        1. OmniDex launch
        2. Monitoring support
      2. OmniExplorer
        1. Reporting bugs & feature requests
    • dexx
      1. Fixed Travis CI configuration for 0.13 port
      2. Hosted Mac OS X SDK for Travis CI on AWS S3
      3. Fixed restoring of default minRelayTxFee in unit tests, so random test order also works
      4. Bumped version of 0.13 port version to 0.1.99, and updated related tests
    • Zathras
      1. Omni Explorer:
        1. Fixed a crash in MetaDEx market page when the total amount of available tokens overflows an unsigned 32-bit integer (thanks for report Marv!)
        2. Fixed an issue where cancelled trades with no matches would show as 100% sold (thanks for report Marv!)
        3. Working on engine logic problem that results in matched trades being recorded in multiple iterations (causing duplicates) (thanks for report Marv!)
      2. Omni Core:
        1. Working on optimizations, achieved target of sub-10 minute parsing! Improvements include:
          1. For Class B, only prepare an equivalent number of SHA256 hashes to the packet count (rather than MAX_SHA256_OBFUSCATION_TIMES each transaction)
          2. No longer recalculate fee distribution thresholds every block, only when smart property token counts change (eg grant or issuance)
          3. Skip iterating the vector of checkpoints unless we’re actually in a block that is %10000.
          4. Fix the MAX_SEED_BLOCK const that was causing seed blocks >390K to be ignored
          5. Skip actually fetching a property from the SP database when we need to check if it exists (property ID’s are sequential so existence can be inferred from peeking next available property ID)
          6. Wallet cache improvements
          7. Migrate the tally map from std::map to std::unordered_map (this is actually slower at the beginning when we only have a small number of elements, but by about block 300,000 the hashtable lookup of unordered_map starts to see substantial improvements over std::map).
          8. Don’t bother iterating over the outputs again in HandleExodusPurchase if we’re past the Exodus crowdsale & on mainnet
          9. Added model to drop non-Omni transactions faster by comparing bytes in scriptPubKey looking for marker bytes and only examining interesting transactions more closely
    • Sean
      1. OmniPortfolio 0.1.2 coming this week
        1. Update to OmniJ 0.5.0
        2. Use Omniwallet address array balance query (using Omniwallet staging server)
    • Judith
      • Ongoing Communication with projects

  • Multisignature Addresses and Omni

    The only prudent way to do a managed smart property issuance is through a multisignature address. Also, long-term storage of assets held on an institutional level, and institutional operations such as payroll management, may also benefit from using multisignature addresses. Most importantly, it’s essential that exchanges integrating the Omni Layer protocol replicate best practices used by BTC-only exchanges such as BitMex, and have one central multisignature address, or preferably, a series of rolled multisignature addresses.The protocol does not currently support multiple outputs per transaction, this is a feature we want to see in the next version to enable addresses without BTC to pay miner fees to some service that provides the BTC input and is compensated with a second output of equivalent value in smart property. Creating transactions that fulfill customer withdrawals as secondary outputs is not yet possible, so a combination strategy of hot wallets and multisignature repository wallets is recommended for doing a large number of send transactions, for now. For example, an exchange could keep 10% of the assets in a hot wallet that the server controls for fast withdrawals and then re-fill it on a daily basis.It’s also possible to create applications that make the below illustrated process much easier, and even facilitate exciting uses like market places for real goods, with paid arbitrators available to settle disputes with a 3rd key.First, one must safely generate and store private keys and their corresponding public keys. The best way to do this is install Linux on a formatted USB, drop a download of Omnicore on the same USB, wipe a hard drive, and boot from the USB. Load up Omnicore (or Bitcoin Core, for this purpose, it’s the same) and go to Help -> Debug -> Console. Then type:


    Copy the address and paste it in front of the following command:

    validateaddress <address>

    The pubkey will be displayed, write it down, it’s in Hex (base 16) so your hand might get a cramp. Pasting it into an email and having a copy in the cloud is acceptable since pubkeys are not a security vulnerability, and are actually meant to be shared. The other board members or team members, or your accountant, or your spouse, or whomever is going to follow these steps on their own to generate their own private key, will have to share their pubkeys with you in order to generate the multisig address.Now the very important part:dumpprivkey <address>

    Like it says on the tin, this will dump the private key for that address (though it only works if you’ve generated the address locally and it’s saved in that local client). It’s very important that the privkey is written down in analog form, make sure your hand-writing isn’t too bad, that characters that might be confused for another are marked. A private key, being an extremely large number in a very high numerical basis, isn’t so long as a public key, so it ought not inspire a hand cramp. Now it’s time to generate the multisignature address, let’s say you want to create a 2-of-3 address, you’ll do this by specifying the number of signatures needed (2) and listing an array of pubkeys: omnicore-cli createmultisigaddress 2 '["0232b7c756b51c8ad37fa63929d119b118af54598c8a0f1ab8f1966704e4cbff96", "02343986778e78ff014076967c5f49923e3304c43c79e58e82f4119df19833ba8e", "027aa3757d4a869a8e886a4562322a251fe8a7b1c710a8a33f7aad980c9e6e9a3b"]'

    The createmultisigaddress call will return the new address and the redeem script, which like the pubkey, is very long, annoying to physically write down, and not a security risk to share, but necessary to complete transactions. It can be copied to a digital back-up and shared in emails.

    It’s essential that you fund the new address you just created with some bitcoin, it can be a very small amount, but no less than .005 is recommended. Check your transaction hash when you send, you’ll need it later. Now the most technically complex part, and the one specific to Omni Layer transactions – preparing a transaction to be signed. There are a series of RPC calls that begin with “omni_createpayload_”and then are followed by the name of an existing transaction, for example “omni_createpayload_simplesend”, “omni_createpayload_trade”, and “omni_createpayload_issuancemanaged” – the full list can be found here. Issuance of a managed smart property is one of the more parameter-intensive

    transaction types, here is a list:









    the ecosystem to create the tokens in (1 for main ecosystem, 2 for test ecosystem)




    the type of the tokens to create: (1 for indivisible tokens, 2 for divisible tokens)




    an identifier of a predecessor token (use 0 for new tokens)




    a category for the new tokens (can be “”)




    a subcategory for the new tokens (can be “”)




    the name of the new tokens to create




    an URL for further information about the new tokens (can be “”)




    a description for the new tokens (can be “”)

    omnicore-cli omni_createpayload_issuancemanaged 1 2 0 “” “” “myTokens” “” “Experimental multisig tokens.”

    Very important note, OP_Return only allows 76 bytes of data, so your hex payload must be less than 152 characters long, the categories parameters are not worth the text, just name your asset, include the URL and come up with a very succinct 3-5 word description. Longer strings will fail to modify the transaction.

    The resulting hex is what would go into the OP_Return of a Bitcoin protocol transaction that would effectively make it an Omni Layer transaction. You might think that one would then simply have everyone sign that payload.

    But wait, there’s more! We must also create the components of a bitcoin transaction as if we weren’t creating an Omni transaction, with an added bonus of inserting the payload you just create as an OP_Return, and after that we’ll have a proper transaction hash to sign.

    The steps:

    omni_createrawtx_input, then add the payload via
    omni_createrawtx_opreturn, then add the reference address via
    omni_createrawtx_reference, and finally add the change address with

    Now step by step with parameters:

    omnicore-cli “omni_createrawtx_input” “<raw tx hash to modify, we’re creating a new one, but it’s necessary to put in the quotes and leave it blank>” “<the transaction hash of the bitcoin you sent to fund the address earlier>” <the vout position of the output that this input transaction is providing to fund mining fees – an integer, usually 0 or 1>

    Now copy the hash that was just emitted, as well as the Omni Layer transaction payload you created two steps ago, as parameters for the next step:

    omnicore-cli “omni_createrawtx_opreturn” “<modified transaction you just got from the createrawtx_input>” “<hash that is the payload of the Omni transaction you want to put into the OP_return>”

    You’ll get another modified hash representing the new data, now copy that and your multisig address as parameters:

    omnicore-cli “omni_createrawtx_reference” “<the most recent transaction hash you want to build-up>” “<your multisig address>”

    Note that your reference address is only the address you’re sending from if you’re doing an issuance, usually this is the address you want to send tokens to.

    Now finally, we’ll take the resulting transaction hash and add a change address (change as in “spare some change?” not as in “we want change”), which will also be the address you’re transacting from, like a typical Bitcoin transaction.

    omnicore-cli “omni_createrawtx_change” “<latest version of the hash for this transaction you’re building>” “[{\’txid\’: \'<hash of input transaction that funded the address>\’,\’vout\’:<0 if the input you’re spending is first among inputs, 1 if second, ect. – an integer>,\’scriptPubKey\’:\'<3039a5ee506a381271c1a8974eda16457838f249 – should look like this, click the “Scripts and Coinbase” link under “Inputs and Output”in the tx view of and scroll down to the hex ouput corresponding to the output you’ve chosen to spend>\’,\’value\’:<BTC spent in output, an 8 decimal place floating point number, must equal the whole output chosen by vout from the input tx>\’},<other JSON objects representing other input transactions used, where applicable>]” “<your address to receive the change, same as in the previous action>” 0.00035

    The last parameter is an integer for the miner fee paid.

    One tricky thing about this step the JSON has to have “\” in front of every ” or ‘ used in the JSON part, but other JSON sections in, for example, the signrawtransaction call, don’t require this. Just a quirk of the design of the RPCs. If you don’t use the \’s you’ll get an “Error parsing JSON:” response.

    Here’s a really clear example:

    ./omnicore-cli omni_createrawtx_change “0100000001cde12afc42d31cf0dc70ffdda31f11d470d45407790fc487e478223a249228fa0000000000ffffffff031ef579120000000017a314a6eb127dfb988196197f8e2aa1353974b66a2s648700000000000000001b6a14ef7d6e69000000000000007600000006c7c12e10aa0a0000000000001976a0b3e8cab9b8383e121f2dbf77be8fc79″[{\”txid\”: \”b13e92243a22783485c407780724d170d313cfa3ddff70dcf01cd342fc2ae1c\”,\”vout\”:0,\”scriptPubKey\”: \”b264a9ed243dfb686126127e8d1cb1356281d26a278487\”,\”value \”:0.749}]” “3QSYoxGXw5sfHLzMMSsDUgdW45G2W7M8sM2” 0.00025

    There are extra spaces separating : and \ so the blog doesn’t show a:\ emoticon, remove those in practice.
    And now we have a valid transaction to broadcast. Share the hash with your co-signers. They can copy it in along with their private keys using this command:
    <$ omnicore-cli signrawtransaction "0100000001e006a9...f16c9f4af17f8700000000" '[{"txid":"41a76b319ba24cd32fecd85fe234e32aa58c6151d964ca5968b8b41415a906e0", "vout":0, "scriptPubKey":"a9148baa686154e24014b546f3cb5223f16c9f4af17f87", "redeemScript":"52210232b7c756b51c8a...980c9e6e9a3b53ae"}]' '["cQoN38zUcZV9egX8XbMv5B2CPzaAg4ccdVPGxdwbpdy3TPt85eS8"]'

    These parameters are: the transaction hash, a JSON including similar information as the change address call above, but including the redeem script shown when you generated the multisig (which can be saved digitally, as its compromise can’t really be used to compromise the address, but which is necessary to sign transactions on a multisig address). And finally, the private key. Note that the \’ required above is not required for the JSON here, just one of those things. Finally, using the scriptPubKey you can find on will return a “mismatched pubkey” error, the right pubkey is a subtly different looking hex string you can get by decoding the transaction:

     ./omnicore-cli decoderawtransaction "0100000001cde12afc42d31cf0dc70ffdda31f11d470d45407790fc487e478223a249228fa0000000000ffffffff031ef558160000000017a914a9eb247dfb988196197f8e2aa1353974b66a2784870000000000000000166a146f6d6e69000000000000007600000006c7c12e10aa0a0000000000001976a914e8fab7b8383e121f2dbf77be8fc79effec252e7688ac00000000"
     "txid" : "5bef1c94f072317bc14201273eaf1f17a60ca4c97d5586b35333dc7b327b05c6",
     "version" : 1,
     "locktime" : 0,
     "vin" : [
     "txid" : "b13e92243a22783485c407780724d170d313cfa3ddff70dcf01cd342fc2ae1cd",
     "vout" : 0,
     "scriptSig" : {
     "asm" : "",
     "hex" : ""
     "sequence" : 4294967295
     "vout" : [
     "value" : 0.749,
     "n" : 0,
     "scriptPubKey" : {
     "asm" : "OP_HASH160 a9eb247dfb988196197f8e2aa1353974b66a2784 OP_EQUAL",
    ---> "hex" : "b264a9ed243dfb686126127e8d1cb1356281d26a278487",
     "reqSigs" : 1,
     "type" : "scripthash",
     "addresses" : [
     "value" : 0.00000000,
     "n" : 1,
     "scriptPubKey" : {
     "asm" : "OP_RETURN 6f6d6e69000000000000007600000006c7c12e10",
     "hex" : "6a146f6d6e69000000000000007600000006c7c12e10",
     "type" : "nulldata"
     "value" : 0.00002730,
     "n" : 2,
     "scriptPubKey" : {
     "asm" : "OP_DUP OP_HASH160 e8fab7b8383e121f2dbf77be8fc79effec252e76 OP_EQUALVERIFY OP_CHECKSIG",
     "hex" : "62b63ee8fab7b8383e121f2dbf77be8fe19effec252e7688ac",
     "reqSigs" : 1,
     "type" : "pubkeyhash",
     "addresses" : [

    That arrow in the middle of the above block quote shows you where to find the hex you need to properly sign. The one at the bottom is what you’d need to use to sign a successor transaction that takes the output you’re about to produce as an input.

    The result will be transaction you can copy and email to your other co-signers to continue signing. You’ll get a message suggesting an error and see “complete: false” but don’t let this fool, you, that means you did it right. Once the transaction has enough signatures, it will show an output where “complete:true”.

    But before you sign that last transaction, make sure it’s something you’d want to sign with a special version of the decode call:

    /omnicore-cli omni_decodetransaction


    “txid” : “8cda8e91f973717b317426292d8c1637360c12c97d5586b35333dc7b327b05c6”,
    “fee” : “0.00025000”,
    “sendingaddress” : “3QSYoxGXw5sfHLzMMSsDUgdW45G2W7M8sM2”,
    “referenceaddress” : “1J2P7J6yAkPOpVsanJSHx4RrhZqd1fc8dn”,
    “ismine” : false,
    “version” : 0,
    “type_int” : 0,
    “type” : “Simple Send”,
    “propertyid” : 118,
    “divisible” : true,
    “amount” : “291.21130000”,
    “confirmations” : 0

    Once you’re sure you’re good on signing, follow the steps linked above and when complete:true is the result, you can take the resulting hash and do this:

    omnicore-cli sendrawtransaction “<completed, signed transaction hash>”

    If you get an “insufficient priority” error, this is because your miner’s fee is not large enough.

    Also note, the Bitcoin Core RPC “createrawtransaction” will make your fee the different between the input and the output, it doesn’t have all the steps involved here so by default just that call won’t include a change address, so if you try to send 1 bitcoin from an address containing 10, you’ll pay a miner’s fee of 9 BTC and have a bad time.

    The output from sending the raw transaction, assuming no errors occur due to lack of sufficient signatures or fee, will be a transaction id that you’re used to seeing, copy it into a and or and you’ll see the transaction out in the wild, pending confirmation.

    For periodic business operations, weekly or monthly, this is a somewhat tedious process, but once you get the hang of it and have the commands in your SSH history, it’ll be easy. Except, for security reasons you must scrub your bash history after using a private key in the signing transaction, more on that here. It’s considered good security practice to create a new multisignature address prior to using your private keys on the old one, and periodically port funds and control of a smart property to it, limiting the possibility of a compromise over time for a highly re-used set of private keys.

    Just to spell it all out, here’s that transaction:

    Change the issuer on record of the given tokens.
    Name Type Presence Description
    fromaddress string required the address associated with the tokens
    toaddress string required the address to transfer administrative control to
    propertyid number required the identifier of the tokens
    "hash"  // (string) the hex-encoded transaction hash
    $ omnicore-cli "omni_sendchangeissuer" \
        "1ARjWDkZ7kT9fwjPrjcQyvbXDkEySzKHwu" "3HTHRxu3aSDV4deakjC7VmsiUp7c6dfbvs" 3

    It’s possible for co-signers to write down a private key (and it’s important that they do it well, without ambiguity of upper or lower case in their long-hand, maybe a typewriter would be useful) and rarely use it, and for the administrator to use those pubkeys over and over while generating a new key and address each operations cycle.

    It’s worth it to take more time generating keys in an air-gap and signing transactions in the same environment, reduces the risk profile from .00001% down to .00000000001% or some similar approximation of hyper-marginalized risk. Every layer involved is a potential attack vector, which is why the best way to sign a transaction is in an unsync’ed Omnicore QT instance (Help->Debug->Console) on a Linux device that is clean-booted from a recently formatted USB stick and never used to access the internet.

    People talk about air-gaping like it’s hard, but the hardest part is simply allocating a device for it, which should be a trivial line item for a serious operation. Different organizations will find different balances of compromise. Probably the best trade-off would be having a script that takes one private key as a parameter, pasted in fresh before the script runs, to prepare and partially-sign the relevant transactions and output a JSON object listing them along with their decoded parameters, and have it auto-email the CFO or accountant, who then saves it to a .txt file, carries it to the air-gap device on a USB stick, and then copies the long transaction hashes in while signing them manually. Maybe manually decode them again before signing to check for possible man-in-the-middle attacks. Then take a .txt file of those signed transactions, or maybe a .json file, bring it over to the internet-connected computer on the USB stick, and either email it back or submit it to a server to run another script that tries a sendrawtransaction call for each transaction. Hacking your operation should be as challenging as the famous sequence in the first Mission:Impossible film.

    No exchange that requires multiple manual signatures to move assets has yet been hacked.

    If you’re new to server management, see this tutorial.

  • State of the Layer: All Hands – Dec 13 2016

  • State of the Layer: All Hands – Dec 20 2016

    • Craig
      1. Updates for Omni port
      2. Omniwallet fixes for null recipient
      3. DEx volume and automation
      4. DEx tutorial
      5. UIT protocol enhancements
      6. Core.ID discussion / protocol needs
    • Adam
      1. Omniwallet
        1. Continuing to handle support and feedback from launch
        2. Working on fixes for dex 1.0 interface
    • Patrick
      1. Evaluating HTML 5 app design for making multisig easy
      2. Editing on multisig article
      3. Spec draft for futures and options WIP
      4. Business development Re: US stocks transferable between brokerage accounts and blockchain tokens
    • Marv
      1. Omniwallet
        1. User support
    • Zathras
        1. Fixed several API issues preventing successful completion of automated testing (thanks @Sean)
        2. Investigating OE outage caused by Omni Core crash on failed page allocation
      2. Omni Core
        1. Initial works on Omni Core port
        2. Performing further review & tests on fee system
    • Sean
      1. Jenkins CI
        1. Found and helped resolve Omniwallet issue with send-to-self
        2. Updated to use (new URL and API) in tests
        3. Configured to build both stable and integration branches of Omni Core
          1. master branch is built by omnicore-stable job
          2. develop branch is built by omnicore-integration job
          3. Consensus Tests and RegTest Integration Tests run against both builds.
      2. OmniJ
        1. OmniChest classes now use OmniExplorer URL/APIs (may be renamed in future)
        2. Improvements to error handling in Omniwallet client
        3. Still working on multi-address query API update
    • Judith
      • Ongoing Communication with projects

  • State of the Layer: All Hands – Jan -3 2017

    • Craig
      1. CNCERT bug report review
      2. Updates for Omni port
      3. DEx volume and automation
      4. DEx tutorial
      5. UIT protocol enhancements
      6. Core.ID discussion / protocol needs
    • Adam
      1. Omniwallet
        1. Continuing to handle support and feedback from launch
        2. Added new external api lookups
    • dexx
      1. Finalized parts for 0.13 port
      2. Reviewed Zathras’ fee system related pull requests
      3. Prepared porting of 0.13.2 to our code base
    • Zathras
      1. OmniExplorer:
        1. Recovered several outages caused by hung OC daemon
        2. Troubleshooting the engine to determine failure causes
      2. Omni Core:
        1. Fixed a bug where properties with under 100,000 tokens calculate a zero value distribution threshold (
        2. Fixed a bug related to fee distribution during token revokation (
        3. Lots of debugging towards the hang on DEx v1 RPC requests (cause of OmniExplorer’s node crashes), very difficult to replicate explicitly
        4. Continuing work towards port
    • Sean
      1. Holidays
      2. Code validation and cleanup in OmniJ and bitcoinj-addons
        1. FindBugs – resolution of some, but not all issues
        2. PMD – resolution of some, but not all issues
        3. Use JDK7 classpath when compiling Java 7-based modules (needs CI support)
    • Judith
      • Ongoing Communication with projects

  • State of the Layer: All Hands – Jan -10 2017

      By,Adam January 12, 2017

    • Craig
      1. Discussion with Colu on Lightning network compatibility
      2. Updates for Omni port
      3. Improving external communications
      4. DEx volume and automation
      5. DEx tutorial
      6. Core.ID discussion / protocol needs
    • Adam
      1. Omniwallet Support
      2. Starting to look into multisig/hardware wallets 
    • dexx
      1. Reviewed and merged fee related pull requests from Zathras:
      2. Sanitized RPC responses to replace non-UTF-8 compliant characters:
      3. Reviewed backports of fixes and performance improvements for from Zathras:
      4. Ported code base to Bitcoin Core 0.13.2:
    • Zathras
      1. OmniExplorer:
        1. Recovered from another OC node failure
        2. Added token distribution statistics feature as requested (just choose ‘Click to view statistics’ when viewing any property)
      2. Omni Core:
        1. Still trying to pin down exact circumstances that trigger node crash, still difficulty replicating, moved testing to Windows OS
        2. Backported several fixes back to 0.0.11 for point release (
        3. Further progress on Omni Core port
      3. General:
        1. Support requests increasing, likely due to increasing usage of Omni Layer technologies (transaction vol has almost doubled in last month alone)
        2. Investigating Sean/Adam’s new ideas around DEx1 (CSV, CLTV etc)
    • Sean
      1. Bitcoinj-addons
        1. Bug fixes, code cleanup for upcoming 0.2.2 release
      2. OmniJ
        1. Big fixes, code cleanup for upcoming 0.5.1 release
        2. 0.5.1 will also have optimized Omniwallet REST balance queries
      3. OmniPortfolio
        1. Bug fixes and updates for upcoming 0.1.2 release
        2. 0.1.2 release will use OmniJ 0.5.1 and bitcoinj-addons 0.2.2
    • Judith
      • Ongoing Communication with projects

  • State of the Layer: All Hands – Jan -17 2017

    • Craig
      1. Lightning network exploration / output-based conversions
      2. Updates for Litecoin Omni port
      3. Improving external communications
      4. DEx tutorial / volume and automation
      5. Core.ID discussion / protocol needs
      6. Report on transaction volumes
        1. Tracking usage and relevant stats on omniexplorer
      7. Adding Dex transactions to Coinmarketcap
    • Adam
      1. Omniwallet Support
      2. Continuing to look into multisig/hardware wallets support
    • Patrick
      1. Follow-up Interview w/ Coininterview
      2. Business development re: multisig wallet sponsorship
      3. Getting organized to push OmniArb prototype live.
      4. Spec work to prepare for futures crowdsale
      5. Work organizing the sales back-end for BOND and other products
      6. Initial treatment for Registered Addresses/Stocks on blockchain
    • dexx
      1. Ported Omni Core to 0.13.2:
      2. Used non-segwit serialization for OmniJ:
      3. Started to look into building Omni Core via Gitian to resolve issue with icons and installer:
    • Zathras
      1. Omni Explorer:
        1. Working on API performance improvements & scalability
        2. Fixed outage caused by API threading
      2. Omni Core:
        1. Continuing work on port
      3. General:
        1. Lots of increased interest, requests for guidance (we need to improve introductory documentation)
    • Judith
      • Ongoing Communication with project

  • State of the Layer: All Hands – Jan -24 2017

    • Craig
      1. Satoshi Round Table
    • Adam
      1. Omniwallet
        1. Handling Support
        2. Performing Maintenance on disks
      2. Starting to look into multisig/hardware wallets support
        1. Trezor Dev kit enroute
    • Patrick
      1. Traveling:
        1. Working on finishing the trading algo and getting orders working
    • Sean
      1. OmniPortfolio
        1. Set up private alpha in Google Play for Android 6+
      2. Omni Protocol
        1. More time designing 2-party escrow for Omni-BTC exchange
    • dexx
      • Pushed two pull requests to resolve issues related to build process of Omni Core and related to the build of the Windows setup of Omni Core.
      • Merged the port of the 0.13.2 code base of Bitcoin Core.
      • Also checked out the pull requests of @zathras, related to the update of our splash screen, as well as the performance backport for 0.11.3
      • For our 0.13 port, we only need release notes
    • Zathras
      1. Omni Explorer:
        1. Completed optimizations for heavy usage of getblocktx.  Development version of API much quicker:
          • Timing five hundred requests for blocks getblocktx: real  0m58.816s getblocktx_dev: real  0m7.188s
        1. Working on new schema overhaul to structure DB for API performance
        2. Added graphical view of usage statistics to dev (queries are too heavy for prod at the moment, needs optimizing)
      2. Omni Core:
        1. Reviewed dexx’s various PR’s & tested Bitcoin Core 0.13.2 port (thanks @dexx!)
        2. Minor works on litecoin port, still breaking out code into commits for publish
        3. Updated 0.2 splash to match 0.0.11 (
    • Judith
      • Ongoing Communication with project


    January 25, 2017

  • State of the Layer: All Hands – Feb -7 2017

    February 7, 2017 Adam

    1. Craig
      1. Status for Omni LItecoin screenshots and port / repo
      2. Lightning network exploration / output-based conversions
        1. Open letter for meta-protocols
        2. Investigation on protocol feasibility
      3. DEx tutorial / volume and automation
      4. Report on transaction volumes
        1. Tracking usage and relevant stats on omniexplorer
        2. Move to production
      5. Adding Dex transactions to Coinmarketcap
      6. Core.ID discussion / protocol needs
      7. Exodus wallet integration updates
    2. Adam
      1. Traveling
      2. Omniwallet
        1. Handling support
        2. Starting to look into multisig/hardware wallets support
          1. Dev kit received
    3. Patrick
      1. Troubleshooting RPC issue
      2. Preparing for 2 major crowdsale offerings
    4. Sean
      1. Lightning Network conference call
      2. Consulting, Android development
    5. dexx
      1. Reviewed and tested Zathras’ submissions:
        1. Add seed blocks for 440,000 to 450,000 (merged)
        2. Add checkpoint for block 450,000 (merged)
        3. Provide easy access to specific consensus hashes when parsing (waiting for final tweaks)
      2. Finalizing parts for (based on Bitcoin Core 0.10) and 0.2 (based on Bitcoin Core 0.13) releases:
        1. Need an update on DEx1 locking issue
        2. Release notes are last part missing before tagging the releases
    6. Zathras
      1. Omni Explorer:
        1. Fixed a bug causing incorrect display of DEx v1 sell offer pricing
        2. Further performance related schema work (migrating raw tx data out of primary tables to shrink them)
        3. Added sell linking, pricing, time and purchase data when viewing DEx accepts (thanks for feedback @Marv)
        4. Working on adding support for Send All transactions to the engine and front end in dev (thanks for feedback @Adam)
        5. Need to discuss testing requirements & then arrange time to move dev improvements over to production
      2. Omni Core:
        1. Added option to easily generate a specific consensus hash during parsing (
        2. Added checkpoint for block 450,000 (
        3. Battle testing of Omni Core 0.2 going well
      3. Omni Core Lite:
        1. Pushed first rough version of “Omni Core Lite” (port to Litecoin –
      4. General:
        1. Support requests are mainly around the same issue (confirmation time) – since the answer is usually the same (fees) can we help users self-service these requests?  Eg FAQ?
    7. Judith
      • Ongoing Communication with project

  • State of the Layer: All Hands – Feb -21 2017

    • Adam
      1. Omniwallet
        1. Handling support
        2. Starting to look into multisig/hardware wallets support
    • Patrick
      1. OmniArb Progress –  packaging into NPM/Github repo
      2. OmniArb Features – investigating way to detect 0-confirmation potential trade matches and lock in an arb quickly
      3. BOND to be listed as regulated fund in Armenia on NASDAQ OMX, working on Blockchain Yield Index methodology
      4. Preparing proposal to stock transfer agency for sponsorship/KYC address project
    • Sean
      1. Consulting, Android development
    • dexx
      1. Omni Core can be released, after “Bump version to Omni Core” is merged:
      2. Omni Core 0.2 (based on Bitcoin Core 0.13.2) can be released, after “Update release notes for Omni Core 0.2” is resolved:
    • Zathras
      1. Omni Core:
        1. Looking at requirements and options for address tagging
        2. Built prototype for atomic metadata
      2. Omni Core Lite:
        1. Fixed Linux Gitian builds, now working on Windows
        2. Added functionality for remaining transactions to send tab
      3. General:
        1. Usual support & enquiries
    • Marv
      1. Omniwallet
        1. User support
    • Judith
      1. On going communications with projects

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