[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[PhantomPhreak]

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

Maybe someone else can think of something. . .

To the Dev/s:
The following counterpartyd protocol/CLI issues should be resolved:
FIX:
a) XCP for BTC offer should include an option/variable to limit block period for a matching order lock (lockperiod) and a failure to BTCpay in such time period should reinstate the temporarily locked offer (instead of canceling as it currently does)

This would prevent total wiping and make it temporary at best (10 blocks ~ 90 minutes, shorter for greater persistence).
many other options, but this resolves multiple issues at once.

My point IN RE FEES, is there should be NO FEES outside of OPTIONAL transaction fees if people choose to pay them, thus allowing XCP to be more usable.

Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network.

wrong:
https://blockchain.info/block-index/465919/00000000000000006e1a275bff2757913c4513c7e361ccb19ee6f2734ba1e8f1
click advanced at bottom, and starting at bottom of page you will see MANY bitcoin transactions with NO FEE, AKA 0 FEE.

The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended)
Hopefully counterpartyd will support spending of these outputs natively at some point.

Currently they are spent and at some point in the future, it is theoretical that we may get them back.
On my balance statement I can only mark it as an expense for now.

2) no BTCSend support outside of BTCPay
b) Improve: Allow counterpartyd BTCsend fromaddress toaddress BTC fee(optional/can use default)
c) Improve: Allow BTCSend and XCP at same time to an address
d) BONUS: Allow BTCSend to ASSET which divides the BTC among all asset holders similar to how XCP dividend should be distribued

3) Escrowed/Multisig Bitdust is unspendable in counterpartyd.
a) fix: allow spending such dust natively in counterpartyd

4) MINOR: market display updates.
a) Reorganize market CLI to display Feeds, then Bets, then Open Orders with BTC/XCP & XCP/BTC orders and Order matches awaiting BTCpay LAST in chart.
b) Update sorting open orders by asset exchange type first (XCP/BTC, etc.), then ratio second (subsorting inside the different types). i.e. force XCP/BTC BTC/XCP last in chart for easier viewing.

5) Regarding Major Program/Protocol revisions: Please don't change significant aspects of the protocol (such as asset fees) without consulting stakeholders.
Specifically In Re: Asset creation fees: Where does this new fee go? Ideally it would be either extinguished (to the burn address) or distributed among all XCP stakeholders.

Crossposted to my own thread:

We have enabled a simple DEX trading option/platform to expand people's options and hopefully gain that market share (of allowing non-technical bitcoin holders to invest in or send XCP/DEX). This is an innovative and unique service similar to our MP/BTC trading services. Anyone with the private key for their BTC address can buy XCP/MPTSTOCK by sending BTC to our specified address (see our forum thread or website). We then spend the BTC on the DEX to buy XCP/MPTSTOCK which is sent (minus 10% commission) to the Buyer's address.
Essentially - Anyone can buy XCP/DEX Assets by sending bitcoins from their bitcoin client to our current XCP buy address (shown on both our site and our bitcointalk thread for redundancy). This will work for any client/address which the buyer has the private key for (pretty much all BTC clients except exchange accounts).
When our messenger (TC and/or FB) shows green, this service is available for rapid processing at a premium. Otherwise, our goal is to process all such transactions within 24-48 hrs. Frequency of trades will depend on volume of submitted orders.

THANKS to all the Dev's!

It seems like these ideas are not under consideration, yes?

Right now BTCpays are allowed until one of the matched orders expires. Changing this is a real possibility.

Fees =/= min. dust output size. Transactions with multi-sig outputs that aren't at least .0001086 BTC in size are not delayed---they are flat-out rejected by the Bitcoind network.

If you don't want to pay the .0001 BTC transaction fee, change the appropriate line in config.py. The Counterparty protocol doesn't care.

Your previous suggestions are under consideration.

[PhantomPhreak]

Um.. I think a troll ate the order book:

http://blockscan.com/order.aspx?q=3336

I hereby submit a bug: Orders for BTC should check balance of address before submission.

If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of.

The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address.

Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses.

But that's a client-side check. Anyone can craft their own raw transaction to get around that.

EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have

+1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive.

It's not even a question of crafting a raw transaction, but rather of deleting one line of Python code.

Alright, you've made your point and I agree. How about moneypaktrader's suggestion though? A lockin period + the ability to reinstate orders automatically?

Also is fee_required / fee_provided deducted at the time of match, or btc payment? If the latter, then that approach is also useless, because someone could simply put an absurdly high fee and not intend to actually pay it.

This is kind of similar to the asset name issue we had a while back...

Orders are reinstated automatically now. The issue is that users are given a long time to make the BTC payments.

fee_required and fee_provided both refer to Bitcoin transaction fees paid to miners immediately.

[mtbitcoin]

Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP

Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).

+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed ( XCP or btc) and refunded after a btcpay is successfully completed.

Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees.

[PhantomPhreak]

Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP

Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).

+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed and refunded after a btcpay is successfully completed.

Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees

Then one would need to own XCP before being able to buy XCP on the distributed exchange (with BTC).

[mtbitcoin]

Another suggestion:
Require 1XCP to be escrowed for each order match beyond the first, which is returned on successful BTCpay, otherwise it goes to the person whose order was offline for the lockin period?
Thus a new BTC order must be submitted for EACH order to be wiped unless they escrow XCP

Edit: or even 0.01 XCP to be escrowed.
Obviously such a change should be implemented at a certain block number in future to allow people to prepare for the changeover.
Those are several of the glaring problems I see (order wiping, High fees, etc.).

+1 going forward we will need to work on mechanisms to prevent intentional abuse and trolling. A small value of 0.1 or perhaps a percentage value of the XCP purchased could be escrowed and refunded after a btcpay is successfully completed.

Failing which these coins are distributed among the matched orders that are not paid or just burnt as fees

Then one would need to own XCP before being able to buy XCP on the distributed exchange (with BTC).

Yes ...I noticed that after posting which is why I edited my post. Could a small value of btc be locked up then as fees transaction fees

Going forward I wonder if some sort of reputation system could be placed depending on order history of the address. Perhaps when placing an order another requirement I.e fee-required ..could rep_required=5. Meaning an address that is correctly completed 5 successful btcpay orders are only allowed to match

The above is a simplistic example but something similar could be worked on. Alternatively orders with escrowed XCP are categorized differently and sellers can specify that they will only want to match with purchasers that have XCP escrowed

I think going forward it's quite obvious that using the platform for anything even closely resembling hft would be unpractical so the additional requirements before placing an order can be accepted

[gacrux]

Heads up, I see some more invalid order matches:

3288   284402   1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb   2014-02-06 05:29:18   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3286   284391   1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx   2014-02-06 04:26:13   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3285   284390   1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN   2014-02-06 04:14:45   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3282   284386   1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN   2014-02-06 04:26:07   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...

Someone needs to update their client?

Holy crap, that's me! Well, 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx and 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN at least. Wish I'd seen this thread earlier :-(

Already posted about this here:
https://bitcointalk.org/index.php?topic=406408.20
And here:
https://forums.counterparty.co/index.php/topic,2.0.html

I thought I was up to date. I cloned from master yesterday. Did a git pull from ~/counterpartyd today, but forgot to also run git pull in ~/counterpartyd/dist/counterpartyd , which I'm guessing is what has bitten me.

Would you do another test purchase now, so that I can be absolutely sure that the problem has in fact been fixed for you? As stated, the devs will compensate you for the BTC you send in those transactions.

That's mighty kind of you; thank you! I'll PM you the relevant txns on the Counterparty Forums regarding your offered reimbursement, which is much appreciated.

I have pulled from master and attempted another purchase to help you test:
http://blockscan.com/order.aspx?q=3337

However, with 6/10 blocks to go until expiry, my offer (buy 5 XCP @ 0.005 BTC per each) so far remains unmatched

At the time I posted my buy order there were no sell orders within an order of magnitude of it. It appears that somebody has swept the order book clean with a ridiculously large offer (which they presumably don't intend to fulfil with BTCPAY) in order to get the front page of blockscan.com to display:
Last DEX Matched Price :     1000.0000 BTC/XCP @ $756,500.000

I can try another test buy later, once the order book straightens itself out. Hope this helps.

I'm not sure there's an easy way to mitigate this attack - does anyone who wants to match my order get automatically matched against the ridiculously high fake one first? I guess they could require a higher fee... and I could pay a higher fee....?

[porqupine]

Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.

[mtbitcoin]

Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.

It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system.

I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is  here is 'optional' escrow.

[PhantomPhreak]

Heads up, I see some more invalid order matches:

3288   284402   1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb   2014-02-06 05:29:18   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3286   284391   1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx   2014-02-06 04:26:13   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3285   284390   1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN   2014-02-06 04:14:45   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...
3282   284386   1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN   2014-02-06 04:26:07   023d390307488909fc6b05a37a3335...   Invalid: invalid order match ID, 023d390307488909f...

Someone needs to update their client?

Holy crap, that's me! Well, 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx and 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN at least. Wish I'd seen this thread earlier :-(

Already posted about this here:
https://bitcointalk.org/index.php?topic=406408.20
And here:
https://forums.counterparty.co/index.php/topic,2.0.html

I thought I was up to date. I cloned from master yesterday. Did a git pull from ~/counterpartyd today, but forgot to also run git pull in ~/counterpartyd/dist/counterpartyd , which I'm guessing is what has bitten me.

Would you do another test purchase now, so that I can be absolutely sure that the problem has in fact been fixed for you? As stated, the devs will compensate you for the BTC you send in those transactions.

That's mighty kind of you; thank you! I'll PM you the relevant txns on the Counterparty Forums regarding your offered reimbursement, which is much appreciated.

I have pulled from master and attempted another purchase to help you test:
http://blockscan.com/order.aspx?q=3337

However, with 6/10 blocks to go until expiry, my offer (buy 5 XCP @ 0.005 BTC per each) so far remains unmatched

At the time I posted my buy order there were no sell orders within an order of magnitude of it. It appears that somebody has swept the order book clean with a ridiculously large offer (which they presumably don't intend to fulfil with BTCPAY) in order to get the front page of blockscan.com to display:
Last DEX Matched Price :     1000.0000 BTC/XCP @ $756,500.000

I can try another test buy later, once the order book straightens itself out. Hope this helps.

I'm not sure there's an easy way to mitigate this attack - does anyone who wants to match my order get automatically matched against the ridiculously high fake one first? I guess they could require a higher fee... and I could pay a higher fee....?

Your new order has been matched.

[jimhsu]

Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.

It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system.

I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is  here is 'optional' escrow.

+1. Once we stop caring that a buyer needs XCP to buy XCP there is a lot that's possible. Optional XCP escrow released upon successful BTCPay is another great idea.

Where would XCP be without mtbitcoin...

I am starting an mtbitcoin fan club. Not to be confused with mtgox.

I would say the most immediate change should be a lockin parameter to directly address the inability to get XCP back in a short timeframe from this attack.
We can then implement some sort of (optional) XCP escrow system, and then followed by a reputation system in the indeterminate future. To allow new buyers to currently buy XCP, allow single orders to be bought without regard to the escrow requirement. All of these things will of course need to be thoroughly tested.

[porqupine]

Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.

It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system.

I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is  here is 'optional' escrow.

I didn't mean a burn period Proof of Burn - but rather a fee based Proof of Burn for initializing an XCP buy order for a new address without XCP. (And then you could use the escrow method once an XCP balance for the address exists).

[MoneypakTrader.com]

Requiring people to pay extra mining fees is wasteful.
I'd suggest:

XCP/BTC orders can designate these new variables/fees:
1) BTCpay lockin time in blocks as a variable for XCP orders:
****only BTC orders with less than or equal to this time left are matchable.***
2) BTC order lockin Fee (in XCP) (Ignored for first order match) allowed to be set by XCP orders and BTC orders.
3) Optional Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match in (2) above or no maximum if not set in 2 above).
4) XCP orders (beyond first match) in order are paid from the XCP paid in exchange for the privilege of the lock in time received to BTCpay. Only btc orders designating lockin fee more than or equal to the lockin fee required by the XCP orders are matchable IF the remaining lockin fees are sufficient to pay it.
5) 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 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.

Moving the XCP encoded transactions to a method that doesn't require BTC should be a high priority to allow the possibility of XCP trading using the absolute minimum of BTC fees required, ZERO in some cases if BTC is sent to senders address from sufficiently aged blocks.

But anyways, this is something that people should be given a few days to prepare for and be implemented at a specific block number. The core protocol shouldn't be tweaked so much and something stable needs to be pushed that will work indefinitely.

[BitThink]

Could I confirm whether my understanding of current issue is correct?

Malicious people can match any XCP sell orders with a tiny cost now. Those eaten orders have to wait until the matches expire. Currently the client cannot check the buyer's BTC balance because bitcoind does not provide this function.

My question is
1) bitcoind does not provide the function to check balance of an arbitrary address, but it can provide the user's own balance and unspent outputs. Could we put this checking in XCP client or it is already there?

A solution of the chicken-egg problem:

Could we set a maximum buy order for those without XCP escrow. For example, without XCP escrow, you can only buy 10XCP. Then with this 10XCP as escrow, you can buy 1000XCP. Something like this can help to avoid abuse with Large buy orders without escrow.

[MoneypakTrader.com]

Could I confirm whether my understanding of current issue is correct?
Malicious people can match any XCP sell orders with a tiny cost now. Those eaten orders have to wait until the matches expire.

The whole point of designing a protocol is to make "malicious people" irrelevant.
We are designing a system that is provably fair to the participants with a simple rule system enforced at the protocol level just like bitcoin does.
My suggestion 2 posts above allows more variables to allow orders to be customized and prevent the current problems.

[ddink7]

Tx0    Tx0_Address    Forward Asset       Tx1    Tx1_Address    Backward Asset    Remarks
3337   12b79vxJ3mv7b7mWJjApidEjcDntCHm6vT   0.02499951 BTC      3340   1Pcpxw6wJwXABhjCspe3CNf3gqSeh6eien   4.999902 XCP   Valid: awaiting BTC payment
3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   4802.70770001 BTC      3340   1Pcpxw6wJwXABhjCspe3CNf3gqSeh6eien   0.00009605 XCP   Valid: awaiting BTC payment
3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   4802.70770001 BTC      3338   1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485   0.00009605 XCP   Invalid: expired awaiting BTC payment
3325   1MNfSB1apnK45FacyFtFnxcopp6E6MV4nc   100 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   0.75 BTC   Valid: awaiting BTC payment
3318   1bLockjTFXuSENM8fGdfNUaWqiM4GPe7V   10 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   0.1 BTC   Valid: awaiting BTC payment
3314   18sinvadjvf7i5RXE4ns9sSH1iPrDeA1n9   1000 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   50 BTC   Valid: awaiting BTC payment
3308   1Jkx1LVfHgZWa8sHEN9BnNeYN7WfSwNmbf   1000 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   50 BTC   Valid: awaiting BTC payment
3306   14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC   5.53238637 XCP      3335   1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb   0.025 BTC   Valid: awaiting BTC payment
3306   14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC   1.54906818 XCP      3332   1LCrVCMAoKQ6QHEXLTXBWjhtgcF1cx2Wd6   0.007 BTC   Valid
3306   14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC   1.77036363 XCP      3328   1LCrVCMAoKQ6QHEXLTXBWjhtgcF1cx2Wd6   0.008 BTC   Valid: awaiting BTC payment
3306   14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC   8.85181818 XCP      3322   1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb   0.04 BTC   Invalid: expired awaiting BTC payment
3291   1Fz5idgemYfsszRMmaQNd2Anvm2JytAoU   72.72 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   0.5083 BTC   Valid: awaiting BTC payment
3280   18sinvadjvf7i5RXE4ns9sSH1iPrDeA1n9   100 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   2 BTC   Valid: awaiting BTC payment
3275   1PUis3DiofnDQjNS8HbuMABj8xYLiWWNWR   0.08 BTC      3319   1PBmybpJ9DXFCMqGdcMHd7FdbVYLajH5nU   20 XCP   Valid: awaiting BTC payment
3275   1PUis3DiofnDQjNS8HbuMABj8xYLiWWNWR   0.008 BTC      3295   1PBmybpJ9DXFCMqGdcMHd7FdbVYLajH5nU   2 XCP   Valid: awaiting BTC payment
3261   14SwRtFfpVrSFYBHzzq6PcvR8dCexWrHZC   50 XCP      3336   1LVDTWudnKaNHjamPzRSjyhEuXeqK6BH5V   0.25 BTC   Valid: awaiting BTC payment

Looks like someone went through and locked up all the sell orders on the DEX. Blockscan now shows only one sell order still standing.

[BitThink]

Yes, without escrow, anyone can eat all the sell orders without much cost. Therefore, I suggest
1) add proportional escrow fee in XCP for buy orders.
2) buy orders less than 10 XCP is free from escrow fee, so new users without XCP can still use the exchange.
All escrow fee goes to the seller if Btcpay is not sent in time. Otherwise, it goes back to the buyer.

[BitThink]

Yes, without escrow, anyone can eat all the sell orders without much cost. Therefore, I suggest
1) add proportional escrow fee in XCP for buy orders.
2) buy orders less than 10 XCP is free from escrow fee, so new users without XCP can still use the exchange.
All escrow fee goes to the seller if Btcpay is not sent in time. Otherwise, it goes back to the buyer.

I see one potential problem with the XCP escrow solution: what do we do about honest XCP buyers who want to place limit orders?

Unless I am mistaken, under this system if I place a resting limit order to buy XCP and turn off my computer, I run the risk of an XCP seller hitting my bid and collecting the escrowed XCP, since I am not around to execute a BTCPay.

This would really discourage XCP buyers from placing resting orders. Maybe this is not a bad thing though. Since XCP is not built for high-frequency trading there is nothing wrong with a 1-sided order book reflecting the asymmetry in XCP/BTC exchange. The XCP/BTC exchange would just resemble Ebay instead of the NYSE.  

I am not sure how the expire time of BTCPay is set. Is it always set by the XCP sellers? Could the buyer of limit order set it? If it is set by the buyer, then problem solved. How about who put the order first always determine the BTCPay expire time?

[MoneypakTrader.com]

Unless I am mistaken, under this system if I place a resting limit order to buy XCP and turn off my computer, I run the risk of an XCP seller hitting my bid and collecting the escrowed XCP, since I am not around to execute a BTCPay.

Doesn't my suggestion fix that?
Yes, BTC orders should be observant close to their expiration time since the BTC order time left is the "lock in" time and they risk losing the fee without fulfilment if they aren't ready to execute the BTCpay.
Alternatively, there could be an additional variable for BTC orders lock in time in addition to time left/time to live but then it would be difficult for the btc order wince they'd need to not leave their computer for longer than the lock in time while their order is open or they risk losing the fee without benefit.

My suggestion:
https://bitcointalk.org/index.php?topic=395761.msg4988118#msg4988118

[mtbitcoin]

After i put an order i get this:

Code:

raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'code': -22, 'message': 'TX rejected'}

https://counterparty.co/faqs/i-got-an-error-tx-rejected-code-22-what-is-that/

Hi PhantomPreak

I am also running into this issue. Managed to get it resolved once by sending coins in but consequently the same issue occurred.

I've sent you a pm with the debug information

[Matt Y]

Want to buy:

Counterparty technical lessons. I want to know more about the protocol and would like someone to teach me. Skype is preferred but I can also do Google Hangouts  Will pay in bitcoin. Please PM offers which include a short explanation of what you will be teaching me.

Thanks.