There is some discussion on how to improve the protocol, specifically the critical "free options to buy all offered XCP until they expire with a single BTC order" flaw that one alpha-tester pointed out a few days ago (resulting in a critical order-book-clearing, locking all XCP orders for their full duration).
Here is the proposal some of us support which was cleaned up and more fully described by jeremy to fix that problem and also implement some added functionality to the options system that this protocol uses such as to prevent micro-orders from burdening BTCpay'ers:
I'm heavily invested in the XCP system and want to see it succeed and do better.
MoneypakTrader offered some good solutions for fixing a few of the problems the system currently has:
https://bitcointalksearch.org/topic/m.5009075Building on those suggestions, I'd advocate the following improvements:
FIRST SUGGESTION:
All orders should include the major version number of the client issuing the order to prevent matching problems that users have experienced. The protocol should not allow matches of different major version and should inform the user if other version numbers are more popular than the one used to suggest upgrading. The new version should show the old version order book and the new version order book to allow placing orders under either systems.
Essentially these are hard forks. Older clients can still make trades with each other, but for added features and trades with new clients, it must be updated.
Again, new clients should have a feature to view and issue orders/commands at older version levels just in case significant users/orders resist the upgrades and the new client user wishes to match older version orders.
SECOND SUGGESTION:
All orders involving BTC should be able to set an optional variable [minimum] (amount of BTC for each valid match), denominated in BTC (for efficiency reasons). Leftover amounts in the order book for less than the [minimum] should be cancelled from the order book and returned to the owner AFTER ALL other fractions of that order are COMPLETELY BTCpayd for.
This works particularly well when combined with the other following improvements.
Reason:
"BTC for XCP" orders require a second "BTCpay" to complete EACH order match made, this wouldn't be an issue except:
1) Significant fees (around 40 cents/0.0004btc) are required for EACH "BTCpay" action make small transactions (<1 XCP) proportionally very expensive (as described by moneypaktrader on bitcointalk around their above linked post time).
Here's a scenario, suppose I want to spend some BTC to buy 50XCP at the best possible DEX rates and the order book looks like this:
XCP for BTC orders:
1 XCP @ 0.0040 (total costs with btcpay = 0.0044 btc/xcp, ignoring the costs to place the btc/xcp orders)
2 XCP @ 0.0041 (total costs with btcpay = 0.0043 btc/xcp, ignoring the costs to place the btc/xcp orders)
1 XCP @ 0.0042 (total costs with btcpay = 0.0046 btc/xcp, ignoring the costs to place the btc/xcp orders)
50 XCP @ 0.00425 (total costs with btcpay = 0.004258 btc/xcp, ignoring the costs to place the btc/xcp orders)
I have an incentive to place a btc for xcp order for enough quantity (or more) to buy at least all the orders through the 50 XCP order but only "btcpay" for the single 50 XCP order match which is the best price for the quantity I want.
When combined with fees per match described below, this feature is almost necessary to avoid excessive fees from numerous matches.
THIRD SUGGESTION:
Because BTC orders get the option to pay or not to complete the order,
the orders requesting BTC should be allowed to charge/receive an XCP fee for providing that option. I agree with MPT that this fee should be waived/ignored for the first matched order to prevent clogging the order book with high match fees, the BTC order will be paying sufficient network fees to justify getting a first match without a fee. Also using XCP for this fee will encourage XCP usage and drive demand for XCP by high volume traders.
New Variables needed -
A)
Orders requesting BTC have an OPTIONAL variable [fee-charged] (defaults to 0 if not set).
B)
Orders offering to pay BTC have an OPTIONAL (XCP) input [fees-provided] (defaults to 0 if not set). This is deducted from the xcp of the BTC address of the BTC offer and escrowed for use until the order completes/expires.
C)
Orders offering to pay BTC have an OPTIONAL variable [max-fee] (defaults to total fees-provided balance or 0 if not set).
How it would work -
The first otherwise valid match to a BTC order is matched with no fee deducted from B.
After the first match, B (fees-provided) and C (max-fee) must be greater than or equal to A (fee-charged) or it does not get matched and goes to the next order/match. The remaining balance of B and variable C must still be greater than or equal to each A of each future match (or A must equal 0 if B=0).
Each match after the first gets paid immediately the XCP value agreed and the balance of B is reduced accordingly. Balance of B is refunded to the BTC offer on completion/expiration of the order.
Why? "XCP for BTC" orders must wait until their order expires and currently receive no compensation for giving the option to buy to the "BTC for XCP" order for the duration of their order time. At the same time, the initial order requires some expense to create and that should be conidered enough payment to justify one free match. Also, requiring a fee for the first match would allow high fees and low prices reaulting in a strange looking order book.
FOURTH SUGGESTION:
1)
Orders requesting BTC may designate an optional variable [max-time] to btcpay (defaults to remaining expiration time):
Only BTC offering orders with less than or equal to this amount of expiration time remaining are matchable. Matches that aren't paid for in this time are returned to the order book as usual.
DECISION FOR HOW TO IMPLEMENT THIS FEATURE:
EITHER a) the max time will allow extending past the orders expiration time or b) the expiration time remaining must be greater than the max-time or the remaining orders are cancelled. It's not so important which, just must be documented which method is used.
NOTE: BTC offering orders should NOT have a second variable for lock time because they should need to know EXACTLY when they will need to plan to be online to check orders and having such a variable is too random for someone who wants to collect several matches over a few days an then pay them all by their expiration time. i.e. it would make it too unpredictable just like the current system.
FIFTH SUGGESTION:
This is possibly unnecessary with the other features, but some people might want to trade with each other so this would help them:
Allow direct order matching for the cost of the fee-charged described above.
Self explanatory, but could be from just having a new variable --buy-order XXXX and the order will only match against that order number (either matched or not).
SIXTH SUGGESTION:
There should be a variable for order persistence (or not) (should default to yes as currently provided), but some people might want their order to NOT relist after failed purchases.
In regards to other people's suggestion to simply charge more miner fees:
As MPT noted, it is wasteful to simply ask for the BTC for Asset order to burn/spend/waste BTC in miner fees, that is equivalent to asking them to piss away money for no benefit.
In regards to escrow, that does not give anyone value immediately for the immediate loss of use of the Asset. That's why the fee is better. They should be compensated directly for the option if the option is given rather than only compensated in failure to pay.
