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

[JakeThePanda]

When is the GUI coming out?

[jl777]

Where do you get $1 in fees from?

Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

That's the total for both buyer and seller

[jl777]

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 was thinking GUI client could have an option to automatically issue BTCpay after it detected the otherside of transaction was completed. If it is automated and reliable, wouldn't this allow limit orders without any issues?

clearly, there needs to be some sort of temporary or permanent cost to prevent order spamming and making the orderbook useless. Doing this while reducing the cost per actual transaction as low as possible, well that is the difficulty. I have faith a solution will be found

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

The expire time of BTCpay is simply the lesser of the two expirations involved in the transaction.

Thanks. Then it is a little bit more difficult to punish the late buyers since the sellers can attack the buyers by setting a very short expire time.

One possible solution is maybe only the one who matches the existing orders needs to put some XCP in escrow. This could prevent someone eat up all sell orders without cost.

This solution, however, cannot prevent another kind of manipulation. Say current the lowest sell order is at 0.01. Then I can put a limit buy order 1M XCP @ 0.009999, so that I can ensure nobody can really sell to the bid walls.

It seems this kind of attack is arguably less harmful than a big buy orders to eat up all sell orders.

Let's think together to see whether there's better solution.

Moreover, even checking BTC bandwidth is doable, it cannot prevent the attack. Only put BTC in escrow can avoid this kind of attack completely.

Just aggregating some of the ideas above: here is the system I propose.

XCP seller options: --xcp-escrow-required-pct, --max-order-lock-time

XCP buyer options: --xcp-escrow-provided-pct, --min-expire-time

Reasoning for each:

The escrow is pretty straightforward. It prevents sweeping of the sellers' order book and also prevents the XCP buyer from getting a free option

Max-order-lock-time is different from expiration. It allows sellers to specify how long their order can be locked by a buyer before the escrow is forfeited.
Min-expire-time is the buyer analog to max-order-lock-time. It allows the buyer to specify the minimum time he has to do a btcpay.

If escrow-provided-pct < escrow-required-pct, the seller can ignore the buyer order.

If min-expire-time > min(max-order-lock-time, buyer-time-to-expiration, seller-time-to-expiration), the buyer's order won't be matched.

This solves:
1) sweeping of order book problem
2) XCP buyer doesn't get free option
3) XCP seller order won't get locked for a long period of time
4) XCP seller won't be able to hit buyer orders and set low expiration to collect escrowed XCP

This doesn't completely solve the problem of the buyer placing a large order wall slightly below the ask, but it does discourage it. A seller could ignore the attacker's order wall if he sets max-order-lock-time below min-expire-time, and if min-expire-time is set too low the seller can just match it and collect the escrowed XCP.

EDIT: I forgot to mention the XCP escrow system would completely replace fee_provided and fee_required. This solves MoneyPakTrader's issue of the fees being too high as well as creating demand for XCP. Instead of allowing attackers to set the price for fees required to trade, which negatively impacts honest traders, in this system honest traders only pay the minimum mining fee to trade.

Great idea.

[jl777]

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

From what I understand, one party is essentially issuing a call option while the other is getting a call option, for no cost. Using some approx of call option value (Black and Scholes), or some simplified model of value of option makes sense. That means if you lock in an option to buy at a fixed price for many blocks, it will cost more if you dont exercise it. Sure would discourage making orders that you dont intend to complete. Also if you decide you dont want to buy the BTC (since maybe it crashed), then you bail and are happy you only lost the value of call option

Eventually, there will be sellers who are selling with a range of durations so buyers can pick and choose which implicit call options to purchase.

James

[MoneypakTrader.com]

Where do you get $1 in fees from?
Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

That's the total for both buyer and seller

WRONG, I already Debunked that theory, so please use links to actual transactions unless your goal is to post unsupported contradictions of documented facts I previously disclosed (repeated again for your ease of review).

Link to the blockchain transaction for cost of recent XCP transactions:
XCP offered:
https://blockchain.info/tx/b844cf1b76237b48bb156c14ad9145c073ec812ab6388a8d33a2d296cbafc83d
EXTRA FEES COST: 0.0003172 BTC ~$0.3
BTC offered:
https://blockchain.info/tx/5ab38cd0b172d3d93e5f8d5cde3f3222ec45818e8bf9d4c3550c30be7844c12b
EXTRA FEES COST: 0.0003172 BTC ~$0.3
BTCpay:
https://blockchain.info/tx/f0cb991676f41fb3e71bdf568ee298e677f97a70b046d557d2674f52cef41419
EXTRA FEES COST: 0.0004258 BTC ~$0.4
total fees for BTC/XCP DEX trade ~$1

Notice how BTCpay ALONE costs 0.0004258 Bitcoins?

Granted, you MIGHT be able to spend those lost multisig coins *at some point in the future if someone ever bothers to develop a method to do so*, but the current facts/rules of this world require it to be classified as an expense.
You could pretty it up calling it a "forced escrow" (to an account that can't be accessed. . .), but it still operates equivalent to a "fee".

[MoneypakTrader.com]

From what I understand, one party is essentially issuing a call option while the other is getting a call option, for no cost. Using some approx of call option value (Black and Scholes), or some simplified model of value of option makes sense. That means if you lock in an option to buy at a fixed price for many blocks, it will cost more if you dont exercise it. Sure would discourage making orders that you dont intend to complete. Also if you decide you dont want to buy the BTC (since maybe it crashed), then you bail and are happy you only lost the value of call option

Eventually, there will be sellers who are selling with a range of durations so buyers can pick and choose which implicit call options to purchase.

Yes, the current system allows for options for the remaining time of the xcp order at the cost of a btc/xcp transaction. XCP sell order placements should know there is a possibility their option will be bought with only the BTC network transaction fees (plus multisig fees as that flaw persists).
My proposal allows some degree of customization while continuing the basic premise of a stock book (due to no option fee required beyond the transaction fees for the first match of each BTC order).
I advocate against a pure option fee since that would encourage excessive options orders being placed and make for an ugly order book.
Instead, with the first match free method I propose (below in bold) people know there is a possibility their option will be free and therefore won't rely on the option fee as guaranteed and correspondingly the order book will be cleaner and look more like the stock offering book we want.

With my proposal, Honest buyers can look at the order book and pick an XCP order that has the volume they want and trade in one transaction using the method I propose (using minimum xcp match amount variable), NO fees required aside from the already outrageous XCP protocol fees that are slapped on them that I want removed.

The combination of improvements I suggest allows the book clogging to be minimized (first order match fee is ignored since BTC order placement requires getting a block into the bitcoin blockchain which is a sufficient hurdle to allow at least one order match).

We don't want to burden honest XCP buyers who just want to buy 200-500 XCP without clearing numerous orders with costly escrows requiring 10 different BTCpays (or sacrificing all those escrow/fees we hope to implement). That's why the minimum amount option for matching your btc order I propose ((4) below) must be allowed as a variable (to ameliorate the excessive XCP protocol fees required for BTCpay). Please read my proposal and understand how it all comes together to help everyone involved.

The fact is that the market currently uses an option style system with no additional fee per extra match, allowing the order book to be cleared for a single fee that is to none of the parties benefit. Escrow doesn't compensate the XCP seller for the lockin period provided (if the option is exercised in this period) thus forcing a distortion in pricing since the BTC order has no reason to pay immediately if they intend to complete the purchase. Why not wait for the remainder of the lock time just in case the offer becomes unattractive?
Setting prices/Paying for the options beyond the first ones (if the xcp seller chooses to charge a fee) allows more accurate pricing of the orders to price the lock time while compensating the BTC order for their time/effort in placing the order and describing the minimum XCP order matches they will btcpay for.

My proposal will encourage shorter lock times and more active trading for people that actually want to exchange currencies. Further it will allow a benefit to XCP holders who trade more effectively while still allowing BTC trades without first having XCP.

I agree the current fee system should be removed, if transactions are included in a block, fees are irrelevant and wasteful. The obligation is on the BTCpay-er to ensure they get their transaction included in a block (i.e. pay 0.0001 fee). All other transactions should be frictionless with virtually ZERO fees.

Regarding fixing some of the current problems I'd suggest:
XCP/BTC orders can designate these new [optional] variables/fees:
1) [Optional] BTCpay lockin time in blocks as a variable for XCP orders:
****only BTC orders providing less than or equal to this time left are matchable.***
2) [Optional] BTC order lockin Fee per match(in XCP) (Ignored for first order match) allowed to be set by XCP orders (required fee) and BTC orders (maximum fee per match or match is ignored).
3) [Optional] Lockin Fees (XCP) paid by BTC orders to cover matches beyond the first. (with maximum lockin fee per match specified by BTC order in (2) above or no maximum if not set).

Secondary XCP order matches (beyond first match) earn XCP from BTC orders (using (3) above) in exchange for giving the btc order the privilege of lock time received to do the BTCpay. Only btc orders designating a lockin fee ((2) above) more than or equal to the lockin fee required by the XCP orders ((2) above) are matchable IF the remaining lockin fees are sufficient to pay it and BTC order time to expiration is less than or equal to the lockin period specified ((1) above).

4) [optional] Minimum match amount (in XCP/asset) as an option for BTC orders (to prevent BTCpay fee problems for small amounts). Since each match requires btcpay, it only makes sense to let btc orders set a minimum they are willing to follow through and btcpay for.

I.E. NO XCP required by a BTC order 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.

These changes should be incorporated so that older clients/orders will NOT match with orders that include the new variables to minimize the potential problems.

Flat payment for the lock time is more fair to the XCP order allowing them to customize the lock fee (larger for more lock time presumably).
The fees paid for the lock time should be immediately spendable by the XCP order giving the lock time, it could be a long time or short time as agreeable by the orders allowing a sort of options trading by default.
XCP buyers should be watching their order close to the expiration and they will either BTCpay or cancel orders to avoid paying the lockin fees for not enough lock time during the last few blocks. They should be able to cancel the unmatched order remainder while the matched orders will either be BTCpaid for or expire naturally (they paid for the lockin time, so no buthurt as the current situation allows).

The first order match to a btc order MUST ignore the lock fee in order to prevent clogging the order book at or below the trading range using high lock fees. This first no-fee match method will increase market liquidity.
This will allow clearing the first XCP order (above a certain liquidity level using the minimum option I described), but the fee paid to include a transaction in the blockchain is sufficient to justify this *AND* this will add an element of strategy to the options trading to encourage more sophisticated traders onto the platform.

The BTC order MUST be allowed to skip small orders (per my proposal (4) above) to avoid inefficient trades unless the BTC order wants to disregard this variable and either BTCpay for such inefficient trades or lose the lock fees required to match the trades they won't pay for.

The remaining problems such as the excessive cost for XCP transactions should be addressed when possible.

Also, to prevent LONG initial load times (currently several hours to sync and will only grow longer), an initial DB should be added to the repository each month after agreed to be legit by a sufficient number of community members. This will be necessary in another month to prevent week long sync time for slower computers.

Can someone please link to the most current description of how the asset creation/fees work?

Improvement 5) Orders seeking to receive BTC should be allowed to direct match for the cost of the lockin fee specified according to (2) above, allowing a btc order to claim the order/lockin time by directly reserving it, this would facilitate directly buying the option/order they want regardless of position on the market list. This would allow direct trading which is a desirable benefit to the platform.

[jl777]

Where do you get $1 in fees from?
Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC

Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC.

That's the total for both buyer and seller

WRONG, I already Debunked that theory, so please use links to actual transactions unless your goal is to post unsupported contradictions of documented facts I previously disclosed (repeated again for your ease of review).

Link to the blockchain transaction for cost of recent XCP transactions:
XCP offered:
https://blockchain.info/tx/b844cf1b76237b48bb156c14ad9145c073ec812ab6388a8d33a2d296cbafc83d
EXTRA FEES COST: 0.0003172 BTC ~$0.3
BTC offered:
https://blockchain.info/tx/5ab38cd0b172d3d93e5f8d5cde3f3222ec45818e8bf9d4c3550c30be7844c12b
EXTRA FEES COST: 0.0003172 BTC ~$0.3
BTCpay:
https://blockchain.info/tx/f0cb991676f41fb3e71bdf568ee298e677f97a70b046d557d2674f52cef41419
EXTRA FEES COST: 0.0004258 BTC ~$0.4
total fees for BTC/XCP DEX trade ~$1

Notice how BTCpay ALONE costs 0.0004258 Bitcoins?

Granted, you MIGHT be able to spend those lost multisig coins *at some point in the future if someone ever bothers to develop a method to do so*, but the current facts/rules of this world require it to be classified as an expense.
You could pretty it up calling it a "forced escrow" (to an account that can't be accessed. . .), but it still operates equivalent to a "fee".

Clearly, we need a solution that doesnt require sending all this BTC in an unrecoverable way. I had thought there is a way to extract the BTC used for multisig. Why not make the GUI automate this process of recovering it?

A key part of XCP vs MSC is that XCP has lower fees, so this is a critical issue as far as I am concerned

[520Bit]

Looks like I might have finally caught up with the blockchain. I tried to check on it but the process had crashed with this error.

Status: RESTART
Block: 284193
Send: 100.0 of asset XCP from 1FueYJfpS7Q92qHGGrbr5d4r5qn4Lz56To to 1KKPcuXvYkEqwjFRUWuDUFcLk3YQgXfVbQ (b5f95848...8fd4d9f3)
Traceback (most recent call last):
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/counterpartyd.py", line 682, in <module>
    blocks.follow(db)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 534, in follow
    parse_block(db, block_index)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/blocks.py", line 64, in parse_block
    cancel.parse(db, tx, message)
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/cancel.py", line 61, in parse
    util.credit(db, tx['source'], order['give_asset'], order['give_remaining'])
  File "/opt3/git/counterpartyd_build/dist/counterpartyd/lib/util.py", line 257, in credit
    assert asset != 'BTC' # Never BTC.
AssertionError

Any ideas here?

Reparse counterpartyd and try again.

Actually, I believe the problem is that he's running an old version. 520bit, tell us what counterpartyd --version returns.

counterpartyd -V
counterpartyd v0.2

Did a git pull and I've restarted it. It's started parsing an older block so when it gets up to 284193, I'll have an answer.

My counterpartyd version is:

Code:

c:\counterpartyd_build>counterpartyd --version

c:\counterpartyd_build>echo off
counterpartyd v0.3

So you have to update to the latest version.

[supersuber]

Why

Code:

TypeError: wif_to_tuple_of_secret_exponent_compressed() got an unexpected keywor
d argument 'is_test'

[/quote]

You're running an old version of pycoin.
[/quote]

Easiest way to fix this, if you're using the build system, is to just rerun setup.py from a checkout of the newest code.
[/quote]

It works!
Thank you!

[xnova]

Counterparty now has its own IRC server
irc.counterparty.co

More info here: https://counterparty.co/faqs/do-you-guys-have-an-irc-channel-how-do-i-connect/

The server has full NickServ, ChanServ functionality. Let me know if you guys have any issues with it.

[xnova]

NOTE: The Counterpartyd windows installer has been updated to the newest source from master.

If you are using the installer instead of source (which is NOT RECOMMENDED at this time), PLEASE UPGRADE to the latest version.

Updated installer link: https://github.com/xnova/counterpartyd_binaries/raw/master/counterpartyd-v0.3-amd64_install.exe
Updated installer sha1 hash: https://github.com/xnova/counterpartyd_binaries/raw/master/counterpartyd-v0.3-amd64_install.sha1

The installer docs have also been updated.

(This message also posted a https://forums.counterparty.co/index.php/topic,67.0.html)

[kdrop22]

I have the counterpartyd running fine but now am lost.
When a bid is matched, for example I place a request to buy XCP with and it matches an order to sell XCP.
Is the transaction then completed automatically by counterpartyd or do I need to complete the transaction manually?

You would need to do a 'btcsend' to complete the transaction.

[supersuber]

issuance --source=YOUR_ADDRESS --asset=ASSETNAME --quantity=QUANTITY divisible

Code:

    if asset[0] == 'A': raise exceptions.AssetNameError('starts with ‘A’')
lib.exceptions.AssetNameError: starts with ‘A’

 

[Wit22]

First of all, thanks to the counterparty team for doing such a great job so far.

Now a question. I want to install counterpartyd
I'm struggling to get bitcoind to work.
My bitcoin-qt has synced fully but when I run bitcoind, it asked to reindex, so I ran the command; now I have a blank open windows terminal with a flashing underscore. Will bitcoind confirm when it's finished reindexing? I have no idea what sort of progress it has made (if any)...

Also. When is the GUI version of counterpartyd due out and will it still require a functioning bitcoind installion and associated python librbaries?

(I'm not a programmer lol.)

[DaFockBro]

dayyyyuuuuummmmmm fat sell wall

http://blockscan.com/order_book.aspx

[520Bit]

First of all, thanks to the counterparty team for doing such a great job so far.

Now a question. I want to install counterpartyd
I'm struggling to get bitcoind to work.
My bitcoin-qt has synced fully but when I run bitcoind, it asked to reindex, so I ran the command; now I have a blank open windows terminal with a flashing underscore. Will bitcoind confirm when it's finished reindexing? I have no idea what sort of progress it has made (if any)...

Also. When is the GUI version of counterpartyd due out and will it still require a functioning bitcoind installion and associated python librbaries?

(I'm not a programmer lol.)

You can also run Bitcoin-QT to do the reindex. It works as well. You can install counterpartyd after Bitcoin-QT synced all the blocks to the latest one.

[Wit22]

Are you saying that bitcoind doesn't have to be 'synced' or functioning?
This is my first time installing bitcoind /bitcoin-qt

[520Bit]

Are you saying that bitcoind doesn't have to be 'synced' or functioning?
This is my first time installing bitcoind /bitcoin-qt

I am runing Bitcoin-QT which works well. I don't know much about how to use bitcoind.

[520Bit]

issuance --source=YOUR_ADDRESS --asset=ASSETNAME --quantity=QUANTITY divisible

Code:

   if asset[0] == 'A': raise exceptions.AssetNameError('starts with ‘A’')
lib.exceptions.AssetNameError: starts with ‘A’

 

What is your version of countepartyd? You need to update to the latest version v0.3.