DEX anti-trolling proposal

Does the automatic BTCPay mean user has to run counterpartyd with the unlocked wallet all the time ?


Besides security issue, it discourages user to put bid order way under the market (to catch panic sell for example), which is actually good for creating market depth. There should be option to send email / or some forms of alert, well this might be better on third party software.

[quote author=romerun link=topic=69.msg669#msg669 date=1392734593]
Does the automatic BTCPay mean user has to run counterpartyd with the unlocked wallet all the time ?

Besides security issue, it discourages user to put bid order way under the market (to catch panic sell for example), which is actually good for creating market depth. There should be option to send email / or some forms of alert, well this might be better on third party software.
[/quote]

Correct - your wallet would need to be unlocked at the time counterpartyd sent BTCpay. Your options would be:

A. leave your wallet unlocked for the duration of your order, so that counterpartyd can auto-BTCpay on your behalf
B. force disable the auto-BTCpay feature (eg. with a command line option) and rely on yourself to notice the match and unlock/BTCpay manually.

I’m not against anyone exercising option B, as long as you recognise that you need to BTCpay promptly. To this end some kind of alarm / email to alert you to an order match could be useful (and probably do-able in a couple of lines of bash script polling counterpartyd every 10 minutes and sending an email when it sees an order match, if you were so inclined.)

Just as long as you’re not advocating the third option, as some people have:
C. that you should be free to delay BTCpay for a matched order until you feel convenient

That represents holding an (uncompensated) buy option against the seller’s XCP, and is important to recognise as obviously unworkable. It would be constantly gamed by buyers who only BTCpay when the market rate moves in their favour, causing the whole market to break down.

It is very important that buyers be expected to BTCpay in the shortest possible timeframe that they can reasonably be expected to do so safely. That’s currently 10 blocks, but I see no reason why it couldn’t be half that if clients could be relied upon to auto-BTCpay immediately upon a match. The lower, the better for everyone.

(note: I’m describing my proposed functionality here, not actual functionality; AFAIK auto-BTCpay is currently unimplemented in counterpartyd.)

Cross-post: https://forums.counterparty.co/index.php?topic=132.0

[quote author=techo051 link=topic=69.msg428#msg428 date=1392146534]
I don’t know if this is possible, but can a new BTC address be automatically created for escrow, with the private key somehow hidden or inaccessible to anyone until the BTCpay has been confirmed (perhaps with the private key distributed across a few nodes in the network or something similar)? I picture it working something like this:


1.[size=7pt][font=times new roman]      [/font][/size]Bob (XCP buyer) places an order to buy 200 XCP for 1 BTC.
2.[size=7pt][font=times new roman]      [/font][/size]Bob’s 1 BTC is transferred automatically to an account with a hidden private key (NB: not sure exactly where this private key would reside during the escrow period).
3.[size=7pt][font=times new roman]      [/font][/size]Mary (XCP seller) places an order to sell 100 XCP for 0.5 BTC.
4.[size=7pt][font=times new roman]      [/font][/size]100 XCP of Mary’s order is matched to Bob’s original order.
5.[size=7pt][font=times new roman]      [/font][/size]XCP protocol automatically sends the 100 XCP to Bob.
6.[size=7pt][font=times new roman]      [/font][/size]Once the XCP transfer is confirmed, 0.5 BTC are sent to Mary, the other 0.5 BTC stay in escrow until the rest of Bob’s order is matched, cancelled by Bob, or expires. Or, since the private key has now been used, perhaps they are transferred to a new address created in the same way described above. 


The critical part of this whole transaction is in point 2 above. Is there any way to have the escrow address be created in a trustless manner and have the private key distributed across a few nodes or in another way that makes it inaccessible to anyone until the order is matched? If this is possible than I don’t see why the steps outlined above couldn’t be implemented.
[/quote]
Sounds great idea to completely remove BTCpay and trolls and fees altogether. Not sure about how implement automatic escrow of BTCs with hidden private numbers…