-
- | 0 |
- Will equal on |
- 32 |
- Will equal on or before |
-
-
- | 1 |
- Will not equal on |
- 33 |
- Will not equal on or before |
-
-
- | 2 |
- Will exceed on |
- 34 |
- Will exceed on or before |
-
-
- | 3 |
- Will not exceed on |
- 35 |
- Will not exceed on or before |
-
-
- | 4 |
- Will be below on |
- 36 |
- Will be below on or before |
-
-
- | 5 |
- Will not be below on |
- 37 |
- Will not be below on or before |
-
-
-
- | 6 |
- Bullish Contract for Difference |
- |
- |
-
-
-
- | 7 |
- Bearish Contract for Difference |
- |
- |
-
-
-
-A "Contract for Difference" (CFD) allows a bettor to temporarily gain bullish or bearish exposure to a price movement, in direct proportion to that movement. A bettor who creates a bullish CFD on Gold with 1x leverage (65536) will receive 10% of the counter-wager funds if Gold rises 10% during the period of the bet. If instead Gold falls 10%, the bettor loses 10% of his own money at stake. As with normal bets, 0.5% of the total pot goes to the creator of the data stream before winnings are determined.
-
-CFD bets store "leverage" in place of the data used by "bet threshold" in other bet types. If a bettor prefers that a 10% price movement means a 20% gain or loss, they may select 2x leverage (65536\*2=131072). Similarly, a 10% price movement could mean a 5% gain or loss using 0.5x leverage (65536\*0.5 = 32768). Just as with normal bets, a CFD bettor can "sweeten the deal" by offering better odds (a lower counter-wager amount). High-leverage bets or big price movements could result in a winnings calculation higher than the amount at stake, in which case the winner simply gets the entire pot.
-
-### Accepting a Bet
-
-Say you see a bet which you would like to accept. Simply publish the inverse bet with matching odds and the same end date, and the Omni Protocol will match them automatically (that is, everyone parsing Omni data will mark both bets as accepted). Here is what a bet matching our last example would look like:
-
-1. [Transaction version](#field-transaction-version) = 0
-1. Transaction type = 40 for creating a bet offer (32-bit unsigned integer, 4 bytes)
-2. Bet Currency identifier = 5 for USDCoin (32-bit unsigned integer, 4 bytes)
-3. Data Stream identifier = 3 for the Gold ticker, per our data stream example (32-bit unsigned integer, 4 bytes)
-4. Bet Type = 34 for “Will exceed on or before” (See table above) (16-bit unsigned integer, 2 bytes)
-5. Bet threshold (Non-CFDs only) = 200,000 (0.00200000 BTC, which equates to a ticker value of 20 per our data stream example) **OR** Leverage (CFDs only) = 65536 (1x leverage) (32-bit unsigned integer, 4 bytes)
-1. [Settlement Date](#field-utc-datetime) = January 1st, 2215 00:00:00 UTC (8 bytes)
-7. Amount of wager = 5,000,000,000 (50.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)
-8. Amount of counter-wager = 10,000,000,000 (100.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)
-
-
-
-Note that this bet will be matched against only half of the previous example, because while the odds match (2:1 vs. 1:2), the amount of this bet is for less. This bet is only for $50, so would only win $100 if they win, as opposed to the full $200. Once the bets are matched, the first bet still has $100 available for someone else to bet $50 against.
-
-Once GoldCoins reach a value of 20 or the bet deadline passes, the bet winner gets 99.5% of the money at stake. The other 0.5% goes to the creator of the data stream. When using currencies other than Mastercoin, a small fee will be deducted (see [fees](#fees) above).
-
-## Distributed E-Commerce
-
-The Omni Protocol allows for the buying and selling of physical goods in a sort of distributed classified ads system, with purchase money held in escrow by the protocol. Some might call this a "distributed e-bay", while the cynical might call it a "distributed silk road". Due to the potential for black-market uses of this feature, we encourage our users to know and follow the laws of their respective jurisdictions.
-
-### Listing Something for Sale
-
-Say you want to sell a Bible for 0.001 Mastercoins. Creating a sell offer will use a variable number of bytes due to the use of null-terminated strings:
-
-1. [Transaction version](#field-transaction-version) = 0
-2. [Transaction type] = 60 for sale listing (16-bit unsigned integer, 2 bytes)
-3. Currency identifier of price = 1 for Mastercoin (32-bit unsigned integer, 4 bytes)
-4. Desired price = 100,000 (0.00100000 Mastercoins) (64-bit unsigned integer, 8 bytes)
-5. Item category = "Contraband\0" (11 bytes)
-6. Item subcategory = "Forbidden Books\0" (16 bytes)
-7. Item title = "Bible, NASB\0" (12 bytes)
-8. Description/Notes = "tinyurl.com/kwejgoig\0" (21 bytes) (Please save space in the block chain by linking to your description!)
-
-Every sale offer published by a given address gets a 32-bit "Listing ID" number assigned, which increments for each item offered for sale from that address. We'll assume this is the first item offered for sale from this address (Listing ID=0).
-
-To delist an unsold item, publish the exact same message, but with a price of zero. Sellers should make sure they provide some method of contacting them (for instance, on the listing webpage), so they have a communication channel to help resolve disputes with buyers.
-
-### Initiating a Purchase
-
-Say you see the Bible listed above and wish to purchase it. However, you have no reputation as a buyer, so you want to offer a 10% higher purchase price than what the seller is asking. You want your purchase offer to expire in 3 days, which is 259200 seconds. Starting the purchase process takes 20 bytes. The optional comment field adds additional bytes:
-
-1. [Transaction version](#field-transaction-version) = 0 (2 bytes)
-2. [Transaction type] = 61 for Initiate purchase from listing (16-bit unsigned integer, 2 bytes)
-3. Listing ID = 0 (the ID for the listing above) (32-bit unsigned integer, 4 bytes)
-4. [Offer Valid For](#field-time-period-in-seconds-future) = 259200 seconds - 3 days (4 bytes)
-5. Offered price = 110,000 (0.00110000 Mastercoins) (64-bit unsigned integer, 8 bytes)
-6. Comment = "I really want this book!\0" (25 bytes)
-
-The reference address points to the address which listed the Bible for sale with the currency identifier set to 1 (Mastercoin). The seller now has 3 days to accept this buyer's before the offer expires. The buyer's money is now locked in escrow until their offer expires or the purchase is complete.
-
-The purchaser may also offer less than the suggested price. This may be viable for an established buyer and/or a stale listing.
-
-The comment field can be used by the prospective buyer to communicate with the seller either a message, link to a public key, link to a shipping address, email address, plea to accept the lower price, or the answer to a question the seller included with their sale offer.
-
-### Accepting a Buyer
-
-If you see an offer that you like, you can initiate a transaction to accept the offer. For any offers that you do not wish to accept because the buyer offers a bad price, has a bad reputation, or has no reputation, then you simply do not accept that specific transaction
-
-The message to accept the offer takes X bytes:
-
-1. [Transaction version](#field-transaction-version) = 0
-1. Transaction type = 62 for Accept buyer offer (32-bit unsigned integer, 4 bytes)
-2. Which buyer = 2 (3rd offer received) (16-bit unsigned integer, 2 bytes)
-
-Once a buyer has been accepted, the seller may ship the Bible. When using currencies other than Mastercoin, a small fee will be deducted (see [fees](#fees) above).
-
-
-### Leaving Feedback
-
-Once a buyer has been accepted, they may release funds held in escrow (or destroy those funds) and leave feedback. To do so takes a variable number of bytes due to the use of a null-terminated string:
-
-1. [Transaction version](#field-transaction-version) = 0
-2. [Transaction type] = 63 for Release Funds and Leave Feedback (16-bit unsigned integer, 2 bytes)
-3. Listing ID = 0 (the ID for the listing above) (32-bit unsigned integer, 4 bytes)
-4. Tip percentage = 5 (Offered price + (Offered price * (Tip percentage / 100))) (8-bit unsigned integer, 1 byte)
-5. Text feedback = “tinyurl.com/kwejgoig\0” (21 bytes) (Please save space in the block chain by linking to your feedback!)
-
-The reference address points to the address which listed the Bible for sale. Funds which are not released are permanently destroyed. Specifying more than 100% signifies an additional tip beyond the funds held in escrow. Funds are released automatically after 60 days if the buyer never leaves feedback. In addition to the text feedback, each transaction gets "1 star" to "5 stars" based on the following criteria:
-
-* 1 Star: All funds destroyed (very unhappy customer)
-* 2 Stars: Some funds destroyed
-* 3 Stars: No funds destroyed, no tip
-* 4 Stars: Tip < 10%
-* 5 Stars: Tip >= 10%
-
-In order to avoid people gaming the reputation system, some coins must be destroyed with every purchase. The percentage of coins destroyed goes down with each new purchase. The percentage is calculated as (value of this purchase) / (2 \* value of all purchases, including this one). Note that this formula causes 50% of the coins from the first purchase to be destroyed.
-
-## Escrow-Backed User Currencies (experimental proposed feature)
-
-The most important and also the most controversial feature (at least the escrow backed part) of the Omni Protocol is the built-in support for users to create their own currencies out of existing Mastercoins. For the purposes of demonstrating how user currencies will work, we will use an example currency called “GoldCoins”, which are intended to track the value of one ounce of gold, and which may be stored, transferred, bought, and sold similarly to Mastercoins.
-
-### Stability Concept
-
-So how do we drive the value of these GoldCoins to their target value, when demand for them may surge and decline? The price of GoldCoins is decided by the balance of supply and demand. Since we can’t control the demand for GoldCoins, we must control the supply. The key to accomplishing this is to use an escrow fund which holds Mastercoins, as shown below:
-
-
-
-The escrow fund operates like a battery on the power grid, charging when there is excess energy then discharging where there isn't enough. When there are too few GoldCoins (GoldCoin price is too high), the escrow fund releases new GoldCoins, and the escrow-battery “charges” by holding Mastercoins in escrow. When there are too many GoldCoins (GoldCoin price is too low), the escrow fund purchases some of the excess GoldCoins, thereby “discharging” the escrow-battery as it releases the stored Mastercoins.
-
-### New Currency Creation
-
-Say you want to create the GoldCoin currency described above, using the Gold data stream we defined. Doing so will use a varying number of bytes, due to the use of a null-terminated string. This example uses 38 bytes:
-
-1. [Transaction version](#field-transaction-version) = 0
-1. Transaction type = 100 for creating a new child currency (32-bit unsigned integer, 4 bytes)
-1. Data Stream identifier = 3 for the Gold ticker, per our data stream example (32-bit unsigned integer, 4 bytes)
-1. Escrow fund delay = 4 for 4 days (see below) (8-bit unsigned integer, 1 byte)
-1. Escrow fund aggression factor = 1,000,000 for 1% (See below) (32-bit unsigned integer, 4 bytes)
-1. Currency Name = “GoldCoin\0” (9 bytes)
-1. Escrow Fund Initial Size = 100,000,000,000 for 1,000 Mastercoins (64-bit unsigned integer, 8 bytes, causes 1,000 Mastercoins to be debited from the currency creator and credited to the escrow fund. This number should not exceed the amount owned by the creator, but if it does, assume they are crediting all their Mastercoins to the escrow fund)
-1. Escrow Fund Minimum Size = 99,000,000 for 99% (32-bit unsigned integer, 4 bytes, if the escrow fund value is ever less than 99% of all GoldCoins, the currency is dissolved and the escrow fund is distributed to GoldCoin holders who would take a 1% loss)
-1. Sale/Transfer Penalty = 100,000 for 0.1% (32-bit unsigned integer, 4 bytes, any time GoldCoins are sold or transferred, 0.1% are destroyed, which improves the health of the escrow fund)
-
-
-As with properties, currencies are awarded currency identifiers in the order in which they are created. Mastercoin is currency identifier 1 (bitcoin is 0), and Test Mastercoins have currency identifier 2, so if GoldCoin is the first Omni Protocol currency, it will get a currency identifier of 3.
-
-The currency held in escrow is the parent currency of the data stream. In this example it is Mastercoins, but it could also be any Omni Protocol currency. For instance, GoldCoins could later be held in escrow to support a currency whose data stream uses GoldCoins as a parent currency.
-
-The escrow fund delay of 4 days means that the price of GoldCoins must be too high (or too low) for 4 days in a row before the escrow fund will take any action.
-
-The escrow fund aggression factor determines how aggressively the escrow fund corrects the price of GoldCoins when their price diverges from their target. An escrow fund with aggression factor of 0 will never take any action. If the aggression factor is 100%, the escrow fund will take the maximum possible action (buying every GoldCoin for sale above the target price, or selling new GoldCoins to every buyer below the target price).
-
-In the case of a 1% aggression factor, the escrow fund's first action will be to fix 1% of the error. If the error the next day is still in the same direction, the escrow fund will fix 2% of the error, then 3% the next day, and so on until it reaches 100% or the error changes direction. Once the error changes its direction, the escrow fund has done its job and it starts counting again from zero.
-
-The fields Escrow Fund Initial Size, Escrow Fund Minimum Size, and Sale/Transfer Penalty were added in response to the “bytemaster/d’aniel attack”, which becomes possible once malicious actors are able to short these currencies. The attack only works on currencies with underfunded escrows, and consists of a malicious actor creating a competing GoldCoin with a healthy escrow fund, which the market would presumably prefer over the GoldCoin with the unhealthy escrow fund. The malicious actor could then profit by shorting the unhealthy GoldCoin until people panicked and fled for the healthy version. More information about unhealthy escrow funds can be found in the next section.
-
-### Unhealthy Escrow Funds
-
-What if the price of Mastercoins falls 95%, and the value of the escrow fund is now only 5% of the target value of all GoldCoins? Using the battery analogy, this escrow fund now has less “charge” and is therefore less capable of intervening to correct prices.
-
-If the currency creator had set the minimum escrow size to 100% the escrow fund would never get into this situation because it would simply dissolve and pay out to currency stakeholders as soon as the escrow fund value dropped to parity, with zero or minimal losses. For currencies which are set up to allow continued operation once unhealthy, the protocol responds by adjusting the aggression factor accordingly. In the example of GoldCoins backed by only 5% given above, the 1% aggression factor would be multiplied by 5% to get 0.05%, meaning that the adjustments will be of much smaller magnitude, and it will take a lot longer to get to 100% aggression.
-
-Note that escrow funds holding funds worth more than their currency do not get more aggressive. That is, if the GoldCoins escrow fund is worth twice the value of all GoldCoins in existence, the aggression factor is still 1%.
-
-### Maintaining Escrow Fund Health
-
-Given a reasonably stable Mastercoin, escrow funds should generally grow healthier over time. Our GoldCoin escrow fund, when it does act, is buying GoldCoins when they are cheap, and selling them when they are expensive. Thus it will generally tend to make a profit, and the Mastercoins held by the escrow fund will grow. The larger the escrow fund, the lower the chance of the currency failing to maintain its value. Additionally, the currency creator can optionally supply initial escrow funds if desired, and the currency can be tuned to destroy some GoldCoins with every sale or transfer, further increasing escrow fund health.
-
-When an escrow fund is unhealthy, lowering the aggression factor makes the escrow fund take more profitable trades, which increases the likelihood of recovery. For instance, if it is buying excess GoldCoins, the cheapest 0.05% can be purchased at a better average price than the cheapest 1% on the market.
-
-Escrow funds should generally be tuned to act slowly. This will allow arbitrage traders to do the heavy lifting, as the knowledge that the escrow fund will eventually get the price back to the target makes for a self-fulfilling prophecy when traders act on that knowledge. If the escrow fund acts too quickly, it loses money when the bitcoin version of a security leads the real-world version, as would happen if someone was engaging in insider trading anonymously using the bitcoin version.
-
-
-
-# Appendix A – Storing Omni Protocol data in the blockchain
-By Zathras, Copyright © 2013 The Mastercoin Foundation
-
-The following appendix serves to detail the different approaches to storing Omni transaction data in the Bitcoin blockchain along with their validity requirements and use cases.
-
-This appendix will not discuss the varying types of Omni Protocol transactions or what the transaction data contains (these are defined in the main body of the Omni Protocol Specification) and will focus solely on transaction data storage.
-
-For the purposes of a simplified overview, parties wishing to develop Omni software should support the decoding of both Class A and Class B transactions, but only need support encoding of Class B transactions.
-
-Note that for all transaction classes, we have some unused "padding" bytes at the end of most messages. Those bytes are undefined (they are ignored, so they can have any value).
-
-## Class A transactions (also known as the ‘original’ method)
-
-Class A transactions were the first class of Omni Protocol transaction and store data in the blockchain by utilizing fake Bitcoin addresses to encode transaction data.
-
-The transaction data is encoded into said fake Bitcoin address which is then used as an output in a single Bitcoin transaction satisfying the following requirements:
-
-* Has a single or the largest pay-to-pubkey-hash or pay-to-script-hash (since block height 322000) input with a valid signature to designate the sending address
-* Has an output for the recipient address (the 'reference' address)
-* Has an output for the exodus address
-* Has an output for the encoded fake address (the 'data' address)
-* Should have all output values above the 'dust' threshold (0.00005460 BTC as of Q2 2014) and preferable be equal.
-* Has exactly two non-Exodus outputs (one of which must be the data address) with a value equal to the Exodus output and/or has exactly one output with a sequence number +1 of the data address for reference output identification
-* Additional outputs are permitted for the remainder of the input (the 'change' address)
-
-Further:
-
-* Exodus outputs are ignored in decoding
-* Any input not meeting the requirement for type (pay-to-pubkey-hash or pay-to-script-hash) will trigger the invalidation of the transaction
-* Only pay-to-pubkey-hash and pay-to-script-hash outputs will be considered for the reference address
-* Pay-to-script-hash output addresses will be the opaque script-hash address and not assume any decomposition into addresses which may be used in the redemption of such outputs
-* Pay-to-script-hash is enabled since block height 322000
-
-NOTE: The sequence number for a given address is defined as a 1 -byte integer stored as the first byte of each 'packet'. Sequence numbers are continuous with 0 following 255 (256=0, 255+1=0).
-
-NOTE: Should a transaction result in an edge case that provides conflicting reference address values for sequence numbers and equal outputs, the reference address identified via equal outputs will take precedence.
-
-As there is no private key associated with these fake addresses they are inherently unspendable. This creates concerns around blockchain bloat, especially within the UTXO (Unspent Transaction Output) set as each use of a fake address adds an unspent output to the UTXO dataset that will never be redeemed, thus growing (or ‘bloating’) it.
-
-As the UTXO set is designed to be memory resident it is thus in the interests of Bitcoin to avoid UTXO bloat to minimize the memory requirement for client implementations.
-
-Class B transactions were developed to address this issue by using provably redeemable outputs. Class A transactions are thus considered deprecated and are supported for backwards compatibility only.
-
-NOTE: Class A transactions are restricted to the ‘simple send’ transaction type only. All other Omni transaction types are supported by Class B transactions only. Client implementations should utilize Class B for all transaction types, including ‘simple send’.
-
-## Class B transactions (also known as the ‘multisig’ method)
-
-Class B transactions attempt to address the UTXO ‘bloat’ issue by storing data in the blockchain by utilizing ‘1-of-n’ multisignature outputs where one of the signatories is the sender or another public key address the sender has designated.
-
-By adopting a ‘1-of-n’ approach (credit Tachikoma @ bitcointalk) we can increase n to the number of packets (public keys) needed to store the transaction data while maintaining the ability of the sender or their designated party to redeem the output.
-
-NOTE: The reference client currently supports a maximum value of 3 for n. As one signatory should be the sender for redemption purposes, there is a current limit of 2 data packets per output. A number of multisig outputs can be combined to increase the space available for transaction data as required. On decoding all Omni Protocol packets from all multisig outputs are ordered via their sequence number and evaluated as a continuous data stream.
-
-Transaction data is encoded into one or a number of compressed public keys which are obfuscated and then should have their last byte manipulated to form a valid ECDSA point. These compressed public keys then can be included as signatories in a multisig output ordered by their sequence number.
-
-The size of an Omni Protocol packet in a compressed public key is thus 31 bytes (33 bytes minus the first and last bytes for the key identifier (02) and ECDSA manipulation byte). The Omni Protocol packet reserves the first byte for the sequence number, providing a total of 30 bytes per packet for Omni Protocol transaction data. The range of sequence numbers in a Class B transaction is 1 to 255, providing for a total 7,650 bytes maximum actual transaction data storage per Omni Class B transaction.
-
-Sequence numbers are again used to order the packets (again first byte of the packet), however as we no longer need to use sequence numbers to identify the recipient (reference) address we are able to start the sequence at one (we do not start the sequence at zero due to our need for a positive sequence number in obfuscation).
-
-Obfuscation is performed by SHA256 hashing the sender's address S times (where S is the sequence number) and taking the first 31 bytes of the resulting hash and XORing with the 31 byte Omni packet. Multiple SHA256 passes are performed against an uppercase hex representation of the previous hash.
-
-EXAMPLE: The following provides example output for an obfuscated Omni packet (where and XX is the last byte reserved for ECDSA point validity manipulation):
-