BTC-trading is enabled on the protocol level but disabled in Counterwallet. The reason is bad user experience, or more specifically that when an order matches, the person who is supposed to transfer BTC may not do it. The result is that no trade occurs, frustration. confusion and loss of a tx fee (but no loss of assets, thankfully).
My question is if this only happens when it’s the one with the passive order who is supposed to transfer BTC?
On the contrary, say Alice puts a GAMECARD for sale at 0.1 BTC. A few days later Bob buys this GAMECARD. Is there any way this order can match unsuccessfully? I mean, can Bob somehow initiate the trade but not transfer the BTC, thus mess up Alice’s order, etc?
It’s not done well and I wish BTC Sell remained (if only after enabling it in some Settings > Advanced menu), but the majority decided to cater to the lowest common denominator.
So the order can match only if someone first created a BTC buy order (ex: sell XCP for BTC).
I think (but I don’t have time to verify that) that you can’t denominate sales in BTC in CW (but you can via the API or CLI).
Okay, I just checked: you can’t sell for BTC in CW.
As you can see as soon as one clicks Other and tries to enter BTC…, CW autocompletes the field with other CP assets, but doesn’t allow you to set BTC.
She’d have to use the API or CLI.
If the offers match, then Bob would have X blocks (I think 20, but you can see in CW Support FAQs) to send BTC in (say, using counterparty-client). If he doesn’t, then the match is cancelled and Alice’s offer is returned to the pool of offers that can be matched (as long as it hasn’t yet expired, i.e. when they were matched the offer wasn’t more than 980 blocks old; 1,000 being the default offer duration).
So Bob can only screw up Alice by constantly making matching troll orders, but don’t forget that he loses money (1%, IIRC) every time he fails to make BTC Pay (details are explained in the FAQs).
Someone could revert the patch and run a custom version of Counterwallet that allows BTC Sell.
But how do you get paid for that (estimated ~$1K/year in expenses)?
This is true also if Bob is the active part? So Bob has to make two transactions? First the order, and when this matches, he got 20 blocks to make the BTC pay?
What I was “fishing” for in the initial post was whether these two transactions could be merged into one? I suppose the answer must be no. Reason is that if both Bob and Charlie at the same time want to buy Alice’s GAMECARD, and both of them transfer BTC at the same time, the protocol can only give the GAMECARD to one of them but the protocol cannot return a BTC payment. Therefore the “BTC pay” system (one dummy tx to make the order, another to make the BTC pay after the order matches) is needed to eliminate this risk.
Yes, it’s 2 transactions from Bob’s side. The reason is that the Counterparty protocol cannot take bitcoin in escrow, so the first BTC (sell) offer is merely an offer, whereas the 2nd is the actual payment.
I haven’t tried to create a BTC buy offer and then match it with two BTC offers issued at the same time, but I would assume that whichever BTC transaction is processed first would “win”.
In theory it may be possible to be the slower guy (say, by 2 minutes) but pay a higher transaction fee and still be matched first.
Once the offers are matched, then the matched BTC seller has plenty of time to complete the payment.
When reading the topic I thought you might be interested in knowing that we finally started implementing counterparty support for our trading software. One of the goals is to reduce the friction with BTC on the DEX by automating btcpay. The software is written in C++/Qt and will talk to your local counterparty/Bitcoin stack.
We have a free paper trading version for Bitstamp available on our website http://marginsoftware.de if you want to give the software a try.
If you have any questions, ideas or foresee problems we might run into just let me know ;).