initial updates for OmniDex 2.0 #316
Conversation
OmniDex 2.0 updates for PR to OmniLayer
README.md
Outdated
|
|
||
| If the amount offered for sale exceeds the sending address's available balance (the amount not reserved, committed or in escrow), the transaction is invalid. The amount offered for sale, up to the amount available, must be reserved from the available balance for this address much like any other exchange platform. (For instance: If an address owns 100 MSC and it creates a "Sell Order" for at least 100 MSC, then the address's available balance is now 0 MSC, reserving 100 MSC.) After the sell order is published, any coins received by the address are added to its then current available balance, and are not included in the amount for sale by this sell order. The seller could update the sell order to include these newly acquired coins, see [Change a Transaction Type 21 Coin Sell Order](#change-a-transaction-type-21-coin-sell-order) below. | ||
| For all transaction types that involve 2 Omni Protocol currencies, the currencies must be in the same ecosystem. Amounts must be greater than zero. |
|
Looks good to me on the first scan! |
README.md
Outdated
| * 22: [Purchase Coins with Bitcoins (accept currency trade offer)](#purchase-mastercoins-with-bitcoins) | ||
| * 25: [Create an Order to Sell Omni Protocol Coins for Another Omni Protocol Currency](#create-an-order-to-sell-omni-protocol-coins-for-another-omni-protocol-currency) | ||
| * 26: [Cancel all my orders of a currency pair at a specified price](#cancel-all-my-orders-of-a-currency-pair-at-a-specified-price) |
There was a problem hiding this comment.
We haven't used 'my' to denote reader ownership previously I don't believe (eg we have "Sell Coins for Bitcoins", rather than "Sell My Coins for Bitcoins".
There was a problem hiding this comment.
I remembered why I added "my" - otherwise, it's not clear that it applies just to orders from this address. it could be interpreted as applying to ALL orders of the currency pair at the specified price. Suggestions?
How about this: Transaction type 26 cancels open orders, submitted by the address, for a given set of currencies at a given price.
|
Thanks @marv-engine it's great to see some love going back into the spec :) I've added a few notes, let me know if anything is unclear... |
|
The new transactions are part of the current consensus rules, so we should build upon this pull request and eventually integrate it. |
README.md
Outdated
| @@ -529,6 +533,95 @@ Say you see an offer such as the one listed above, and wish to initiate a purcha | |||
| |Currency identifier| [Currency identifier](#field-currency-identifier) |1 (Mastercoin) | | |||
| |Amount to be purchased|[Number of Coins](#field-number-of-coins)|130,000,000 (1.3 coins) | | |||
|
|
|||
| ### Sell Omni Protocol Currencies for Bitcoins [NEW] | |||
|
|
|||
| Description: Transaction type 21 posts the terms of an offer to sell Omni Protocol currencies, including Omni Token coins or Test Omni Token coins for bitcoins. A new sell offer is created with Action = 1 (New). Valid currency identifier values for this transaction are any Omni Protocol currencies (production or test) owned by the sending address. | |||
There was a problem hiding this comment.
Ideally, we extract and remove the action field and create a bunch of "single" transaction types, similar to the token/token exchange with:
- 25: create order
- 26: cancel orders by price
- 27: cancel orders by token id
- ...
There was a problem hiding this comment.
Given that we somehow need to have compability for the old transaction types and the "new" way is rather different, maybe let's start with a whole new number, instead of reusing and overloading the old one.
We could for example start with tx type = 30 to create a token/bitcoin order, = 31 to change one etc. (example numbers, not necessarily those)
There was a problem hiding this comment.
removed Action field; changed to new tx types 30 - 34
README.md
Outdated
|
|
||
| Description: Transaction type 21 posts the terms of an offer to sell Omni Protocol currencies, including Omni Token coins or Test Omni Token coins for bitcoins. A new sell offer is created with Action = 1 (New). Valid currency identifier values for this transaction are any Omni Protocol currencies (production or test) owned by the sending address. | ||
|
|
||
| If the amount offered for sale exceeds the sending address's available balance (the amount not reserved, committed or in escrow), this indicates the user is offering to sell all coins that are available at the time this sell offer is published. The amount offered for sale, up to the amount available, must be reserved from the available balance for this address much like any other exchange platform. (For instance: If an address owns 100 Omni Token coins and it creates a "Sell Order" for 100 Omni Token coins, then the address's available balance is now 0 Omni Tokens, reserving 100 Omni Tokens.) After the sell offer is published, any coins received by the address are added to its then current available balance, and are not included in the amount for sale by this sell offer. The seller could update the sell offer to include these newly acquired coins, see [Change an Omni Protocol Coin Sell Offer](#change-an-omni-protocol-coin-sell-offer) below. |
There was a problem hiding this comment.
For the sake of not messing with the total system's consensus and state after a block reorganization, we removed to ability to "sell more than available" some time ago. These transactions are then simply invalid.
There was a problem hiding this comment.
I had missed this. I updated my version.
README.md
Outdated
|
|
||
| The amount reserved from the available balance for this address will be adjusted to reflect the new amount for sale. Note that the amount reserved as a result of the update is based on the available balance at the time of the update plus the existing sell offer amount not yet accepted at the time of the update. | ||
|
|
||
| Say you decide you want to change an offer, e.g. the number of Omni Protocol currency coins you are offering for sale, or change the asking price. Send the transaction with the new values and the values that are not changing and Action = 2 (Update) so it is processed by OmniCore as valid before the whole amount offered has been accepted. Note that while the portion of an offer which has been accepted cannot be changed, sending an update message still has an effect, in that it affects any coins which have not been accepted, and it affects accepted coins if the buyer fails to send payment. |
There was a problem hiding this comment.
Maybe let's also give an example. Because it's somewhat unclear how exactly an order is updated: only by providing a new "amount for sale", but what about "amount desired"? Or are we just going to handle an update like:
- remove old order
- create a whole new one
My point: the user needs to recalculate the ratio of desired/for sale, if he or she wants a similar price, but less units for sale.
README.md
Outdated
|
|
||
| A currency sell offer can be canceled by using Action = 3 (Cancel) until the offer has been fully accepted by valid purchase offers ([Purchase Omni Protocol Currencies with Bitcoins](#purchase-omni-protocol-currencies-with-bitcoins)). When a sell offer is canceled, the associated coins are no longer reserved. | ||
|
|
||
| When canceling a sell offer, the values in the following fields are not tested for validity: |
There was a problem hiding this comment.
That's one of the reasons we decided to split the MetaDEx transaction types into more than one, because the cancel transactions can be shorter.
README.md
Outdated
|
|
||
| If you send a Purchase Offer for more coins than are available at the time your transaction gets added to a block, your amount bought will be automatically adjusted to the amount still available. When a Purchase Offer is sent to an address that does not have a matching active Sell Offer, e.g. the specified Sell offer has been canceled or is all sold out, the Purchase Offer must be invalidated. It is not valid to send a Purchase Offer to an address if the sending address has an active Purchase Offer (not fully paid for and time limit not yet reached) with that address for the specified Omni Protocol currency and current unit price. [WITHIN WHAT MARGIN OF ERROR???] | ||
|
|
||
| [???] Note: Your total expenditure on bitcoin transaction fees while accepting the purchase must meet the minimum fee specified in the Sell Offer in order for the transaction to be valid. |
There was a problem hiding this comment.
Correct, the accept transaction must have at minimum the specified fee.
There was a problem hiding this comment.
The phrase "total expenditure" is unclear. If someone purchases a small fraction of the amount offered for sale, how much should the transaction fee be (e.g. a proportionate fraction of the minimum fee) or the whole fee? Is the fee to be supplied for each fractional purchase from the same address?
A proportionate fee seems sensible to me.
There was a problem hiding this comment.
Related: #253
Not sure how to go from here.
README.md
Outdated
| | Transaction version |[Transaction version](#field-transaction-version) | 0 | | ||
| | Transaction type | [Transaction type](#field-transaction-type) | 24 | | ||
| | Currency identifier | [Currency identifier](#field-currency-identifier) |1 (Omni Token) | | ||
| | Current unit price | [Number of Coins](#field-number-of-coins) |1 (bitcoin) | |
There was a problem hiding this comment.
I think that line is not needed. An order can be identified exactly by only the seller's address as well as the token id for sale.
There was a problem hiding this comment.
A address may have several sell offers at different, or even the same, prices. This occurs in automated exchanges. So the question is how a particular sell offer can be uniquely identified in as little space as necessary.
There was a problem hiding this comment.
Ah, it was unclear to me that the seller can have multiple offers for the same token.. But what happens, if he or she also has multiple offers for the same token at the same price?
no more Action field, new tx's numbered 30 - 34
README.md
Outdated
| @@ -576,9 +579,13 @@ When canceling a sell offer, the values in the following fields are not tested f | |||
|
|
|||
| The cancel will apply to the amount that has not yet been accepted. The UI must indicate if the cancellation was successful and how many coins were not sold. | |||
|
|
|||
| If you want to cancel an offer, use Action = 3 (Cancel) and send the transaction so it is processed as valid before the full amount for sale has been accepted. | |||
| If you want to cancel an offer, use Action = 3 (Cancel) and send the transaction so it is processed as valid by OmniCore before the full amount for sale has been purchased with one or more Purchase Omni Protocol Currencies with Bitcoins transactions. [??? NEED TO DECIDE HOW TO UNIQUELY IDENTIFY A SINGLE OP CURRENCY SELL OFFER] | |||
There was a problem hiding this comment.
Omni Core with space, but I'm not sure, if the implementation should have a place in the specification.
README.md
Outdated
| Note that while the portion of an offer which has been accepted cannot be canceled, sending the cancel message still has an effect, in that it cancels any portion of the offer which has not been accepted, and it prevents accepted coins from being relisted if the buyer fails to send payment. The payment window behavior continues unchanged for any portion of the sell offer which has aleady been accepted. | ||
| If an address has more than one active Sell Omni Protocol Currencies for Bitcoins offers, multiple offers can be cancelled with one transaction as follows: | ||
| * specify the Omni Protocol Currency to cancel all the sender's active offers to sell that currency | ||
| * use 0 as the Omni Protocol Currency to cancel ALL the active offers from the sender's address |
There was a problem hiding this comment.
Let's create a new transaction type to "cancel all", instead of overloading.
There was a problem hiding this comment.
I understand. Will a "cancel all" tx type be consistent with how other actions are cancelled?
README.md
Outdated
| The sell offer is assigned a unique id for the life of the offer (i.e. until it is cancelled or fully accepted and paid for), even if the terms of the offer are changed in the future. The id must be different than the id's for all other sell offers that are active at the time OmniCore processes the sell offer, otherwise the sell offer is not valid. | ||
|
|
||
| The id is the hash of the following data items, in the order listed: | ||
| [??? NEED ADDITIONAL INFO ABOUT THE HASH] |
There was a problem hiding this comment.
All that data is part of the transaction that creates the initial offer and a transaction id is the hash of the whole transaction. I think we could just use the txid in that case instead of building something new, which could be very difficult to recreate.
There was a problem hiding this comment.
Does the length of txid cause any problems?
There was a problem hiding this comment.
The txid won't work, at least by itself. We need an efficient way to detect duplicate sell offers from the same address. Obviously, each txid is different even if it has the same OP content.
README.md
Outdated
| @@ -568,7 +584,7 @@ Say you want to publish an offer to sell 1000 Omni Tokens for 1.5 bitcoins. Doin | |||
|
|
|||
| ### Change an Omni Protocol Currency for Bitcoins Sell Offer | |||
|
|
|||
| Description: Transaction type 31 is used to change the terms of an existing offer from the sending address to sell Omni Protocol currencies, including Omni Token coins or Test Omni Token coins, for bitcoins. The existing sell offer is updated to have to specified new attributes. [??? NEED TO DECIDE HOW TO UNIQUELY IDENTIFY A SINGLE OP CURRENCY SELL OFFER] | |||
| Description: Transaction type 31 is used to change the terms of an existing offer from the sending address to sell Omni Protocol currencies, including Omni Token coins or Test Omni Token coins, for bitcoins. The existing sell offer is updated to have to specified new attributes. | |||
There was a problem hiding this comment.
Just as a side note, internally update orders of DEx 1 are basically three steps:
- Does the order exist? If not, fail
- Cancel the order
- Create a new order with the given data
https://github.com/OmniLayer/omnicore/blob/develop/src/omnicore/dex.cpp#L243
There was a problem hiding this comment.
Is it a problem to retain the id of the original sell offer throughout the life of the offer?
README.md
Outdated
|
|
||
| The cancel will apply to the amount that has not yet been accepted. The UI must indicate if the cancellation was successful and how many coins were not sold. | ||
|
|
||
| If you want to cancel an offer, send the transaction so it is processed as valid by OmniCore before the full amount for sale has been purchased with one or more Purchase Omni Protocol Currencies with Bitcoins transactions. [??? NEED TO DECIDE HOW TO UNIQUELY IDENTIFY A SINGLE OP CURRENCY SELL OFFER] | ||
| If you want to cancel an offer, send the transaction so it is processed as valid by OmniCore before the full amount for sale has been purchased with one or more Purchase Omni Protocol Currencies with Bitcoins transactions. |
There was a problem hiding this comment.
I don't understand this sentence.
How about unrolling it completely to something like:
Cancel an offer:
[version]: 0
[type]: 31
[sell offer identifier]: ???
Cancel all offers for a specific token/currency:
[version]: 0
[type]: 32
[currency id]: ???
Cancel all offers:
[version]: 0
[type]: 32
There was a problem hiding this comment.
I was trying to make it clear (ironic, isn't it?) that the Cancel isn't valid if there are no tokens left for sale, even if they haven't been paid for yet. I'll try again.
Convert Marv's OmniDex 2 modified Spec to AsciiDoctor
|
@marvgmail This PR needs a rebase now. Let me know if you need help with rebasing. |
No description provided.