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

Uh oh...

Tried to cancel an order and got this error;

lib.exceptions.BitcoindError: {'message': 'Private key for address 156FAUbf3Moo54qnUN9NRdNq7KP8KrMXBP is not known', 'code': -4}

That's where my XCP's are and a Bitcoin.

Is there something that counterpartyd could have done? All I've done with it the last few days is buy a little XCP through the DEX. I've done nothing fancy.

I'm the owner of Poloniex, and I'm trying to figure out how to get XCP on the exchange. I have some questions, as I'm not completely sure how it works yet...

1. Someone sent me 2 XCP for testing. I also got about 0.0001 BTC. I'm guessing this is because XCP is sent over BTC transactions, and you have to send at least a little BTC in order to send XCP. Correct?
2. I tried to send XCP to another address, but it tells me I need 0.0003 BTC. Why this amount? Where does it go? Is the amount adjustable?
3. I can see this being a bit of a problem, keeping track of both BTC and XCP. What if someone sends a deposit of 1000 XCP and then withdraws 1 XCP 1000 times? Would this not drain the BTC balance?

But the GUI release could be changed so it checks wallet balance before creating a sell BTC order, as well as an option to auto fill that order when a match has been found.

On another note, when a BTC sell order is insolvent for some filled part, I think it should wipe the entire order - this would at least prevent buy-wall trolling.

This would only be a check that is performed at the client that is creating the order.The Bitcoin protocol doesn't allow checking the balance of arbitrary addresses so other nodes won't be able to verify this.

If the check was added to the client:

1) It doesn't stop someone creating the order anyway with either a non-standard version of Counterparty.
2) You could just transfer the BTC away from your address after submitting the order. BTC can't be held in escrow.

By placing a fee_required amount on your trade, you are giving an incentive for the person to follow through with the BTCPAY. If they don't, they have just given a nice miner's fee, which helps BTC anyway.

Counterparty's timing resolution is restricted to a Bitcoin and therefore as a DEX, it offers a different service to trading on centralised exchanges. That's why there is a bounty out there for a centralised exchange. The time for order matching, execution, settlement and liquidity will be different to off blockchain transactions. The market price will reflect these factors between the exchanges.

The market is still in its infancy but I don't see a problem, even with these 'troll' trades that popped up on the DEX. The protocol is pretty clear that the fee_required is a disincentive to put up 'troll' trades and an incentive to follow through with settlement . We should just mentally sort where fee_required is given higher priority.

In some ways, I see Counterparty as a trustless inter-dealer broker which provides liquidity to centralised exchanges (or perhaps gateways) who are on sell side.

We of course debated what the default fee required should be, and indeed the decision is not once-and-for-all. Nevertheless you just criticized us for implementing new required fees, which we have not done, and hence my clarification.

Nice project.  Well done.

Whether you think the current implementation is effective is one thing (and on this matter we have been taking the community's discussions into consideration and will continue to do so), but this is quite different from claiming that we have implemented new required fees, which is false.

To be completely clear, we have implemented zero required fees. Users are, as always, free to choose the fees themselves.

The last (and first) I used CEF was in June 2013 and it was the version: cef_binary_1.1364.1123_macosx
So I can not really advise you on this point.
It is precisely the hard part, making a standalone build with counterpartyd and CEF embedded in. This is the part that will take me more time I think.

Please DON'T delay your dinner plans while you wait for that.
Actually, don't expect to have those funds ready for your vacation plans next week either.

But the reason I'm posting is just to reiterate the QUICK FIX to current problems (again):
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH  btc offers if the asset expiration time left is less than the btc offer expiration time left.

BAM, solved until the other suggestions can be implemented to further harden the DEX against more rigorous alpha testing.

Please explain again how *if* people decide to force BTC orders to burn more coins that will help (A) what problem be solved and (B) not cause more friction to trading? quotes are fine.
How will that not just make an overlapping trading range in the book as currently shows? that's no good, the first match should be free to allow clearing up the book as per our proposals: https://forums.counterparty.co/index.php/topic,71.0.html

MoneyPakTrader, you have written a very long response, but one statement you've repeatedly made should be cleared up:



If the "FEES REQUIRED FOR USING THE DEX" are the costs associated with multi-sig transactions, then you should know, as has been explained repeatedly, that these are not fees, and it is only in the absence of OP_RETURN that multi-sig is implemented; the new fee_required/fee_provided is set to a default of 1%, it is by no means required and it is grossly misleading to keep referring to these as required fees.

I disagree with your interpretation of how the match protocol works:
Order: sell 0.00001818 XCP at 0.0017 BTC/XCP in 8000 blocks, with a provided fee of 5e-05 BTC and a required fee of 0.0 BTC (f8ff1b5e75436cc61c20476684d431e5f3890ea1c080b9f683d7f287fa005975)
Order Match: 0.00000181 BTC for 0.0000181 XCP at 0.1000 BTC/XCP (6efab911ef0b392cced9a410f610380783356f3172b6ee724e9c5175e21e8a7df8ff1b5e75436cc 61c20476684d431e5f3890ea1c080b9f683d7f287fa005975)

Notice it didn't match the lower rates that are on the market? (0.0025, 0.004, etc. etc.)

There has been some disagreement between stakeholders and developers on the future of the counterparty protocol and distributed exchange system. This is currently helping investors who still want to get into XCP by buying at fairly low rates from stakeholders who are unsatisfied with the current direction (see my review thread for details on buying XCP for 0.005 BTC each, link in sig).
It has just now become more clear as to the cause of the disagreement.

The main DISAGREEMENT is on the NATURE OF THE CURRENT PROBLEM with the DEX system.
While we believe the current fees required to use the XCP network are excessive and inefficient - totalling ~$1 or 0.001 BTC for a single matched trade to complete with much of the expense being sent to unspendable locations (multi-sig is currently unspendable despite that rumor of spendability which was debunked in this thread). Our perspective is that MORE fees going to miners or being "burned" are NOT acceptable changes, while allowing asset orders to request and receive fees for the privilege of locking that order for a time they agree to is more fair and acceptable.

How it currently works:
1 A) People with XCP can place an offer to sell a specific amount of XCP at a specific XCP/BTC rate to last until a specific expiration. They may only cancel unmatched orders prior to the expiration. This costs about 30 cents (USD) currently whereas a direct XCP send costs about 20 cents.

1 B)People with bitcoins can place requests to buy XCP at a specific rate until a specific expiration. They may cancel or refuse to pay. This costs about 30 cents.

2 A) If there is overlap of the two above listings, those orders are matched regardless of order size (0.000001 XCP order may be matched with a 1 BTC order) and regardless of expiration time (XCP order expiring in 2 blocks may match with a BTC order expiring in 100 blocks). This creates an order match, (in this case perhaps for 0.00001 BTC for 0.0000005 XCP or 1 BTC for 200 XCP expiring in 2 blocks) matching happens regardless of whether the xcp/btc seller want to match a minimum quantity, maximum time to pay, etc.
For example, if a btc offer is placed around 6PM lasting for the next 25 hours (150 blocks) and wants to sell 5 btc for 1000 XCP and will come back the next day around 4PM to review orders and pay for those that match. They might be matched numerous times with short expiration XCP orders of (maybe 10 blocks or even 20 blocks, since they are not intending to view the matches until closer to their expiration time) over the next day but NONE of them show or might have very short expiration time when they are reviewing the matches. Further, they CAN'T specify minimum matches, so several dust matches are present which they must parse the database to view since the CLI doesn't show which match is for what trade. Frustrated at these failures of the protocol, they might abandon using the DEX around 7PM on that day and go to the thread in this forum to trade for XCP the same way every other alt-coin is traded if they don't abandon the idea of XCP altogether (due to the failure of XCP protocol to do it's intended purpose).

2 B) Assuming there are some XCP orders that matched with sufficient time for the BTC order to review them and pay, the BTC order involved in the match (requesting XCP or other asset) then has an option to send BTC (BTCpay command) to complete the match/s and receive XCP. NOTE: They will lose their btc for no benefit if the transaction occurs after the expiration of the match.

Based on how the protocol currently works, these MOST SIGNIFICANT CURRENT PROBLEMS are as follows:
1) EXCESSIVE FEES REQUIRED FOR USING THE DEX (whereas the devs are contemplating MORE fees).
2) LACK OF CUSTOMIZATION FOR ORDERS IN REGARDS TO TIME TO BTCPAY AND MINIMUM MATCH AMOUNTS.
Specifically: PEOPLE PLACING ORDERS INVOLVING BTC CANNOT SPECIFY:
A) The duration of time allowed for BTCpay.
B) Minimum match amounts.
3) Asset for BTC orders receive no compensation for order matches that do not BTCpay within the timeframe. Also, they receive no compensation difference for an order requiring payment in 5 blocks and no compensation for an option to buy their XCP in 1000 blocks expiration time.

A solutions to these problems is being worked out in this thread:
- https://forums.counterparty.co/index.php/topic,71.0.html
But since the dev's don't agree to the above problems, of course they won't implement solutions to them. . .

Solutions in short to the above defined problems are:
1) Don't force people to pay fees as default, let the market decide.
2) Allow customizing orders in regards to matching, particularly for matches after the first match to a btc order (see thread discussion) -
3) Allow XCP orders to get compensated for the expiration/payment timeframe they offer: This would be paid by the BTC seller for the privilege of multiple matches/options to buy. NOTE: due to already excessive fees and the potential for a highly clogged book from numerous fee amounts as we see now, the FIRST match should be included for the price of getting your BTC Sale request included in the blockchain. This will allow clearing of orders around the trading range for the cost of the transaction fees (already too high). The DEX system already is usable for small amounts, it's just numerous matches per BTC order that needs some option to prevent continuing the matching.

As long as the developers are misguided in identifying/solving the problems, we will be divesting of XCP.
Buy XCP at 0.005BTC each! link in sig

What the dev's have to say about the problems/fees being burned to miners:
I agree, you advocate burning more per transaction. . .

I'm calling BS on that, it's absolutely necessary for the BTC offer to know exactly when they are willing and able to pay, thus they MUST be able to set a time that they are able to pay for their order request and forcing all trades to be done in an arbitrary timeframe (10 blocks) would SUCK, what if I want to btcpay in 150 blocks (expiration of my btc offer) and there's an xcp offer on the books that is looking for the same?
Give us more options, don't take them away. . .

Great, now you want BTC orders to pay 1% in miner fees, wow, we're definitely not on the same page. . .

We are selling XCP at 0.005 BTC each until 30 BTC worth has been exchanged or 7 days, whichever comes sooner.

I hope dev's become enlightened on these problems and solutions we have described:
https://forums.counterparty.co/index.php/topic,71.0.html

fee_required is now a percentage of the total BTC worth of an asset that one is buying, and an address's fee_provided is deducted cumulatively. So, if there are five XCP-for-BTC orders for 1 BTC each, the fee_provided for a BTC-for-XCP order must be .05 BTC, not .01 in order to match all of them.

We are also still considering implementing the optional XPC escrow.

EDIT: the fee_required/fee_provided default to 1% and fee_required/fee_provided no longer needs to be an argument of an order. Users can however change the fee just be including fee_required/fee_provided as an argument of an order

EDIT 2: And there is a fixed 10 block expiry for btcpay as you noted.

No, it doesn't. If there are two bids at .005 and .006, then a new ask at .004 will match the bid at .005 first. (This is a weird and perhaps surprising, and I'm not sure that it shouldn't be changed. Prices should converge either way, however.)

Of course, even if that weren't the case, one could also trade with a higher fee_required (which is what everyone should have been doing all along).

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

Very interesting.  Can you point me in the direction of how to recover my multisig fees?

Thanks.

I didn't get refunded the full 5XCP.  it cost me 0.1 XCP to issue an asset.   bug?

I was afraid of it but it seems that is only way to get that done. Thanks IamNotSure

Really, I think the correct solution is that XCP shouldn't let someone place an order that exceeds their respective balance(s).