This forces XCP orders to have their orders locked while receiving nothing unless the order is unpaid, flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).
I considered having a flat XCP fee per order match as well, but I don't think the additional complexity is worth it. Having a flat XCP fee also shifts part of the burden to honest buyers. We don't want to discourage honest buyers by slapping fees on them if we can avoid it.
Additional complexity?
A) my proposal: 1) XCP transferred to XCP orders on any secondary order matches or 2) returned if no secondary order matches are made and BTC order completes, cancels, or expires.
vs.
B) your proposal: 1) XCP transfer to XCP order matches **if no btcpay is made** (requires parsing BTCpay and order matching) or 2) transferred back to btc order if no order matches are made or 3) transferred back to BTC order if matched and btcpayed **requires parsing btcpays and matches and comparing them**.
Which is more complex again?
"slapping fees on them" ? Burden on honest buyers? Did you read my proposal? no additional fees are required at all, it's all optional and the first match NEVER has a fee "slapped" on anyone regardless of the lowest XCP seller trying to clog the book with high fees which would cause a market anomaly in your proposal but not in mine.
With my proposal, Honest buyers can look at the order book and pick an XCP order that has the volume they want and trade in one transaction using the method I propose (using minimum xcp match amount variable), NO fees required aside from the already outrageous XCP protocol fees that are slapped on them that I want removed.
The combination of improvements I suggest allows the book clogging to be minimized (first order match fee is ignored since BTC order placement requires getting a block into the bitcoin blockchain which is a sufficient hurdle to allow at least one order match).
We don't want to burden honest XCP buyers who just want to buy 200-500 XCP without clearing numerous orders with costly escrows requiring 10 different BTCpays (or sacrificing all the escrow/fees), that's why the minimum volume I propose must be allowed as a variable (due to the excessive XCP protocol fees). Please read my proposal and understand how it all comes together to help everyone involved. I'll attach it at the bottom. Feel free to clarify your position if it can make more sense.
I agree with you that if the price moves by more than the XCP-escrow-required-pct during the lock time, then the buyer can take advantage by not paying for the order. But the sellers can compensate by just setting a higher xcp-escrow-required-pct to make the option value to the buyer so low that it's not worth his time to try this attack. Honest buyers won't care about a higher escrow-required-pct.
The fact is that the market uses an option style system that is currently available at no additional fee per match, allowing the order book to be cleared for a single fee that is to none of the parties benefit. Escrow doesn't compensate the XCP seller for the lockin period provided (if the option is exercised in this period) thus forcing a distortion in pricing since the BTC order has no reason to pay immediately if they intend to complete the purchase. Why not way for the remainder of the lock time just in case the offer becomes unattractive?
Setting prices/Paying for the options beyond the first ones (if the xcp seller chooses to charge a fee) allows more accurate pricing of the orders to price the lock time while compensating the BTC order for their time/effort in placing the order and describing the minimum XCP order matches they will btcpay for.
I predict if this system is put in place xcp-escrow-required-pct can safely be set to 0 anyway because trolls would lose interest in attacking a system that recovers quickly from their attack.
we might as well not improve the protocol if we're comfortable relying on others following rules outside the protocol to limit their behavior.
Regardless, I've described improvements that allow XCP to be bought for no XCP fee while not relying on trolls to not be trolls.
I agree the current fee system should be removed, if transactions are included in a block, fees are irrelevant and wasteful. The obligation is on the BTCpay-er to ensure they get their transaction included in a block (i.e. pay 0.0001 fee). All other transactions should be frictionless with virtually ZERO fees.
Regarding fixing some of the current problems:
I'd suggest:
XCP/BTC orders can designate these new [optional] variables/fees:
1) [Optional] BTCpay lockin time in blocks as a variable for XCP orders:
****only BTC orders providing less than or equal to this time left are matchable.***
2) [Optional] BTC order lockin Fee per match(in XCP) (Ignored for first order match) allowed to be set by XCP orders (required fee) and BTC orders (maximum fee per match or match is ignored).
3) [Optional] Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match specified by BTC order in (2) above or no maximum if not set).
Secondary XCP order matches (beyond first match) are paid XCP from BTC orders (from (3) above) in exchange for the privilege of the lock in time received to do the BTCpay. Only btc orders designating a lockin fee ((2) above) more than or equal to the lockin fee required by the XCP orders ((2) above) are matchable IF the remaining lockin fees are sufficient to pay it and BTC order time to expiration is less than or equal to the lockin period specified ((1) above).
4) [optional] Minimum match amount (in XCP) as another option for BTC orders (to prevent BTCpay fee problems) since each match requires btcpay, only makes sense to let btc orders set minimum they are willing to btcpay for.
I.E. NO XCP required by BTC order for first BTC/XCP match, but optional market driven XCP requirements for additional matches.
This will help drive demand for XCP as well as fix this bug.
These changes should be incorporated so that older clients/orders will NOT match with orders that include the new variables to minimize the potential problems.
Flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).
The fees paid for the lock time should be immediately spendable by the XCP order giving the lock time, it could be a long time or short time as agreeable by the orders allowing a sort of options trading by default.
XCP buyers should be watching their order close to the expiration and they will either BTCpay or cancel orders to avoid paying the lockin fees for not enough lock time during the last few blocks. They should be able to cancel the unmatched order remainder while the matched orders will either be BTCpaid for or expire naturally (they paid for the lockin time, so no buthurt as the current situation allows).
The first order match to a btc order MUST ignore the lock fee in order to prevent clogging the order book around the trading range with high lock fees. This increases market liquidity.
Yes, this will allow clearing the first XCP order (above a certain liquidity level using the minimum option I described), but the fee paid to include a transaction in the blockchain is sufficient to justify this *AND* this will add an element of strategy to the options trading to encourage more sophisticated traders onto the platform.
The BTC order MUST be allowed to skip small orders (per my proposal (4) above) to avoid inefficient trades unless the BTC order wants to BTCpay for such inefficient trades.
I see one potential problem with the XCP escrow solution: what do we do about honest XCP buyers who want to place limit orders?
Using my proposal, they simply set a fee for the lockin period and a minimum order match quantity, free market style solution.
For the primary match (the first match to a XCP buy), the fee is ignored (cost paid to include transaction in blockchain is considered sufficient). If it is a secondary match, they receive XCP immediately for providing the lockin period.
The remaining problems such as the excessive cost for XCP transactions should be addressed when possible.
Also, to prevent LONG initial load times (currently several hours to sync and will only grow longer), an initial DB should be added to the repository each month after agreed to be legit by a sufficient number of community members. This will be necessary in another month to prevent week long sync time for slower computers.
Can someone please link to the most current description of how the asset creation/fees work?
Improvement 5) Orders seeking to receive BTC should be allowed to direct match for the cost of the lockin fee specified according to (2) above, allowing a btc order to claim the order/lockin time by directly reserving it, this would facilitate directly buying the option/order they want regardless of position on the market list. This would be more honest about the options style trading that this platform requires (when BTC is involved).
