omnilayer / omnicore

OmniCore staging tree

Omni Core (beta) integration/staging tree

What is the Omni Layer

The Omni Layer is a communications protocol that uses the Bitcoin block chain to enable features such as smart contracts, user currencies and decentralized peer-to-peer exchanges. A common analogy that is used to describe the relation of the Omni Layer to Bitcoin is that of HTTP to TCP/IP: HTTP, like the Omni Layer, is the application layer to the more fundamental transport and internet layer of TCP/IP, like Bitcoin.

http://www.omnilayer.org

What is Omni Core

Omni Core is a fast, portable Omni Layer implementation that is based off the Bitcoin Core codebase (currently 0.20.1). This implementation requires no external dependencies extraneous to Bitcoin Core, and is native to the Bitcoin network just like other Bitcoin nodes. It currently supports a wallet mode and is seamlessly available on three platforms: Windows, Linux and Mac OS. Omni Layer extensions are exposed via the JSON-RPC interface. Development has been consolidated on the Omni Core product, and it is the reference client for the Omni Layer.

Disclaimer, warning

This software is EXPERIMENTAL software. USE ON MAINNET AT YOUR OWN RISK.

By default this software will use your existing Bitcoin wallet, including spending bitcoins contained therein (for example for transaction fees or trading). The protocol and transaction processing rules for the Omni Layer are still under active development and are subject to change in future. Omni Core should be considered an alpha-level product, and you use it at your own risk. Neither the Omni Foundation nor the Omni Core developers assumes any responsibility for funds misplaced, mishandled, lost, or misallocated.

Further, please note that this installation of Omni Core should be viewed as EXPERIMENTAL. Your wallet data, bitcoins and Omni Layer tokens may be lost, deleted, or corrupted, with or without warning due to bugs or glitches. Please take caution.

This software is provided open-source at no cost. You are responsible for knowing the law in your country and determining if your use of this software contravenes any local laws.

PLEASE DO NOT use wallet(s) with significant amounts of bitcoins or Omni Layer tokens while testing!

Testnet

Testnet mode allows Omni Core to be run on the Bitcoin testnet blockchain for safe testing.

1. To run Omni Core in testnet mode, run Omni Core with the following option in place: -testnet.

2. To receive OMN (and TOMN) on testnet please send TBTC to moneyqMan7uh8FqdCA2BV5yZ8qVrc9ikLP. For each 1 TBTC you will receive 100 OMN and 100 TOMN.

Dependencies

Boost >= 1.53

Installation

You will need appropriate libraries to run Omni Core on Unix, please see doc/build-unix.md for the full listing.

You will need to install git & pkg-config:

sudo apt-get install git
sudo apt-get install pkg-config

Clone the Omni Core repository:

git clone https://github.com/OmniLayer/omnicore.git
cd omnicore/

Then, run:

./autogen.sh
./configure
make

Once complete:

cd src/

And start Omni Core using ./omnicored (or ./qt/omnicore-qt if built with UI). The initial parse step for a first time run will take up to 60 minutes or more, during this time your client will scan the blockchain for Omni Layer transactions. You can view the output of the parsing at any time by viewing the log located in your datadir, by default: ~/.bitcoin/omnicore.log.

Omni Core requires the transaction index to be enabled. Add an entry to your bitcoin.conf file for txindex=1 to enable it or Omni Core will refuse to start.

If a message is returned asking you to reindex, pass the -reindex flag as startup option. The reindexing process can take several hours.

To issue RPC commands to Omni Core you may add the -server=1 CLI flag or add an entry to the bitcoin.conf file (located in ~/.bitcoin/ by default).

In bitcoin.conf:

server=1

After this step completes, check that the installation went smoothly by issuing the following command ./omnicore-cli omni_getinfo which should return the omnicoreversion as well as some additional information related to the client.

The documentation for the RPC interface and command-line is located in [src/omnicore/doc/rpc-api.md] (src/omnicore/doc/rpc-api.md).

Current feature set:

• Broadcasting of simple send (tx 0) [doc] (src/omnicore/doc/rpc-api.md#omni_send), and send to owners (tx 3) [doc] (src/omnicore/doc/rpc-api.md#omni_sendsto)

• Obtaining a Omni Layer balance [doc] (src/omnicore/doc/rpc-api.md#omni_getbalance)

• Obtaining all balances (including smart property) for an address [doc] (src/omnicore/doc/rpc-api.md#omni_getallbalancesforaddress)

• Obtaining all balances associated with a specific smart property [doc] (src/omnicore/doc/rpc-api.md#omni_getallbalancesforid)

• Retrieving information about any Omni Layer transaction [doc] (src/omnicore/doc/rpc-api.md#omni_gettransaction)

• Listing historical transactions of addresses in the wallet [doc] (src/omnicore/doc/rpc-api.md#omni_listtransactions)

• Retrieving detailed information about a smart property [doc] (src/omnicore/doc/rpc-api.md#omni_getproperty)

• Retrieving active and expired crowdsale information [doc] (src/omnicore/doc/rpc-api.md#omni_getcrowdsale)

• Sending a specific BTC amount to a receiver with referenceamount in omni_send

• Creating and broadcasting transactions based on raw Omni Layer transactions with omni_sendrawtx

• Functional UI for balances, sending and historical transactions

• Creating any supported transaction type via RPC interface

• Meta-DEx integration

• Support for class B (multisig) and class C (op-return) encoded transactions

• Support of unconfirmed transactions

• Creation of raw transactions with non-wallet inputs

Related projects:

• https://github.com/OmniLayer/OmniJ

• https://github.com/OmniLayer/omniwallet

• https://github.com/OmniLayer/spec

Support:

• Please open a [GitHub issue] (https://github.com/OmniLayer/omnicore/issues) to file a bug submission.

omnicore's Issues

Meta DEx network/transaction message fields

Back then, during the spec discussion, there was general consensus to change the order of transaction fields as follows, because not in any case all fields are validated, or used:

Add:
[version=0] [type=21] [action=1] [property] [number] [property] [number]

Cancel-All-At-Price:
[version=0] [type=21] [action=2] [property] [number] [property] [number]

Cancel-All-Of-Currency-Pair:
[version=0] [type=21] [action=3] [property] [property]

Cancel-Everything:
[version=0] [type=21] [action=4] [ecosystem]

Related discussion: OmniLayer/spec#276, OmniLayer/spec#284

And there was mixed consesensus to get rid of the action byte altogether:

Add:
[version=0] [type=25] [property] [number] [property] [number]

Cancel-All-At-Price:
[version=0] [type=26] [property] [number] [property] [number]

Cancel-All-Of-Currency-Pair:
[version=0] [type=27] [property] [property]

Cancel-Everything:
[version=0] [type=28] [ecosystem]

Related discussion: OmniLayer/spec#285

---

Reordering the fields was postponed to a next version of the meta DEx, and removing the action byte was dismissed due to it's complexity.

Given that Omni Core changed significantly since then, I re-evaluated the complexity.

Turned out it was less difficult than anticipated, and for fun I implemented the second route, which is actually more invasive: 27f7c3da9625b4acad863a899ff5854254ac20df

To avoid breaking secondary software, such as the tests via OmniJ [...], the API is unchanged, and trade_MP/trade_OMNI can still be used as usual.

The UI works, and all tests pass, including the meta DEx test plan.

Please discuss, whether transaction type 21 can be restructured, such that the ecosystem field is no longer at the end of the data package, and the non-validated fields are removed, or ideally, if the transaction type can be replaced and split into 4 seperated ones (for each action) without action byte.

The upsides:

• smaller payloads
• less ambiguousness

The downsides:

• specification needs to be updated
• it might affect other projects

Updating the specification shouldn't take long, but I'm wondering, if there are other projects, which might be affected by the change, for example Omniwallet? Given that the token exchange was not yet released, and projects should use Omni Core as backend in almost any case, I expect no, or almost no impact.

CC: @dacoinminster, @zathras-crypto, @marv-engine, @achamely

Differences in output with clean parse vs load from state

I've been having a little trouble with some functionality in the auditor and I think I've tracked down what's causing the problem - during a fresh parse the prices in the maps are not the same as when loaded from state. I don't mean the different ordering (I can handle that) but where the price levels seem to be off when parsing fresh.

Example:
Fresh Parse :

2015-04-21 07:26:31 0.00000001000000000000000000000000000000000000000000= 0.00000001000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311949/011, txid: 327872c39d , trade #1 1.00000000 for #3 1

Load State :

2015-04-21 07:28:31 100000000.00000000000000000000000000000000000000000000000000= 0.00000001000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311949/011, txid: 327872c39d , trade #1 1.00000000 for #3 1

@m21 is there any process that runs to do some kind of clean up and ordering on the MetaDEx maps when loading from persistence? Could this be some sort of inherited behaviour from the process of loading the state?

Just figured I'd see if you knew why there would be this kind of difference between parsing and loading state?

Dumping the MetaDEx state when started with --startclean parameter:
src/bitcoind --server --daemon --checkblocks=1 --testnet --disableauditor --startclean

2015-04-21 07:26:31 0.00000001000000000000000000000000000000000000000000= 0.00000001000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311949/011, txid: 327872c39d , trade #1 1.00000000 for #3 1
2015-04-21 07:26:31 0.00000003000000000000000000000000000000000000000000= 0.00000003000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 313391/015, txid: befeae0ace , trade #1 1.00000000 for #3 3
2015-04-21 07:26:31 0.00000005000000000000000000000000000000000000000000= 0.00000005000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311942/006, txid: 10f83fe96b , trade #1 0.20000000 for #3 1
2015-04-21 07:26:31 0.00000010204081632653061224489795918367346938775510= 0.00000010204081632653061224489795918367346938775510:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/015, txid: 59021a3dd2 , trade #1 0.98000000 for #5 10
2015-04-21 07:26:31 0.00000010869565217391304347826086956521739130434783= 0.00000010869565217391304347826086956521739130434783:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/016, txid: 19e139158d , trade #1 1.84000000 for #5 20
2015-04-21 07:26:31 0.00000011111111111111111111111111111111111111111111= 0.00000011111111111111111111111111111111111111111111:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/002, txid: 2de1fe7ddc , trade #1 0.90000000 for #5 10
2015-04-21 07:26:31 0.00000020000000000000000000000000000000000000000000= 0.00000020000000000000000000000000000000000000000000:mpZATHm5ih33ePoSPxFQ4cvWZWaPkN4G5s in 330349/020, txid: 7d624401af , trade #1 0.50000000 for #13 10
2015-04-21 07:26:31 0.00000033333333333333333333333333333333333333333333= 0.00000033333333333333333333333333333333333333333333:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/024, txid: 42bf259148 , trade #1 0.03000000 for #3 1
2015-04-21 07:26:31 0.00000500000000000000000000000000000000000000000000= 0.00000500000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/026, txid: de19d7f7a6 , trade #1 0.00200000 for #3 1
2015-04-21 07:26:31 0.00000500000000000000000000000000000000000000000000= 0.00000500000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/027, txid: b4aa3af464 , trade #1 0.00200000 for #3 1
2015-04-21 07:26:31 0.33333333333333333333333333333333333333333333333333= 0.33333333333333333333333333333333333333333333333333:mvayzbj425X55kRLLPQiuCXWUED6LMP65C in 305595/004, txid: a1376f5bdc , trade #1 0.00000300 for #3 100
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309727/002, txid: 1f9155eee4 , trade #1 0.00000001 for #20 0.00000001
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310026/002, txid: 0f67b7b6bc , trade #1 0.00000001 for #3 1
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310027/003, txid: ffee7963d6 , trade #1 0.00000001 for #3 1
2015-04-21 07:26:31 2.00000000000000000000000000000000000000000000000000= 2.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312084/006, txid: c72cd6f1e7 , trade #1 0.50000000 for #12 1.00000000
2015-04-21 07:26:31 5.00000000000000000000000000000000000000000000000000= 5.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311791/028, txid: ee5272132f , trade #1 2.00000000 for #12 10.00000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mneQadUYjdCB9mrNg3WgaYKj6NVmchUfvH in 309172/002, txid: 2b1ee4f26c , trade #1 1.00000000 for #5 1000000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8 in 311783/003, txid: ccbc53db41 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i in 311939/018, txid: 0d8dbabb22 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i in 311939/019, txid: c738393a05 , trade #1 0.01000000 for #12 0.10000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8 in 312078/018, txid: 2b1e7b8336 , trade #1 0.01000000 for #12 0.10000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312095/025, txid: 89910aecb8 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309269/015, txid: a5fb5ce90d , trade #1 3.00000000 for #12 30.00000000
2015-04-21 07:26:31 50.00000000000000000000000000000000000000000000000000= 50.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305471/008, txid: eb87052102 , trade #1 19.98000000 for #12 999.00000000
2015-04-21 07:26:31 100.00000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305159/006, txid: f2db50593f , trade #1 1.00000000 for #12 100.00000000
2015-04-21 07:26:31 100.00000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305161/002, txid: 81d692f2a2 , trade #1 0.50000000 for #12 50.00000000
2015-04-21 07:26:31 100.00000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309161/004, txid: 58db47011e , trade #1 0.50000000 for #5 5000000000
2015-04-21 07:26:31 100.00000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mzqSkh1bH6kxapAcgiiYo36K8xuR34b1xz in 312093/004, txid: c60255d730 , trade #1 0.05000000 for #5 500000000
2015-04-21 07:26:31 10005.00250125062531265632816408204102051025512756378189= 10005.00250125062531265632816408204102051025512756378189:mxi5CvG71je3PC36JLQ41oG19qtiM2ABXd in 309386/001, txid: 25594751c6 , trade #1 0.00009995 for #5 100000000
2015-04-21 07:26:31 1000000000000000000.00000000000000000000000000000000000000000000000000= 1000000000000000000.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309730/004, txid: 09e3c101a3 , trade #1 0.00000001 for #20 10000000000.00000000
2015-04-21 07:26:31 0.00000010000000000000000000000000000000000000000000= 0.00000010000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299283/005, txid: 8c9187f058 , trade #2 10.00000000 for #2147483660 100
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mnDfiKzacSJcdABh5MmqCjoguFHSNsNyi5 in 312895/006, txid: 19daef41dd , trade #2 1.00000000 for #2147483671 1.00000000
2015-04-21 07:26:31 100.00000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mneQadUYjdCB9mrNg3WgaYKj6NVmchUfvH in 309655/008, txid: 75ac143527 , trade #2 0.00080000 for #2147483679 0.08000000
2015-04-21 07:26:31 20000.00000000000000000000000000000000000000000000000000= 20000.00000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299277/004, txid: e8660cdda2 , trade #2 0.00050000 for #2147483651 10.00000000
2015-04-21 07:26:31 5000000000000000.00000000000000000000000000000000000000000000000000= 5000000000000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305281/008, txid: 24a887e165 , trade #3 2 for #1 100000000.00000000
2015-04-21 07:26:31 10000000.00000000000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/013, txid: 3feb9ec199 , trade #5 15 for #1 1.50000000
2015-04-21 07:26:31 10000000.00000000000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305594/010, txid: 1fb1bf01b0 , trade #5 19 for #1 1.90000000
2015-04-21 07:26:31 10000000.00000000000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305595/005, txid: 4a9fb5eebf , trade #5 50 for #1 5.00000000
2015-04-21 07:26:31 12000000.00000000000000000000000000000000000000000000000000= 12000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/016, txid: 26e58a0cd0 , trade #5 10 for #1 1.20000000
2015-04-21 07:26:31 12500000.00000000000000000000000000000000000000000000000000= 12500000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/037, txid: 004f676c7c , trade #5 20 for #1 2.50000000
2015-04-21 07:26:31 13000000.00000000000000000000000000000000000000000000000000= 13000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/039, txid: b80f7c45f2 , trade #5 10 for #1 1.30000000
2015-04-21 07:26:31 50000000.00000000000000000000000000000000000000000000000000= 50000000.00000000000000000000000000000000000000000000000000:mvayzbj425X55kRLLPQiuCXWUED6LMP65C in 305612/004, txid: 941e0834f9 , trade #5 2 for #1 1.00000000
2015-04-21 07:26:31 0.10000000000000000000000000000000000000000000000000= 0.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 306356/010, txid: 75b687ca67 , trade #12 0.00000003 for #1 0.00000000
2015-04-21 07:26:31 0.10999999997051402461909080516077581355283271004378= 0.10999999997101460474104885414869543915434863984664:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 307645/010, txid: 985954528e , trade #12 320.85123963 for #1 35.29363635
2015-04-21 07:26:31 0.20000000000000000000000000000000000000000000000000= 0.20000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 306354/005, txid: 9572150174 , trade #12 91.00000000 for #1 18.20000000
2015-04-21 07:26:31 0.70000000000000000000000000000000000000000000000000= 0.70000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312085/005, txid: dc864fdd6f , trade #12 49.00000000 for #1 34.30000000
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mpDex2b2HtGVAFgJLnCyZAyeejpr6JjcTF in 304636/008, txid: 0cfe1e5d96 , trade #12 1.00000000 for #1 1.00000000
2015-04-21 07:26:31 10000000.00000000000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 307651/007, txid: 5e1db9843c , trade #13 10 for #1 1.00000000
2015-04-21 07:26:31 20000000.00000000000000000000000000000000000000000000000000= 20000000.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 330348/035, txid: d51d45a170 , trade #13 10 for #1 2.00000000
2015-04-21 07:26:31 500000000000000000.00000000000000000000000000000000000000000000000000= 500000000000000000.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309722/014, txid: e42763e502 , trade #20 0.00000002 for #1 10000000000.00000000
2015-04-21 07:26:31 0.00000002000000000000000000000000000000000000000000= 0.00000002000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309711/002, txid: af2752cd7a , trade #22 50000000 for #1 0.00000001
2015-04-21 07:26:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310401/005, txid: efd436628c , trade #22 3 for #1 0.00000003
2015-04-21 07:26:31 0.10000000000000000000000000000000000000000000000000= 0.10000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/006, txid: 4aebb64b20 , trade #2147483651 20.00000000 for #2 2.00000000
2015-04-21 07:26:31 0.15000000000000000000000000000000000000000000000000= 0.15000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/011, txid: 0ce89ba92d , trade #2147483651 100.00000000 for #2 15.00000000
2015-04-21 07:26:31 0.20000000000000000000000000000000000000000000000000= 0.20000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/012, txid: 470467605a , trade #2147483651 100.00000000 for #2 20.00000000
2015-04-21 07:26:31 5.00000000000000000000000000000000000000000000000000= 5.00000000000000000000000000000000000000000000000000:mshLuF16vrTGDxDAJtUe79DzWozARztRVP in 299448/002, txid: da6e50254d , trade #2147483651 2.00000000 for #2 10.00000000
2015-04-21 07:26:31 4.34782608695652173913043478260869565217391304347826= 4.34782608695652173913043478260869565217391304347826:mxaYwMv2Brbs7CW9r5aYuEr1jKTSDXg1TH in 272804/003, txid: fbeeee3116 , trade #2147483652 11.50000000 for #2 50.00000000
2015-04-21 07:26:31 0.10000000000000000000000000000000000000000000000000= 0.10000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 306893/010, txid: a371593425 , trade #2147483674 0.00000050 for #2 0.00000005
2015-04-21 07:26:31 0.50000000000000000000000000000000000000000000000000= 0.50000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 306872/060, txid: c9c376f738 , trade #2147483674 0.00000010 for #2 0.00000005
2015-04-21 07:26:31 10.00000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309269/022, txid: a6c8734e87 , trade #2147483674 19.00000000 for #2 190.00000000

Dumping the MetaDEx state when started without --startclean (loads from persistence):
src/bitcoind --server --daemon --checkblocks=1 --testnet --disableauditor

2015-04-21 07:28:31 0.00000000000000000100000000000000000000000000000000= 1000000000000000000.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309730/004, txid: 09e3c101a3 , trade #1 0.00000001 for #20 10000000000.00000000
2015-04-21 07:28:31 0.00009995000000000000000000000000000000000000000000= 10005.00250125062531265632816408204102051025512756378189:mxi5CvG71je3PC36JLQ41oG19qtiM2ABXd in 309386/001, txid: 25594751c6 , trade #1 0.00009995 for #5 100000000
2015-04-21 07:28:31 0.01000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305159/006, txid: f2db50593f , trade #1 1.00000000 for #12 100.00000000
2015-04-21 07:28:31 0.01000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305161/002, txid: 81d692f2a2 , trade #1 0.50000000 for #12 50.00000000
2015-04-21 07:28:31 0.01000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309161/004, txid: 58db47011e , trade #1 0.50000000 for #5 5000000000
2015-04-21 07:28:31 0.01000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mzqSkh1bH6kxapAcgiiYo36K8xuR34b1xz in 312093/004, txid: c60255d730 , trade #1 0.05000000 for #5 500000000
2015-04-21 07:28:31 0.02000000000000000000000000000000000000000000000000= 50.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 305471/008, txid: eb87052102 , trade #1 19.98000000 for #12 999.00000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mneQadUYjdCB9mrNg3WgaYKj6NVmchUfvH in 309172/002, txid: 2b1ee4f26c , trade #1 1.00000000 for #5 1000000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8 in 311783/003, txid: ccbc53db41 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i in 311939/018, txid: 0d8dbabb22 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:myBx7FajcnqxTHVTrQnPHaohRgEByKXc1i in 311939/019, txid: c738393a05 , trade #1 0.01000000 for #12 0.10000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mvBBFH1eA3eX6gRW2iS6CVEWTWbk1j5fw8 in 312078/018, txid: 2b1e7b8336 , trade #1 0.01000000 for #12 0.10000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312095/025, txid: 89910aecb8 , trade #1 0.10000000 for #12 1.00000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309269/015, txid: a5fb5ce90d , trade #1 3.00000000 for #12 30.00000000
2015-04-21 07:28:31 0.20000000000000000000000000000000000000000000000000= 5.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311791/028, txid: ee5272132f , trade #1 2.00000000 for #12 10.00000000
2015-04-21 07:28:31 0.50000000000000000000000000000000000000000000000000= 2.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312084/006, txid: c72cd6f1e7 , trade #1 0.50000000 for #12 1.00000000
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309727/002, txid: 1f9155eee4 , trade #1 0.00000001 for #20 0.00000001
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310026/002, txid: 0f67b7b6bc , trade #1 0.00000001 for #3 1
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310027/003, txid: ffee7963d6 , trade #1 0.00000001 for #3 1
2015-04-21 07:28:31 3.00000000000000000000000000000000000000000000000000= 0.33333333333333333333333333333333333333333333333333:mvayzbj425X55kRLLPQiuCXWUED6LMP65C in 305595/004, txid: a1376f5bdc , trade #1 0.00000300 for #3 100
2015-04-21 07:28:31 200000.00000000000000000000000000000000000000000000000000= 0.00000500000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/026, txid: de19d7f7a6 , trade #1 0.00200000 for #3 1
2015-04-21 07:28:31 200000.00000000000000000000000000000000000000000000000000= 0.00000500000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/027, txid: b4aa3af464 , trade #1 0.00200000 for #3 1
2015-04-21 07:28:31 3000000.00000000000000000000000000000000000000000000000000= 0.00000033333333333333333333333333333333333333333333:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311940/024, txid: 42bf259148 , trade #1 0.03000000 for #3 1
2015-04-21 07:28:31 5000000.00000000000000000000000000000000000000000000000000= 0.00000020000000000000000000000000000000000000000000:mpZATHm5ih33ePoSPxFQ4cvWZWaPkN4G5s in 330349/020, txid: 7d624401af , trade #1 0.50000000 for #13 10
2015-04-21 07:28:31 9000000.00000000000000000000000000000000000000000000000000= 0.00000011111111111111111111111111111111111111111111:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/002, txid: 2de1fe7ddc , trade #1 0.90000000 for #5 10
2015-04-21 07:28:31 9200000.00000000000000000000000000000000000000000000000000= 0.00000010869565217391304347826086956521739130434783:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/016, txid: 19e139158d , trade #1 1.84000000 for #5 20
2015-04-21 07:28:31 9800000.00000000000000000000000000000000000000000000000000= 0.00000010204081632653061224489795918367346938775510:mzSeLB27xohsD4KFSJZA1JZaJ5rZURbJjs in 308203/015, txid: 59021a3dd2 , trade #1 0.98000000 for #5 10
2015-04-21 07:28:31 20000000.00000000000000000000000000000000000000000000000000= 0.00000005000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311942/006, txid: 10f83fe96b , trade #1 0.20000000 for #3 1
2015-04-21 07:28:31 33333333.33333333333333333333333333333333333333333333333333= 0.00000003000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 313391/015, txid: befeae0ace , trade #1 1.00000000 for #3 3
2015-04-21 07:28:31 100000000.00000000000000000000000000000000000000000000000000= 0.00000001000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 311949/011, txid: 327872c39d , trade #1 1.00000000 for #3 1
2015-04-21 07:28:31 0.00005000000000000000000000000000000000000000000000= 20000.00000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299277/004, txid: e8660cdda2 , trade #2 0.00050000 for #2147483651 10.00000000
2015-04-21 07:28:31 0.01000000000000000000000000000000000000000000000000= 100.00000000000000000000000000000000000000000000000000:mneQadUYjdCB9mrNg3WgaYKj6NVmchUfvH in 309655/008, txid: 75ac143527 , trade #2 0.00080000 for #2147483679 0.08000000
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mnDfiKzacSJcdABh5MmqCjoguFHSNsNyi5 in 312895/006, txid: 19daef41dd , trade #2 1.00000000 for #2147483671 1.00000000
2015-04-21 07:28:31 10000000.00000000000000000000000000000000000000000000000000= 0.00000010000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299283/005, txid: 8c9187f058 , trade #2 10.00000000 for #2147483660 100
2015-04-21 07:28:31 0.00000000000000020000000000000000000000000000000000= 5000000000000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305281/008, txid: 24a887e165 , trade #3 2 for #1 100000000.00000000
2015-04-21 07:28:31 0.00000002000000000000000000000000000000000000000000= 50000000.00000000000000000000000000000000000000000000000000:mvayzbj425X55kRLLPQiuCXWUED6LMP65C in 305612/004, txid: 941e0834f9 , trade #5 2 for #1 1.00000000
2015-04-21 07:28:31 0.00000007692307692307692307692307692307692307692308= 13000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/039, txid: b80f7c45f2 , trade #5 10 for #1 1.30000000
2015-04-21 07:28:31 0.00000008000000000000000000000000000000000000000000= 12500000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/037, txid: 004f676c7c , trade #5 20 for #1 2.50000000
2015-04-21 07:28:31 0.00000008333333333333333333333333333333333333333333= 12000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/016, txid: 26e58a0cd0 , trade #5 10 for #1 1.20000000
2015-04-21 07:28:31 0.00000010000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305595/005, txid: 4a9fb5eebf , trade #5 50 for #1 5.00000000
2015-04-21 07:28:31 0.00000010000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 308196/013, txid: 3feb9ec199 , trade #5 15 for #1 1.50000000
2015-04-21 07:28:31 0.00000010000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:n4EmA9R4VmxLnxu9G8yZMDxvBBha8bUtEQ in 305594/010, txid: 1fb1bf01b0 , trade #5 19 for #1 1.90000000
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mpDex2b2HtGVAFgJLnCyZAyeejpr6JjcTF in 304636/008, txid: 0cfe1e5d96 , trade #12 1.00000000 for #1 1.00000000
2015-04-21 07:28:31 1.42857142857142857142857142857142857142857142857143= 0.70000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 312085/005, txid: dc864fdd6f , trade #12 49.00000000 for #1 34.30000000
2015-04-21 07:28:31 5.00000000000000000000000000000000000000000000000000= 0.20000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 306354/005, txid: 9572150174 , trade #12 91.00000000 for #1 18.20000000
2015-04-21 07:28:31 9.09090909330457812120569435175245126023972307404363= 0.10999999997101460474104885414869543915434863984664:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 307645/010, txid: 985954528e , trade #12 320.85123963 for #1 35.29363635
2015-04-21 07:28:31 inf= 0.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 306356/010, txid: 75b687ca67 , trade #12 0.00000003 for #1 0.00000000
2015-04-21 07:28:31 0.00000005000000000000000000000000000000000000000000= 20000000.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 330348/035, txid: d51d45a170 , trade #13 10 for #1 2.00000000
2015-04-21 07:28:31 0.00000010000000000000000000000000000000000000000000= 10000000.00000000000000000000000000000000000000000000000000:mpZATHupfCLqet5N1YL48ByCM1ZBfddbGJ in 307651/007, txid: 5e1db9843c , trade #13 10 for #1 1.00000000
2015-04-21 07:28:31 0.00000000000000000200000000000000000000000000000000= 500000000000000000.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309722/014, txid: e42763e502 , trade #20 0.00000002 for #1 10000000000.00000000
2015-04-21 07:28:31 1.00000000000000000000000000000000000000000000000000= 1.00000000000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 310401/005, txid: efd436628c , trade #22 3 for #1 0.00000003
2015-04-21 07:28:31 50000000.00000000000000000000000000000000000000000000000000= 0.00000002000000000000000000000000000000000000000000:mkezrqcfvaQJjYXvqkH4cDwDL45M8uyQY2 in 309711/002, txid: af2752cd7a , trade #22 50000000 for #1 0.00000001
2015-04-21 07:28:31 0.20000000000000000000000000000000000000000000000000= 5.00000000000000000000000000000000000000000000000000:mshLuF16vrTGDxDAJtUe79DzWozARztRVP in 299448/002, txid: da6e50254d , trade #2147483651 2.00000000 for #2 10.00000000
2015-04-21 07:28:31 5.00000000000000000000000000000000000000000000000000= 0.20000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/012, txid: 470467605a , trade #2147483651 100.00000000 for #2 20.00000000
2015-04-21 07:28:31 6.66666666666666666666666666666666666666666666666667= 0.15000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/011, txid: 0ce89ba92d , trade #2147483651 100.00000000 for #2 15.00000000
2015-04-21 07:28:31 10.00000000000000000000000000000000000000000000000000= 0.10000000000000000000000000000000000000000000000000:miLQzgGVDTatUSNaKd91J1DmhCg8HpWuZ9 in 299310/006, txid: 4aebb64b20 , trade #2147483651 20.00000000 for #2 2.00000000
2015-04-21 07:28:31 0.23000000000000000000000000000000000000000000000000= 4.34782608695652173913043478260869565217391304347826:mxaYwMv2Brbs7CW9r5aYuEr1jKTSDXg1TH in 272804/003, txid: fbeeee3116 , trade #2147483652 11.50000000 for #2 50.00000000
2015-04-21 07:28:31 0.10000000000000000000000000000000000000000000000000= 10.00000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 309269/022, txid: a6c8734e87 , trade #2147483674 19.00000000 for #2 190.00000000
2015-04-21 07:28:31 2.00000000000000000000000000000000000000000000000000= 0.50000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 306872/060, txid: c9c376f738 , trade #2147483674 0.00000010 for #2 0.00000005
2015-04-21 07:28:31 10.00000000000000000000000000000000000000000000000000= 0.10000000000000000000000000000000000000000000000000:msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV in 306893/010, txid: a371593425 , trade #2147483674 0.00000050 for #2 0.00000005

Documentation for Omni Core specific options

The following options should be documented:

• -omnialertallowsender=source (multi string, authorize alert senders, can be any)
• -omnialertignoresender=source (multi string, ignore alert senders)
• -autocommit (boolean, create or broadcast transactions, enabled by default)
• -disclaimer (boolean, explicitly show QT disclaimer on startup, disabled by default)
• -omnidebug=category (multi string, enable log categories, can be all, none)
• -omnilogfile=file (string, log file, omnicore.log by default)
• -overrideforcedshutdown (boolean, overwrite shutdown, triggered by an alert, disabled by default)
• -startclean (boolean, clear persistence files, disabled by default)
• -omniprogressfrequency (number, time in seconds after which the initial scanning progress is reported, 30 seconds by default)
• -rpcforceutf8 (boolean, replace invalid UTF-8 encoded characters with question marks in RPC response, default: 1)
• -omniuiwalletscope (number, number of wallet transactions considered by the UI, default: 65535)

The options -datacarrier and -datacarriersize might be mentioned, given that those have an impact on whether class B or class C transactions are created.

Alternatively, and this is what I'd prefer, we add an explicit option to set the limit for class C transactions. I'd favor it, because this allows to use different values, and if we do this, I suggest to set the client's default relay value to 80 byte, but the default cutoff for class C transactions to 40 byte, to support larger OP_RETURN transactions, while ensuring the transactions created by Omni Core are not delayed. The size of 80 byte is the new default for Bitcoin Core 0.11, but I think we should have expressed "support" ideally yesterday.

Support no-wallet mode

Right now it's not possible to build Omni Core without wallet, and neither to use Omni Core with disabled wallet, even if the wallet functionality might not be used at all.

There are a few, actually not many, places where we access the wallet, obviously to create wallet transactions, but I think it's feasible to support a "no-wallet mode".

Some time ago I created the following branch as proof of concept:

• omnicore-0.0.10...dexX7:experimental-oc-0.10-wallet-less

To resolve this issue, I roughly see the following sub tasks:

• locate parts that touch the wallet
• seperate wallet/no-wallet code more cleanly
• enable wallet parts, only if the wallet is available

For the non-UI code I have a good understanding of what to do, but it is probably more difficult for the UI parts, since the wallet is deeply integrated.

Prepare installers, replace icons, define version

With #91, at least for Windows, the setup and icons currently like this:

It should be rebranded to Omni Core.

• Prepare installer
• Replace setup icons
• Define version

Watch-only wallet transactions are not in order

The belief that OrderedTxItems is properly ordered may be false.

When iterating wallet transactions:

block 330105 for tx 3e2313a28fa82c6196bfb0313d8bbd69fdf46246e9160241ad07571a25f08d63
block 330105 for tx 2af942fe0a3c4795c29f087f40701c50152fae83aea9c3f52839d1c51cec7aaf
block 329928 for tx 1f7c88aa0b393b9ccc91ad8a672b33d49e4150a9bbf69094b36b8dfadbfd1bb1
block 329705 for tx 2c711fee42ca3c40cb2163acfeebb545e9f4ba7fb587c92bbdcc85ee3f55439c
block 329569 for tx 7a4045feaef4bf23d8e149db8d5f8db058352aa1cec6d71b45bea0410d5ac571
block 329567 for tx edd66aed4f3237fbb1b475fc620fa48432174694351ce40b984ff271771ab3d9
block 329500 for tx c135c337abb9b0c30d45df21430f99b84410c07b9081eac9093f8e9010c1aee1
block 328968 for tx 57c7c33ead29980b834fab1394348da3c946f038b8af26c039eacac87b1d0dc8
block 328968 for tx 3779517dff19c43a575b661de5454a3c48a2837c3e1916b6ba4d1276f9222582
block 328944 for tx 4b3e1def4e7c99cfe72347f5b25ce31bd4ab2800350cda5f54f5308abc6af741
block 278580 for tx 5ed8587c422e5a2919b80204e2015644dbf036834125b0e254adb3aa6bb4a158 <--
block 278579 for tx fae848ee9ccaa84f1b199a1219c6357532bc14906fa45f525672ac5ebe55c692 <--
block 327644 for tx 9302ba775fb269441b79479c67d23bee5a247ee591cc326bd35037dd8d73899c
block 327644 for tx 3032f2d4139a620fc5418537ed1e318eb5ab27d1998d6b1639b9e3535b213bdd
block 327644 for tx f0ef658bbdb231437f897c95af36860ea385b23349eded4a566d2c9119b883d8
block 327643 for tx 7b6546a77569729266e9bb2b3b39b18b3203183efcf6a7b9550258beeae23cfb
block 327643 for tx 5dd115846a6bdb1ae494b5c8e7baafc59211f6820c24cbb5c6d7c785a7dfd772
block 327643 for tx 6c371ee1311bc223bf220898073ec967046124b95ef563889495697e4b046bc2
block 327185 for tx 32e0b15eacd836fe5370e5d7c2457544bf0fdc1690c1e2e58e6891625f259b97
block 324605 for tx caccd65783b3892e93926fe6f01038d37b97a7140842024cbb43ef761a145cd0
block 324605 for tx e4dcc787351d03f8fb2b520c3ea5a9478bc1df083e644c9246f79caa41afac34

I'm looking into it further, but this has impact because we rely on spoofing an insertion when receiving a Send-To-Owners payout and that relies on ordering.

Ambiguousness of restoring of meta DEx objects

State is stored as a sequence of values in plain files, such as:

13z1JFtDMGTYQvtMq5gs4LmCztK3rmEZga,299076,76375000,1,6415500,0,10000,6

... which represents a traditional DEx offer.

Currently, traditional and meta DEx orders are handled within the same code block, and stored within the same file, and the detection to determine, whether it's a traditional or token offer looks basically like this:

if property desired is BTC then
    process as traditional DEx offer
else
    process as meta DEx order
end if

The catch, and to quote the spec:

When using Action = 4 (CANCEL-EVERYTHING) the validity of the following fields is not tested:

• Currency identifier for sale
• Amount for sale
• Currency identifier desired
• Amount desired

When cancelling everything, it's completely legit to use 0 for the property desired, which would then trigger the interpretation as a traditional offer.

I'm going to take a look at it, and try to untangle this. @zathras-crypto already paved the way for an easier handling of persisted orders, so this shouldn't be too difficult, and it's probably going to be added on top of the other meta DEx stuff.

dFutures Contracts

Let's consider implementing a smart contract type, existing as a special kind of smart property that can exist as signed integer (includes negative balances), where holding it locks up some amount of a designated collateral asset (such as OMNI, USDT) and pays/costs the address the difference between a trade price and a settlement price, either at a settlement time designed for the contract, or when the user trades an off-setting quantity.

Standardized cost-for-difference contracts, in other words. Allows hedging and leveraged speculation on-blockchain.

A very dated spec:

https://docs.google.com/a/farmshares.com/document/d/1_nwkSx3zvyvMHno_zbAuM6E1ypX6LMfGyb8sGaDem_0/edit?usp=drive_web

Examples of how settlement algorithms could work:

https://docs.google.com/drawings/d/19HuBjJEYR059AnqGhWHyHIzWRHN0-69w03zt0BDmzPw/edit?usp=sharing

https://docs.google.com/drawings/d/1frsGq_EzdqqHTtjE8bN_rKN1GtPDlIfsS95vGnRKJMM/edit?usp=sharing

https://docs.google.com/drawings/d/1k60e1tkG25kBfmGqPaWyQs3Gdo5RAT_ajrRtHye34I4/edit?usp=sharing

Meta DEx logic and trade sequence discussion: "both partially filled"

Please confirm, whether the behavior is expected and matches the specification.

---

The following trade sequence is based on #21 (comment), and shows, whether a trade is executed in favor of the buyer, and confirms that it's possible to end up with two partially filled orders.

Trade sequence:

Trade	For Sale	Desired	Unit Price	Inverse Unit Price
A	25 SPX	2.50000000 MSC	0.10000000 MSC/SPX	10.00000000 SPX/MSC
B	0.55000000 MSC	5 SPX	~9.09090909 SPX/MSC	0.11000000 MSC/SPX

Outcome:

Both orders are partially filled, and 5 SPX trade for 0.50000000 MSC.

After the trade A still has 20 SPX left for sale, and B still has 0.05000000 MSC left for sale.

Hold LOCKs only as long as necessary

As outlined in #84,gettransactions_MP and other parts currently lock certain sections longer than necessary.

In case of gettransactions_MP an additional improvement could be to restructure the command, such that we lock the wallet, collect the wallet transactions, release the lock, and then process the transactions, instead of holding the lock for the whole time.

I'm going to tackle it, once the RPC branch is in.

Store state after initial scanning

The state is currently only persisted, after a block was mined.

Closing the client after the initial scanning, but before a block was mined, has the effect that the scanning starts again from the very beginning.

I suggest to store the state after the initial scanning, and this raises the question: maybe we should store the state from time to time during the initial scanning as well? This could allow to stop at some point, and continue later.

Keep track of the progress of bitcoin:0.12

Bitcoin Core 0.11 RC1 was tagged and doesn't merge cleanly into the 0.10 branch unfortunally.

How do we proceed?

Use correct, fixed length integers for all data types

@zathras-crypto audit branch revealed an interesting case, where uint64_t was used to store a token amount, instead of int64_t, which lead to unexpected behavior of the audit module: zathras-crypto#65

---

Well, originally we weren't actually going to cap token counts at 9 gazillion ...

[...] I see some more in the context of crowdfund participation, and CMPTransaction even uses an uint64_t.

Over time, but very carefully (!) they should be replaced by proper types. This should, by the way, also be expanded to other data types, and correct, fixed length integers should be used whenever possible (e.g. uint32_t instead of unsigned int, which is wider on x64 systems, for property identifiers).

Right now, everything works as expected, but [the audit module] is a good example, where this can result in unexpected behavior, so this is rather an improvement for the future, to increase robustness, instead of a bug fix.

Use external cache for CI build results

Because we have an open source plan for Travis CI, the native caching is unfortunally not available, resulting in rather long build times.

In the near future those problems go away, when we can move over to the new "container based" environment, which currently doesn't provide access to all dependencies required for cross-plattform building.

Nevertheless, a sneak preview:

The last one takes "so much time", because it actually also fetches OmniJ and runs the Spock based Omni Core RPC tests. :)

I've started to experiment with Amazon S3, used as substitute for Travis' native cache, and the results are pretty similar to Travis' native cache. I believe this could be a suitable alternative, though I'd need to gain a deeper understanding of S3, especially in the context of access restrictions, and maybe rate limits. The estimated costs are about $ 5-20 for at least 600 full builds. This is a wide range, but I'm not sure, how the data transfer between Travis CI and S3 is charged.

The integration is rather easy, and I run my tests via a private account: dexX7@9335abf

Anyway, some input on this is welcomed.

Rebranding / file names

In earlier versions bitcoind, bitcoin-cli and bitcoin-qt were renamed to mastercored, mastercore-cli and mastercore-qt via makefile.

In #8 (comment) @m21 tackled the topic and suggested renaming the files to omnicore*.

While I generally agree with this practise, there are two points to discuss:

1. The next release:

I'm in the camp that favors a minor release, based on Bitcoin Core 0.10, before doing a major release with meta DEx and new encoding scheme, because roughly 40 % of the nodes listed on bitnodes.io already use 0.10 and such a release is basically a byproduct of the progress towards the next major release. If this is done, the files names should probably still be mastercore* instead of omnicore*, for a frictionless integration.

2. The issues related to file renaming:

There are several parts, which refer to bitcoin* files, for example the QA tests, the deterministic building via Gitian, the Windows installer (if I'm not mistaken, handled by share/setup.nsi.in), and probably other parts as well.

For the last release a new branch was even created to revert the file names as workaround.

• It is thinkable to extend the scope of the rebranding and update all bitcoin* file references. This is probably the way to go, but as natural consequence, this can result in compatibility issues and merge conflicts with Bitcoin Core.
• Alternatively the build route could be adjusted to produce bitcoin* and omnicore* files at the same time.
• Or there could be an option to define the file name target via ./configure. This would probably provide a maximum of flexibility.

I'm not sure, how to tackle this, but in my opinion the rebanding should not break things, and I'd be much more comfortable, if there were a strategy that considers all aspects, whether this involves an extended scope or a dual building route, or something else.

Class C encoded alerts don't pass the marker check

Omni Core alerts use version = 65535 and type = 65535.

This doesn't pass the marker check currently:

if(("6f6d0000" == temp_op_return_script_data[0].substr(0,8)) ||
   ("6f6d0001" == temp_op_return_script_data[0].substr(0,8))) { // only v0/v1 txs are live, add 6f6d0002 to parse a v2 tx when one goes live
    hasOmniBytes = true;
}

The way to go is probably to include the extended marker "6f6dffff" here.

Wallet creates class C transactions, even if not enabled yet

The ClassAgnosticWalletTXBuilder creates class C transactions, even if this feature might not be enabled/live yet.

Suggested fix:

 static bool UseEncodingClassC(size_t nDataSize)
     size_t nTotalSize = nDataSize + 2; // Marker "om"
     bool fDataEnabled = GetBoolArg("-datacarrier", true);

+    int nBlockNow = GetHeight();
+    if (!isAllowedOutputType(TX_NULL_DATA, nBlockNow)) {
+        fDataEnabled = false;
+    }
     return nTotalSize <= nMaxDatacarrierBytes && fDataEnabled;
 }

However, I'm wondering: is there ever the case where the current height is not good enough? For example, could there be the case, where class C transactions might be created, even if not supported yet? I can't think of any case though ...

Commands for creating transactions from non-wallet addresses

@achamely: once native commands for creating tx's from unknown address is available we'll use it. But at the moment OmniCore needs to have the address added/scanned before it will create tx's. Unfortunately for Omniwallet, this isn't possible. 1: too many addresses, 2: we don't have users private keys to add.

Please help me to understand this a bit more. While I can imagine what you may need, it's probably better to clearly define some requirements.

Right now, we are able to construct and sign any transaction for wallet addresses. Those transactions can be broadcasted, or just signed, but currently, this is limited to wallet keys.

As intermediate step, would it help to have an interface to create raw, unsigned transactions, where the caller provides a set of unspent outputs? Would that be possible for OmniWallet?

Grant @dexx7 alert rights

This should be a no-brainer really. @dexX7 is doing great work for us and in my opinion should be given alert broadcast rights.

Opinions aside though, he has merge access so in theory could simply add his own alert address if he wanted to anyway. Thus I propose we request @dexX7 supply us with a mainnet address that can be added to CMPTransaction::step2_Alert along with existing approved senders.

@dexX7 - this is not mandatory mate - if you don't want to that's fine - but I thought given how much you have contributed for us and how involved you are in the project it was only right to at least extend the option.

100% cpu load

We've started seeing 100% cpu load without any changes to server configuration again.
I'm available in Omni Core Skype chat.

[6/19/15, 3:54:22 PM] Andrey Zamovskiy: we are having problems with cpu load again (100% all the time)
[6/19/15, 3:54:23 PM] Andrey Zamovskiy: [6/19/15, 3:13:16 PM] Andrey Zamovskiy: debug log shows a lot of unknown transaction type warnings again
[6/19/15, 3:13:17 PM] Andrey Zamovskiy: 2015-06-19 22:12:56 CWalletTx::GetAmounts: Unknown transaction type found, txid 0810467f4e01785d32e3cca8357235c00095a59749f1bd59425786e06a942b0f
2015-06-19 22:12:56 CWalletTx::GetAmounts: Unknown transaction type found, txid d3664e79c4cc44209a7c5001f267f8c604288ae348021c11af14010454b32f11
2015-06-19 22:12:56 CWalletTx::GetAmounts: Unknown transaction type found, txid 33ec8b9c8f7ed5caedb0ae36bc8f0512c8781bd8c08557c86ead778644cdaa36
2015-06-19 22:12:56 CWalletTx::GetAmounts: Unknown transaction type found, txid 60cae07c62ce2718a296bf179250a7964b8faaa667b06f6b83118f4c5104d8ea
[6/19/15, 3:25:18 PM] Andrey Zamovskiy: 2015-06-19 22:24:57 ERROR: AcceptToMemoryPool : inputs already spent
2015-06-19 22:24:57 ERROR: AcceptToMemoryPool : inputs already spent
[6/19/15, 3:25:50 PM] Andrey Zamovskiy: > during this time the blockchain is synced? (ie the daemon is not doing a bunch of script verification?)
correct
[6/19/15, 3:26:12 PM] Andrey Zamovskiy: i've doubled the VPS cpu power and a couple of days later it started to hit 100% again
[6/19/15, 3:29:18 PM] Andrey Zamovskiy: i'm seeing a flood of messages like this in mastercore.log
[6/19/15, 3:29:18 PM] Andrey Zamovskiy: 2015-06-19 22:28:55 ____________________________________________________________________________________________________________________________________
2015-06-19 22:28:55 parseTransaction(block=342318, 1970-01-01 00:00:00 idx= 0); txid: e49e4a51b3b80f4b3dca13f12c2e4a35780433a7410b94ac90edc3f0dc50eca8
2015-06-19 22:28:55 version: 0, Class B
2015-06-19 22:28:55 type: 0 (Simple Send)
2015-06-19 22:28:55 getValidMPTX() size=4 : 1:342318:0:267077703
2015-06-19 22:28:55 CMPTxList stats: nWritten= 0 , nRead= 480
2015-06-19 22:28:55 property: 31 (SP token: 31)
2015-06-19 22:28:55 value: 2.67077703
[6/19/15, 3:29:53 PM] Andrey Zamovskiy: can cpu load be caused by too high debug level?
[6/19/15, 3:30:02 PM] Andrey Zamovskiy: there are like 10 messages per second
[6/19/15, 3:30:03 PM] Andrey Zamovskiy: like this one
[6/19/15, 3:35:46 PM] Andrey Zamovskiy: i've set debug=0 in config - it didn't help
[6/19/15, 3:35:49 PM] Andrey Zamovskiy: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4886 masterc+ 20 0 2422076 1.053g 11972 S 99.8 14.4 2:18.87 mastercored
[6/19/15, 3:55:12 PM] Andrey Zamovskiy: i keep seeing parseTransaction messages even though i've set debug to 0
[6/19/15, 3:55:15 PM] Andrey Zamovskiy: i think this is wrong

Support no-txindex mode

Right now Omni Core must be used with enabled transaction index, which comes at the cost of storing an index for any transaction, and expensive scanning for transactions, in case transactions were not yet indexed.

Though we are actually only interested in a very small fraction of all transactions, namely those, which are relevant for the Omni Layer.

Currently, not all information we may need is persisted the first time we see it, and for instance, some RPC calls retrieve and reprocess transaction information from the chain every time, instead of getting it from some seperated DB.

This topic probably gets much more relevant with Bitcoin Core 0.11, which allows to discard old blockchain data ("block pruning"), and I think we should explore, and aim for a no-txindex mode.

I believe this could be done, if we move to a model, where transactions are only processed once, and all relevant information is conserved.

Release process and plan for 0.0.10

Let's discuss a timeline, and steps to take.

The process for preview builds, and releases should be done as before:

1. Test build process
2. Tag release
3. Build binaries for Windows, Unix and OS X, ideally deterministically
4. Publish results

What is the timeline for the release, or preview?

What should be added for the preview?

What should be added for the release?

I started a list, and created a few more issues, for points I can currently think of:

• #14: Unification of RPC labels, commands, descriptions
• #71: Documentation for Omni Core specific options (started, but needs refinement)
• #74: Tweak and group transaction parsing and handling
• #78: Coin selection and fee warning
• #91: Rebrand project to Omni Core (related: #10)
• #94: LOCK properly, everywhere, where necessary
• #95: Update RPC API documentation
• #96: Changelog and release notes for 0.0.10
• #97: Prepare installers, replace icons, define version
• #104: Notification based consensus rule updates (related: #116, #129, #159)
• #105: MetaDEx RPC overhaul
• #113: Standardize RPC calls on omni_abcdefghij
• #117: Bump Omni Core version to RC1 (related: #162)

---

Guidelines:

• Signing of Omni Core build results via Gitian

Honoring the original unit price in updated offers

When calculating the amounts to trade on the meta DEx, the applied unit price of an order may be rounded to the next tradable unit, constrained by the amounts available, however, the original unit price should be honored in subsequent trades.

Example trade:

A1 offers 100.00000000 SPX for 10.00000000 MSC
A2 offers 0.80000000 MSC for 7.27272727 SPX

A1 receives 0.80000000 MSC, and has 9.272727273 SPX left for sale (A1's offer is updated)
A2 receives 7.27272727, and has 0 SPX left for sale (A2's offer is erased completely)

A1's offer is updated to: 92.72727273 SPX for 9.27272727 MSC

From the debug log:

PRICE CHECK TRADED_MOREINBUYER: buyer = 0.10000000000000000000000000000000000000000000000000 , inserted = 0.09999999996764705882448096885810350091593813232600 : PROBLEM!

This slightly off unit price is due to the ratio of 9.27272727/92.72727273.

As consequence, the unit price starts to drift, and may be significantly different after one or more trades.

---

A straight forward fix requires two additional fields for CMPMetaDEx objects, original_amount_forsale and original_amount_desired, which shall be used to calculate the unit price for (subsequent) offers.

This likely introduces the requirement of further adjustments to CMPMetaDEx::effectivePrice(), maybe to the core meta DEx logic, and certainly to the persistence of data, in particular CMPMetaDEx::saveOffer().

As far as I can see, no change of CMPTradeList::recordTrade() is necessary, but this hidden, or original unit price should be clearly reflected in all user faced channels (i.e. gettrade_MP, getorderbook_MP, ... ?).

Not all UI views handle block reorganizations properly

I noticed it while testing with the current 0.0.10 branch, but not yet with the UI branch, so the results may already be different there.

Not all UI views are updated after reorganizations or chain forks:

• overview: balances are not cleared
• balances
• send dialog
• trading interface: address selectors are not cleared (trades are)
• trade history: not cleared
• trade cancel dialog: address selectors are not cleared
• transactions: transactions are shown as unconfirmed, no details available

After a restart, all views are fine.

In regtest mode, it can be triggered with:

# generate transactions ...
$ ./src/bitcoin-cli getblockhash 3 # or anything
3b2d47cf687c118d7bfb3c6a2213bd6934c91ae5142e413f0358a51a9dd8e8ec
$ ./src/bitcoin-cli invalidateblock 3b2d47cf687c118d7bfb3c6a2213bd6934c91ae5142e413f0358a51a9dd8e8ec
$ ./src/bitcoin-cli setgenerate true 1 # required to trigger update
[
    "4eeb404c435f51b12acbe210c6dc057d3834835cb06941fd8d64808e6d29ff08"
]

In the BTC history the transaction details are still available, and transactions are flagged as "conflicting", but I don't think this is something we should necessarily mirror:

Meta DEx logic and trade sequence discussion: "effective prices"

Please confirm, whether the behavior is expected and matches the specification.

---

The sequence is based on #21 (comment), and shows that the effective price must be within the accepted price range, and otherwise a trade isn't executed.

Trade sequence:

Trade	For Sale	Desired	Unit Price	Inverse Unit Price	Match?
A	0.00000006 MSC	0.00000006 SPX	1.00000000 SPX/MSC	1.00000000 MSC/SPX	No
B	0.00000010 SPX	0.00000001 MSC	0.10000000 MSC/SPX	10.00000000 SPX/MSC	Yes
C	0.00000001 MSC	0.00000010 SPX	10.00000000 SPX/MSC	0.10000000 MSC/SPX	No
D	0.00000001 MSC	0.00000004 SPX	4.00000000 SPX/MSC	0.25000000 MSC/SPX	Yes

Outcome:

1. When A is added, then there is no other order to match against, and this results in a new offering.

2. When B is added, then B is matched against A, and A is filled completely by B, but there is an amount left for sale of 0.00000004 SPX @ 0.1 MSC/SPX.

3. When C is added, then C and B are not matched, due to the minimal tradable amount of 0.00000001 MSC, which implies an effective unit price of at least 0.25 MSC/SPX to make the trade happen.

4. When D is added, then D and B are matched, and both orders are filled completely.

After this trading sequence, order A, B and D were filled, but C is still unmatched, and should be listed in the orderbook.

Unification of RPC labels, commands, descriptions

As continuation of #3 (comment):

@zathras-crypto: I would say for OmniCore at least the API documentation should be the primary doc? It'll need updating if my work gets merged in that's for sure :)

https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/apidocumentation.md

I would say for OmniCore at least the API documentation should be the primary doc?

Well, this is the documentation, but I was more thinking about something more compact, and with the intention of finding a naming convention for various places, such as Omni Core, Omni Wallet, OmniJ, ...

Where I was basically going: there are several labels and commands, documentation pieces and more, all referring to the same thing:

• Spec: "Create a Property via Crowdsale with Variable number of Tokens"
• Omni Core RPC command: "sendissuancecrowdsale_OMNI"
• Omni Core RPC description field: "Create Property - Variable"
• Omni Core transaction history: "Create Property"
• Omni Wallet short description: "Create Property - Variable"
• Omni Chest short description: "Create Property - Crowdsale Issuance"
• OmniJ function name: "createCrowdsaleHex" (let's ignore the "Hex" here)
• OmniJ part of a test label: "create crowdsale"
• OmniJ code comment: "create a property via crowdsale with variable supply"

Now this is more or less pretty similar, but when it comes to.. say for example DEx related stuff, there are "trade tokens for bitcoins", "sell bitcoins for mastercoins", "create an offer", and other variations.

It would be nice to have a spreadsheet with:

Type	Command	Label	Description
1	simple_send	"Simple Send"	"Send tokens"
50	create_crowdsale	"Create Crowdsale"	"Create a property via crowdsale with variable supply"
...	...	...	...

In particular, having consistent commands seems useful, for a consistent use of several Omni products. It's not relevant, whether it's "simplesend" or "simple_send", but more of an issue, if one uses "send", but the other "transfer_tokens", especially when it comes to APIs. Hope you see my point? :)

More obvious cases: "property" or "currency"? "tokens" or "coins", ...?

If I find some time, I'm going to create a list for Omni Core, which could then be passed around to collaboratively improve the names and labels.

I mentioned, I dislike "send_MP" and "send_OMNI", but I also have no idea how to make it better - or what others think about this topic in general - so this can basically be considered as trying to find an answer and alternatives.. :)

At some point this can be extended to parameter names, and it would also be useful, if there were a compact list of the fields of RPC results (e.g. of "gettransaction_MP").

Select no coins to spent which invalidate Omni transactions

I noticed this quite some time ago, when writing bitcoin-spock tests, and we finally found sneaky ways to work around it, but just right now I fully realized the actual issue is part of Omni Core, and not something that should have been addressed in bitcoin-spock.

The current wallet/spending code does not check, if the coins to spent violate consensus rules.

The consensus rules are pretty simple: only pay-to-pubkey-hash and pay-to-script-hash outputs qualify as valid inputs.

The issue while testing was that the coin selection (used by sendrawtx_MP or send_MP) often selects coinbase transaction coins, which result in invalidated Omni transactions, because coinbase transaction coins are no pay-to-pubkey-hash or pay-to-script-hash coins, and thus not valid.

Overflow warning for crowdsale calculuations

To quote the build log:

In file included from /home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/multiprecision/cpp_int.hpp:1802:0,
                 from mastercore_mdex.h:9,
                 from mastercore.cpp:22:
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/multiprecision/cpp_int/limits.hpp: In instantiation of ‘const int std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> > >::digits10’:
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/detail/lcast_precision.hpp:75:66:   instantiated from ‘const unsigned int boost::detail::lcast_precision<boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> > >::precision_dec’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/detail/lcast_precision.hpp:79:2:   instantiated from ‘boost::detail::lcast_precision<boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> > >’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/detail/lcast_precision.hpp:102:32:   instantiated from ‘std::streamsize boost::detail::lcast_get_precision(T*) [with T = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >, std::streamsize = long int]’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/detail/lcast_precision.hpp:170:5:   instantiated from ‘void boost::detail::lcast_set_precision(std::ios_base&, T*) [with T = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >]’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/lexical_cast.hpp:2014:17:   instantiated from ‘bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::shr_using_base_class(InputStreamable&) [with InputStreamable = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >, CharT = char, Traits = std::char_traits<char>, bool RequiresStringbuffer = true]’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/lexical_cast.hpp:2247:90:   instantiated from ‘bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::operator>>(InputStreamable&) [with InputStreamable = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >, CharT = char, Traits = std::char_traits<char>, bool RequiresStringbuffer = true]’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/lexical_cast.hpp:2374:17:   instantiated from ‘static Target boost::detail::lexical_cast_do_cast<Target, Source>::lexical_cast_impl(const Source&) [with Target = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >, Source = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<128u, 128u, (boost::multiprecision::cpp_integer_type)1u, (boost::multiprecision::cpp_int_check_type)0u, void> >]’
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/lexical_cast.hpp:2543:50:   instantiated from ‘Target boost::lexical_cast(const Source&) [with Target = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<> >, Source = boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<128u, 128u, (boost::multiprecision::cpp_integer_type)1u, (boost::multiprecision::cpp_int_check_type)0u, void> >]’
mastercore.cpp:737:96:   instantiated from here
/home/travis/build/dexX7/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/multiprecision/cpp_int/limits.hpp:133:104: warning: integer overflow in expression [-Woverflow]

Update RPC API documentation

The RPC API documention is outdated, and should be updated, to reflect the rebranding from Master to Omni, and to document all new commands.

Keep track of the progress of bitcoin:0.10

Our current main branch is based on bitcoin/bitcoin/tree/0.10, but since then there has been some further progress.

To compare: omnicore-0.0.10...bitcoin:0.10

I suggest to keep our branch in sync, and adopt upstream changes (by cherry-picking?). What is your opinion on this?

Mac OS X Build

It's time to start trying to build the omnicore-0.0.10 branch on Mac OS X.

I just made a quick try using the instructions in README.md, that is:

./autogen.sh
./configure
make

And the make is failing with the following error:

Making all in src
  CXX      omnicore/libbitcoin_server_a-version.o
omnicore/version.cpp:9:14: fatal error: 'build.h' file not found
#    include "build.h"
             ^
1 error generated.
make[2]: *** [omnicore/libbitcoin_server_a-version.o] Error 1
make[1]: *** [all-recursive] Error 1  
make: *** [all-recursive] Error 1

I'm using OS X Yosemite 10.10.3, Xcode 6.3.1, and have used Homebrew to install the prerequisites as described in build-osx.md

LOCK properly, everywhere, where necessary

Locks are used to ensure not more than one thread at the time enters a "locked" region, for example to prevent that thread A writes some data, and another thread B (for example UI, RPC) reads at that moment.

Currently there are a few places where LOCKs are likely missing.

The following parts should be guarded:

• global state objects
• pending transaction objects
• caches

The lock we currently use is cs_tally, whereby I think it would make sense to use a seperated one for the pending transaction objects, and probably for the caches, especially the UI-only caches, too.

Use notifications to enable features

This issue is to discuss and gain consensus on the concept of using notifications (similar to the alert system) to activate features instead of using a hardcoded blockheight in the source.

I propose that:

• We use a message to activate features instead of hardcoded source
• Said message may only come from Exodus
• Said message will contain the transaction type, version, and blockheight for go-live
• Said message can be superseded by a new activation message with a later blockheight, in the event that we discover a critical issue and need to push back activation

This provides us with more granular control of feature activation, but most importantly allows us to do releases more frequently without always guaranteeing everything "beforehand" as it were.

Thoughts please :)

Satisfied seller replacement, trading of zero amounts

It was observed that offers, which have some units left for sale, but no more desire, are added back to the orderbook, as seller_replacement. This results in a faulty unit price, which causes orders, with inversed currency pair, likely to be matched against that faulty offer. Further, such matches result in a valid trade, where no tokens are actually traded.

Gathered logs:

• http://pastie.org/pastes/10097075/text?key=zyhapet9kp6npfj93w9grg
• http://pastie.org/pastes/10100648/text?key=9cueyytgdv61v79sad8xw
• https://gist.githubusercontent.com/dexX7/1853bfe4d58a2595334f/raw/4617bf94f897184ce824a400b6eeab8ae5400f01/faultytrade.log

Trade sequences:

• https://docs.google.com/spreadsheets/d/1PCxICIyw95aMoOHX1RTzrH9-OYbIF0_bkbZmwjAHcGw/edit?usp=sharing

A2 ends up with for sale = 0.00000049 and desired = 0.00000000:

A1: offer 0.00005100 TMSC  for 0.00000051 TDiv1
A2: offer 1.00000000 TDiv1 for 0.01000000 TMSC   <-- fills A1 complely
A3: offer 0.00999999 TMSC  for 0.99999900 TDiv1  <-- is filled by A2, A2 now has 0.00000049 for sale, but 0.00000000 desired
A4: offer 0.00000049 TMSC  for 0.00000049 TDiv1  <-- matches with A2, but it's a zero amount trade

RPC output with some extra info (using gettrade_MP, getorderbook_MP):

• https://gist.githubusercontent.com/dexX7/45097058b357cc82d5ce/raw/

Debug log, with some extra output for the desired amount:

• https://gist.githubusercontent.com/dexX7/abe123c5e37f722aae9b/raw/

The desired amount is calculated based on unit price and amount available, but it comes down to:

amount desired = amount left for sale * unit price
               = 0.00000049 * 0.01
               = 0.0000000049
               = 0

---

To conclude, this issue is unrelated to honoring the original unit price, but the total amount of tokens still desired, based on the original unit price, is less than one willet.

It is thinkable to avoid adding such offers back to the orderbook, which appears to resolve the initial issue, however, this introduces the need for additional adjustments, outside of the meta DEx core logic, to reflect the "satisfaction" of that order. In particular, when using gettrade_MP to get information about the order, the status is reported as "cancelled part filled". Is there anything else, which should be taken care of, or might be affected, assuming such offers were not added back to the orderbook?

Ping @marv-engine (to confirm proper handling and the logic), @m21 (potential mitigation and implementation pitfalls), @zathras-crypto (for the RPC results).

Meta DEx logic and trade sequence discussion: "best fill"

Please confirm, whether the behavior is expected and matches the specification.

---

The trade sequence is based on OmniLayer/spec#170 (comment), and shows, whether the maximum possible amount of tokens, at the best price, is traded.

Trade sequence:

Trade	For Sale	Desired	Unit Price	Inverse Unit Price
A	0.00000020 MSC	0.00000010 SPX	0.50000000 SPX/MSC	2.00000000 MSC/SPX
B	0.00000012 SPX	0.00000017 MSC	~1.41666667 MSC/SPX	~0.70588235 SPX/MSC

From the other thread, and sort of applicable, green are accepted combinations by both:

Outcome:

A is completely filled by B, and 0.00000020 MSC are traded for 0.00000010 SPX.

After the trade B still has 0.00000002 SPX left for sale.

Meta DEx progress

As continuation of mastercoin-MSC#303.

In short: I coded the whole meta DEx test plan, and some other tests, as Python based RPC tests some time ago and the current omnicore-0.0.10 + wallet fix + cancel logic passes all tests.

Rather sooner than later all tests should be converted into spock tests, which are much, much nicer, and once a test base stands, all tests can hopefully be added via a spreadsheet, similar to sto-testplan.tsv, which is literally processed line by line.

However, if someone likes to dig into it, no setup or bitcoin.conf is required, but only:

git clone https://github.com/dexX7/mastercore-rpc-tests.git
./mastercore-rpc-tests/run_mdex_tests.py --daemon=/path-to/omnicore-0.0.10/src/bitcoind --cli=/path-to/omnicore-0.0.10/src/bitcoin-cli

This executes MetaDexPlanTest, MetaDexCancelAtPriceTest, MetaDexCancelPairAndLookupTest, DexCrossEcosystemSideEffectsTest, MetaDexCancelEverythingInSameEcosystemTest, MetaDexCancelEverythingIgnorePropertyTest and MetaDexCancelEverythingScopeTest.

Orderbook states and trades were added as comments for the MetaDexPlanTest.

---

So what's missing? First, the test plan is available here:

• The meta DEx test plan as spreadsheet

I'm actually not convinced this covers everything, and I'm sceptical regarding the rounding behavior of the current implementation, see mega thread for the general discussion: OmniLayer/spec#170.

Rounding is only barely tackled by the test plan, and further, the current test plan doesn't add up, because the actors have insufficient amounts of TMSC at the end of the last rows. This is a minor issue though.

At this point the most valuable missing pieces are probably addtional test sequences, preferably in a format such as:

action	state infos X	state infos Y	state infos Z	...
E1 offers x.xxx TInd for x.xxx TMSC	...	...	...	...
...	...	...	...	...

Where state infos could be expected balances, open offers, or simliar, like in sto-testplan.tsv.

Coin selection and fee warning

To quote zathras-crypto#75:

---

int64_t minWarn = 3 * minRelayTxFee.GetFee(200) + CWallet::minTxFee.GetFee(2000); // based on 3x <200 byte outputs (change/reference/data) & total tx size of <2KB

Provides 2600 satoshi value for minWarn using default parameters (ie no relay or mining fee customization) on 0.0.10 (both testnet & mainnet). This is not sufficient however, as the cost to send a ~450 byte transaction was a touch over 6000 satoshi.

Results in no warning about low fees, but failure to send transaction.

Note to self, revisit how warning fee is calculated.

EDIT: for reminder - available inputs for mpZATHm5 were >2600 minWarn value but not sufficient to send a tx.

---

I further noticed, but please correct me, if I'm wrong, that the coin selection right now may select insufficient amounts.

In particular, selectCoins() appears to select coins, until n_max <= n_total is reached. n_total is returned in any case.

ClassAgnosticWalletTXBuilder() is used to construct transactions, and coins are selected as follows:

// Select the inputs
if (0 > selectCoins(senderAddress, coinControl, referenceAmount)) {
    return MP_INPUTS_INVALID;
}

As far as I can see, this is flawed:

1. The check can never fail, because selectCoins() returns at least 0.
2. If this check is refined, say to if (0 >= ..., then it seems as if this still not sufficient, because the coin selection may as well end, before the actual amount to select is reached.

Potential loss of precision due to floating-point numbers

It is given that certain rational numbers can not be represented as floating point with any finite precision, and it's representation would have an endlessly repeating sequence, resulting in an approximation of the actual value. While this likely only affects the fractional part of numbers, there are other pitfalls, and depending on the level of precision, there are gaps between numbers (for example 9007199254740993 doesn't exist, when using double).

At this point it is unclear, if the meta DEx might be affected by similar issues, which currently uses boost::multiprecision::cpp_dec_float_100 to represent numbers, which are further transformed into strings and cut after a certain number of digits. This primarily affects the calculation of unit prices, and related values, such as the updated amount desired by a seller, the updated amount desired by a buyer, the number of units a buyer receives, and the order matching, which is based on the unit price.

To avoid potential pitfalls related to floating-point numbers, suggestions so far were to use boost::rational to represent rational numbers, or to use boost::multiprecision::int128_t with plain integer math for the core calculations.

It should be discussed, whether this is an actual issue, and how it should be addressed.

Changelog and release notes for 0.0.10

It would be great, if the changes since the last release would be documented.

I think there is no need to go into very much detail for the obvious parts, but there are a few points, which are good to know:

• new transaction types for token exchange
• rebranding (file names!)
• OP_RETURN data embedding
• new API calls
• new configuration options
• debug log customization

Adopt low level byte serialization

As described in #85 (comment), one of the most time consuming parts in the processing flow is the serialization and deserialization of smart properties.

This is caused by the conversion of string -> JSON -> Entry and Entry -> JSON -> string, and not so much by fetching or storing data to the database.

I was curious, if we can improve it by adopting low level byte serialization, and the results are very impressive. The follownig data was captures on mainnet, averaged over 500 runs and based this commit:

• 72948ae95b456cd0778569730ca60b64d23bb811

For SP 4 on mainnet:

entry -> json -> str:   0.040382 ms
str -> json -> entry:   0.027424 ms
entry -> bytes:         0.002574 ms (16x faster)
bytes -> entry:         0.002864 ms (10x faster)

serialized size:      247 byte (= 0.247 kB)

For SP 3 on mainnet:

entry -> json -> str:  16.309372 ms
str -> json -> entry:  71.348212 ms
entry -> bytes:         0.056452 ms (289x faster)
bytes -> entry:         0.094424 ms (756x faster)

serialized size:    19014 byte (= 19.014 kB)

As proof-of-concept I removed the toJSON() and fromJSON() methods of CMPSPInfo::Entry and replaced the related parts where entries are stored or retrieved:

• 4ef1b9eb0e9f237513bdeacfa6bc5cbf5c9ce424

I'm currently parsing mainnet transactions to get a feeling for the speed improvements in practise. Given that CMPSPInfo::getSP() is used almost everywhere, it should be notable, especially in the context of listtransactions_MP, which is primarily slowed down due to the parsing of SP3.

I really, really don't want to start yet another feature before the release, but we should seriously consider replacing the critical parts.

If it turns out, as I hope, that listtransactions_MP gets a speed boost of 50x or more, then I'm going to prepare a clean replacement for getSP(), putSP() and friends.

Otherwise, and regarding the other parts where serialization may play a role, I suggest to adopt byte serialization after the release.

What do you think?

Export of historical trade data in different formats [...]

We have several RPC commands to get a representation of current or historical state, whether it's a list of owners of some property, or information about trades.

However, I'm wondering, if we should support the export of data in other, more use-case focused formats.

A few examples, to outline what I'm thinking about:

1. Company X uses the Omni Layer to raise funds:

For reporting purposes, the raised amounts, receivers, timestamps, ... might be documented in one way or the other.

2. An individual uses Omni Core to trade tokens for profit:

There is a good chance that gains or losses need to be documented properly, if not for archival, then likely for tax purposes.

3. Omni Core serves as backend for some other software:

Some time ago I played around with NinjaTrader, which supports the import of external data:

Now, all this can of course be done with external tools, but I was basically wondering:

1. if the data preprocessing or conversion should be done within Omni Core [what exactly?]
2. if there might be ways to ease the process, for example by returning data, which is currently not returned, or scattered across several RPC commands [which one?]

CC:
@CraigSellars, @patrickdugan

Seperate RPC commands for DEx actions

As discussed in #47 (comment).

Instead of:

sendtrade_OMNI "fromaddress" propertyidforsale "amountforsale" propertiddesired "amountdesired" action

There should be seperate commands for each action, for example:

sendtrade_OMNI "fromaddress" propertyidforsale "amountforsale" propertiddesired "amountdesired"
sendcanceltradebyprice_OMNI "fromaddress" propertyidforsale "amountforsale" propertiddesired "amountdesired"
sendcanceltradebypair_OMNI "fromaddress" propertyidforsale propertiddesired
sendcancelalltrades_OMNI ecosystem

The traditional DEx commands could be seperated in a similar fashion, too.

Edit: bonus points for finding an alternative to the _OMNI suffix. ;)

Move mastercore_/omnicore_ files into subdir

I suggested this earlier, but @m21's response was something like "this creates trouble for mobile users and there is another reason I can't tell", which left me a bit wondering, and I'm not really sure, what that reason could be, or how this might affect mobile users.

Until now, all files were prefixed with mastercore_, but #13 further introduces omnicore_, and in my opinion this is pretty messy, and I'd really like to move all files into a subdir, and get rid of that prefix.

So:

1. Any objections?
2. What name would you like? src/omnicore?
3. @zathras-crypto: assuming we do this, could you update your pending PRs?

---

For my experimental, modular branch, I have a several layers deep file structure, and aside from the actual content, this is basically were I'm going:

https://github.com/dexX7/bitcoin/tree/experimental-minimal-encoding/src/extensions

---

In particular, I suggest to use a one layer deep structure to at first, because anything else would be an overkill for now, with two exceptions: the tests and the docs (but not the main README.md). The change could look like:

doc/apidocumentation.md                         -> src/omnicore/doc/rpc_api.md // ..?
src/mastercore.cpp                              -> src/omnicore/omnicored.cpp  // ..?
src/mastercore.h                                -> src/omnicore/omnicored.h    // ..?
src/mastercore_convert.cpp                      -> src/omnicore/convert.cpp
src/mastercore_convert.h                        -> src/omnicore/convert.h
src/mastercore_dex.cpp                          -> src/omnicore/dex.cpp
src/mastercore_dex.h                            -> src/omnicore/dex.h
src/mastercore_errors.h                         -> src/omnicore/errors.h
src/mastercore_parse_string.cpp                 -> src/omnicore/parse_string.cpp
src/mastercore_parse_string.h                   -> src/omnicore/parse_string.h
src/mastercore_rpc.cpp                          -> src/omnicore/rpc.cpp
src/mastercore_rpc.h                            -> src/omnicore/rpc.h
src/mastercore_script.cpp                       -> src/omnicore/script.cpp
src/mastercore_script.h                         -> src/omnicore/script.h
src/mastercore_sp.cpp                           -> src/omnicore/sp.cpp
src/mastercore_sp.h                             -> src/omnicore/sp.h
src/mastercore_tx.cpp                           -> src/omnicore/tx.cpp
src/mastercore_tx.h                             -> src/omnicore/tx.h
src/mastercore_version.cpp                      -> src/omnicore/version.cpp
src/mastercore_version.h                        -> src/omnicore/version.h
src/omnicore_createpayload.cpp                  -> src/omnicore/createpayload.cpp
src/omnicore_createpayload.h                    -> src/omnicore/createpayload.h
src/omnicore_encoding.cpp                       -> src/omnicore/encoding.cpp
src/omnicore_encoding.h                         -> src/omnicore/encoding.h
src/omnicore_rpctx.cpp                          -> src/omnicore/rpctx.cpp
src/omnicore_rpctx.h                            -> src/omnicore/rpctx.h
src/omnicore_utils.cpp                          -> src/omnicore/utils.cpp
src/omnicore_utils.h                            -> src/omnicore/utils.h
src/test/mastercore_obfuscation_tests.cpp       -> src/omnicore/test/obfuscation_tests.cpp
src/test/mastercore_rounduint64_tests.cpp       -> src/omnicore/test/rounduint64_tests.cpp
src/test/mastercore_script_dust_tests.cpp       -> src/omnicore/test/script_dust_tests.cpp
src/test/mastercore_script_extraction_tests.cpp -> src/omnicore/test/script_extraction_tests.cpp
src/test/mastercore_script_solver_tests.cpp     -> src/omnicore/test/script_solver_tests.cpp
src/test/mastercore_strtoint64_tests.cpp        -> src/omnicore/test/strtoint64_tests.cpp
src/test/mastercore_swapbyteorder_tests.cpp     -> src/omnicore/test/swapbyteorder_tests.cpp

Meta DEx trading interface

What do you think should be added, removed, or changed?

To continue the discussion from the other thread:

... we shouldn't round the price in the order book, but we should show the effective unit price after a match is made.

I agree that showing the effective unit price is the way to go, and in general, I have no objections against a "very accurate" view of the available offers, but I'm wondering, if it's necessary, given that unit prices are shown "per MSC", and the input fields for the price are also "per MSC".

My first instinct was to show only up to 8 decimal places, as this aligns well with the minimal tradable amount of MSC, and then adjust the numbers such that a trade is executed, if the user creates an order with that price. For example: say there is an offer with an effective unit price of 0.10002555555555.., then I'd assume, the user would enter either 0.10002555 or 0.10002556 to match that offer, and if this is the case, I was wondering, if we might just show the price rounded up or down to one willet right from the beginning?

Stacking of superseeded jobs causes UI freezes

I've tested a Windows build based on 7239539 yesterday (ping me or @CraigSellars, if you want binaries) on Windows 8.1 x64.

First, the good things:

• the UI elements are all where they should be :)
• OmniJ regtests pass

However:

• while catching up with the network (block download), the client was mostly frozen and inactive
• after sending a trade, the client never returned from the frozen or inactive state

The tests were done on mainnet, and the last log entry shows an entry for the newly created transaction, though the "transaction sent" dialog never popped up.

UI shutdown issue on Mac OS

I received the following report from Craig for OS X:

I also had an clean exit issue on OS X (actually, the OS X build I played with in November for 0.0.9 had the same problem) - you tell the app to quit, and the UI (but not the window) unloads itself. Then it never quits and must be force quit. It re-opens cleanly (thank god!).

@msgilligan: did you experience this, too?

Meta DEx logic and trade sequence discussion: "clean results"

Please confirm, whether the behavior is expected and matches the specification.

---

The following sequence is based on testnet trades, which initially caused trouble, because the resulting amounts were calculated based on truncated or rounded intermediate results.

Trade sequence:

Trade	For Sale	Desired	Unit Price	Inverse Unit Price
A	23.00000000 MSC	100.00000000 SPX	~4.34782609 SPX/MSC	0.23000000 MSC/SPX
B	50.00000000 SPX	10.00000000 MSC	0.20000000 MSC/SPX	5.00000000 SPX/MSC

Outcome:

B is completely filled by A, and 50.00000000 SPX trade for 11.50000000 MSC.

After the trade A still has 11.50000000 MSC left for sale.

Exodus purchases, DEx payments, crowdsales unconfirmed transactions

Over the last days I tried to make up my mind about how BTC related actions can be nicely integrated into Omni Core, because right now BTC doesn't really fit into the model.

There are a few points I'd like to discuss.

1. Exodus purchases and DEx payments are BTC payments, but they are handled differently.

It's probably not too far fetched to consider Exodus purchases and DEx payments as something similar, at least design wise. There are some significant differences though:

• A DEx payment requires a marker (Exodus output, or "om" bytes), while an Exodus purchase, strictly seen, doesn't. This is only relevant for testnet and regtest mode [extra question: why do use a different destination, which is not the marker here?], because on mainnet the Exodus marker is also the fundraiser destination. However, it's worth to notice that a BTC payment to moneyqMan7uh8FqdCA2BV5yZ8qVrc9ikLP can count as Exodus purchase, even without explicit marker.
• A DEx payment is only considered as such, if the transaction does not embed any payload, i.e. the transaction has a marker, but isn't a class A, B or C transaction. In contrast, the Exodus purchase logic is executed in any case, even if there is another "action" bound to the transaction (such as a simple send, as seen on mainnet).
• There can only be one Exodus purchase per transaction, namely the highest amount sent to Exodus is used to determine the purchased amount, while at the same time, there can be several DEx payments, and for each output on it's own the DEx payment logic is executed (whether it's more than one payment to the same seller, or multiple sellers).

I would really like, if we come up with an approach, which is more consistent, so that Exodus purchases and DEx payments might be handled by the same module. Given that we can't change history, we have to build a model around those limitations, or change the rules for the future.

2. Exodus purchases are crowsale purchases

• That's a very interesting point in my opinon: what exactly is an Exodus purchase? Isn't it a crowdsale, with 10 % early bird bonus per week, with a block height based deadline at block 255365, and a time based deadline at 1377993600 (2013-09-01 00:00:00 UTC)? ;)
• The unfortunate point here is that the deadline block 255365 and the deadline timestamp 1377993600 don't refer to the same point in time, and block 255365 actually has a timestamp of 2013-09-01 00:04:34 UTC.

This alone isn't a deal breaker, because we might introduce the concept (code wise) of an actual deadline (in terms of: end of crowdsale), and a deadline for the bonus calculations. For all tx 51 crowdsales those deadlines are time based, and equal.

3. Floating-point numbers and rounding directions ...

• The Meta-DEx and STO transactions are completely unaffected by any floating point issues, and use plain integer math. Results are either rounded up, or down (i.e. 1.00001 -> 2 or 1).
• The tx 51 crowdsale logic uses integer math for intermediate calculations, but has a concept of fixed precision, and results are divided by 1000000000000L and 100000000 to limit the number of digits. I'm not yet sure, what this means in practise, and whether this implies a loss of precision.
• Unfortunally the DEx payment logic, as well as the Exodus purchase logic use double for the calculations, and results are "rounded half up" (i.e. 0.49 -> 0, 0.50 -> 1).

I started to test the tx 51 crowdsale logic with Exodus fundraiser values, and at least for some input, the results differ by one satoshi. I have no idea, whether this applies to mainnet purchases, or if we may get away in practise with using the crowdsale logic to handle Exodus purchases.

It would be incredibly awesome, if we could get away with it, because then we could get rid of any special "Exodus purchase logic", and simply consider Exodus purchases as crowdsale purchases.

---

My intention is to find a model, where BTC payments fit in nicely, while thinking ahead, where we have to deal with BTC based crowdsales, and maybe a traditional DEx v2 (e.g. #253: Adaptive DEx fees based on purchased amount, #184: Creating MSC/BTC options via DEx fees to the seller).

I'm a bit lost, because I'm not sure, how to continue from here, but I think finding answers to the following questions might help:

1. Do we want to continue to consider DEx payments only as such, if the transaction doesn't embed a payload?
2. How are BTC based crowdsales going to be handled? Might it be possible to participate in several BTC based crowdsales in one transaction, similar to DEx payments, where each output may be a participation/purchase/payment?
3. Would it be possible to get rid of floating point numbers for DEx payments and Exodus purchases?

Code wise, I'd like to turn parseTransaction() into a plain "extract the payload, determine sender and reference" function, and execute any actions (DEx payments, Exodus purchases) somewhere else.

In light of the above, we currently have to determine:

• (a) does the transaction have a marker? (relevant for class A, B, C, DEx payments - not relevant for Exodus purchases)
• (a) which encoding class is used? (relevant for class A, B, C)
• (b) who is the sender? (relevant for for class A, B, C, DEx payments, Exodus purchases)
• (b) who is the reference? (relevant for for class A, B, C)
• (b) does the transaction have a payload? (relevant for DEx payments)
• (b) if so, what is the payload? (relevant for for class A, B, C)
• (b) what is the transaction fee? (relevant for DEx accepts)
• (c) does the transaction have a money output [1EXoDus, moneyqMan]? (relevant for Exodus purchases)
• (c) what is the highest value sent to the money output? (relevant for Exodus purchases)

And we have to handle:

• Exodus purchases (requires b, c)
• DEx payments (requires a, b, c)
• BTC crowdsales at some point (requires a, b, c)
• standard payload-transactions (requires a, b, c)

As far as I can see we may split parseTransaction() and tackle (a), (b), (c) seperately:

• (a) Determine, whether the transaction has a marker, or better: determine the encoding class (cheap)
• (b) Extract payload, determine sender, reference, and transaction fees (expensive)
• (c) Get highest money output ...

Iterating over outputs is smoking fast and "cheap", while retrieving inputs isn't, thus "expensive". There is probably no performance penalty, even if we check the existence of a marker twice, or collect output values for class A, and do another loop for Exdus purchases.

I further imagine we may persist the data gained by (b), in particular: txid, tx fee, encoding class, sender, payload, reference (is that all?), so we don't have to do the expensive parsing more than once. This is something that is going to be very handy for unconfirmed transactions, or a no-txindex mode as well. It raises the following additional questions:

1. If we are going to parse unconfirmed transactions, then we can only estimate in which block a transaction may end up. This isn't a huge problem, and we may persist the data we have, and update the entry (i.e. add block height, transaction position within block), once the transaction confirms. However, the problem I'm not sure about: the parsing logic explicitly uses a block height to determine, whether P2SH outputs are allowed, if class C transactions are enabled. We may assume that an unconfirmed transaction ends up in a block, which has a height greater than the current chain height, but it's still fuzzy during switch-over times. Say for example: current chain height is 356003, and class C transactions are activated at height 356005. Should an unconfirmed transaction be processed as class C transaction or not? Or maybe both cases might be handled, i.e. as class B and as class C? If so, where is the cutoff? 3 blocks before the switch-over, 5 blocks, 10 blocks, ...?
2. If parseTransaction processes transactions only once, and the data is persisted, then it's reasonable to properly persist information about Exodus purchases, and DEx payments, as well. This is already done to some degree, but not completely. Ideally this should be usable for BTC crowdsales as well. Persisting any output of transactions with marker/money output surely works, but it's an absurd overkill. So my last question: what is the minimum data do we need to persist, to cover that as well? I think a small overhead is fine, i.e. it's acceptable, if we store data, which could be related to Exodus purchases or DEx payments (even if it turns out it's not), but we probably don't have to persist data, which certainly won't be used for Exodus purchases [...], say for example, because the Exodus period is already over.

Ideally, I'd like to be able to start with a clean state, and then iterate over the persisted data, and end up with a similar state, as if the data wasn't retrieved from a DB, but extracted from transactions, as currently done.

Sorry in advance for the very long post, but especially finding answers to the last two questions would be very, very helpful for me.

Meta DEx logic and trade sequence discussion: "rational numbers"

Please confirm, whether the behavior is expected and matches the specification.

---

The following sequence is straight forward, but yields unexpected results, if floating point numbers, instead of rational numbers, are used for the calculations.

Trade sequence:

Trade	For Sale	Desired	Unit Price	Inverse Unit Price
A	1.00000000 SPX	2.00000000 MSC	2.00000000 MSC/SPX	0.50000000 SPX/MSC
B	1.66666666 MSC	0.83333333 SPX	0.50000000 SPX/MSC	2.00000000 MSC/SPX

Outcome:

B is completely filled by A, and 1.66666666 MSC trade for 0.83333333 SPX.

After the trade A still has 0.16666667 SPX left for sale.

Atomic swaps between BTC/Omni

Referencing @dexX7 from OmniLayer/spec#281 (comment)

This diagram outlining @petertodd's Decentralized digital asset exchange with honest pricing and market depth post is a topic that I believe deserves its own issue.

@dexX7, you mentioned that:

this scheme, as it is, would be vulnerable to double-spending of tokens due to the balance based nature of MSC, but there are two ways around: one involving third-party trust, where the party cannot steal per se, or by introducing a new transaction type to bind tokens to an output.

I’m curious about a few things, as I am absolutely a fan of this direction. Are the two solutions above the only ones that solve the issue? If not, I’d like to hear what other options are available. If so, I’m curious what the binding of tokens to an output would need to look like.

To address the concerns of MSC, this would only affect BTC transactions with Omni tokens, not DExv2 transactions between Omni tokens and MSC, which are already atomic (we could also limit to atomic BTC->MSC swaps for simplicity sake, but that’s a bit of a stretch).

If we bind tokens to an (originally?) unknown output (assuming that an original output contained the instruction to do so), could a subsequent transaction (once the atomic swap had been completed) “unbind” it such that the value would return to the balance method (for use in other features where output-based tokens aren’t feasible)? Or would we need to bind the tokens prior to the sale offer (in the event the buyer was the one contributing the tokens (the opposite direction from the example given)?

This one opens a can of worms, for sure.

For my own education, I haven’t found a good description of how SINGLE|ANYONECANPAY transactions are handled by the p2p and clients. What gets relayed, stored for later (in case a buyer shows up), discarded and/or confirmed? Please don’t tell me they’re entirely out-of-band.