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.
