The thing I don't like about XCP escrow is the added complexity to what should really be a very simple function.
Agree. Having more than one mechanism to penalise BTCpay defaulters adds unnecessary complexity. Plus it damages
order fungibility (the idea that any order can be matched against any other without the user having to jump through hoops.)
On the otherhand I don't see how to make large BTC Sell / XCP Buy orders reliable (troll prohibitive) but not fee inefficient without the escrow mechanism.
This is exactly what I'm attempting to address here:
https://forums.counterparty.co/index.php/topic,69.msg340.html#msg340*
the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order,
providing the required fee as any combination of XCP and BTC he prefers*
the automatic refund of XCP fees upon BTCpay settlement
If implemented, this would result in:
* the vast majority of fees being paid in XCP (any sensible client would do this automatically where ever possible,)
massively improving fee efficiency.
*
serious troll deterrence, as matching any appreciably large sum of XCP and failing to BTCpay would cost you heavily (
but it'd be free if you utilised the XCP fee and did BTCpay.)
* retained
simplicity of the fee mechanism. XCP sellers just specify a single fee. XCP buyers can match any order on the book, paying the fee with whatever they have available.
Software could automatically default optimal values very easily so that the user need never even think about fees.
I was thinking something similar - but a few questions.
* the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order, providing the required fee as any combination of XCP and BTC he prefers
Why do you think the fee should be specified as a number and not a percentage? It already seems somewhat annoying that one has to think of how to set Give/Get Asset to try and get a certain proportion; plus this the pick a number would lead to greater incongruity in order matching (as opposed to everyone using say .5%).
I was going to suggest the protocol checking if the Sell BTC Address has a positive XCP balance > the required fee, and automatically escrowing the fee in XCP, unless they do not have enough, otherwise BTC. And then a minor prompt for the GUI to inform users i.e.
One more thing - if such a solution were to be implemented - the percentage of XCP returned / debited from the escrow based on insolvency should be matched order size based; for example if a user is matched for a 1000 XCP buy, and has .5% - 5 XCP in escrow, and he is insolvent, those 5XCP are burned/used as miners fees, but if he has an order for 1000 XCP matched and is matched for 10 XCP which he fails to resolve, it should only debit him for the 10/1000 proportion *5XCP in escrow and the rest should be returned on expiration. Otherwise it will be possible for unresolved dust or near-dust sized transactions to eat away at his escrow balance.
