Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 539. (Read 1276928 times)

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.

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.

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).

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.

Your new order has been matched.

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.

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.

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....?

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

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

+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.

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.

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.

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.).

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...

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

It could at most be a warning, because there's no reason that someone should not send to himself the bitcoins after he secures the order match he wants.

Maybe someone else can think of something. . .
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.


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

+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.

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. That doesn't fix "order hogging", but it's a sanity check.