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

[JahPowerBit]

I made a pull request here: https://github.com/PhantomPhreak/counterpartyd/pull/34

Thank in advance to the developers for time to check this code.

Great work!

Any way for us the mere users, to check it out while XCP devs are reviewing the code?
Will replacing the counterpartyd in dist folder, and running the setup.py and run.py will be enough?

Best way it's to take this commit: https://github.com/JahPowerBit/counterpartyd/commit/0f4c4d531ba667b8c4880c3a17a217f74ed1426d
and restart counterpartyd with --activate-gui

[winner2all]

Have a question. Why don't you implement automatic settlement ? is that even possible ?

[SyRenity]

Best way it's to take this commit: https://github.com/JahPowerBit/counterpartyd/commit/0f4c4d531ba667b8c4880c3a17a217f74ed1426d
and restart counterpartyd with --activate-gui

Seems some deps are missing?

Traceback (most recent call last):
  File "counterpartyd.py", line 13, in <module>
    import requests
ImportError: No module named requests

[prabhu.str1]

why the trading volume is so low?

[halfcab123]

The trading volume is low simply because while burning BTC to get XCP was extremely simple ... Sending XCP via counterpartyd can be a daunting task for an average user. I'm definitely a self proclaimed advanced user and the installation instructions for counterpatyd are simply awful IMHO. We need that GUI and a very good explanation of how to use it.

EDIT: buying after the burn is not easy either.

[Patel]

I'm definitely a self proclaimed advanced user

Cannot wait to see that GUI working on my PC. I think I'd rather use a web based version of course, cause this whole blockchain reindex is insane. I tried 3 times already

Its really simple actually.

Set bitcoin.conf properly
Reindex
Download counterparty prereq's
Build counterparty database

On a virtual machine, reindexing takes about 6 hours, and rebuilding takes about 3.

But its a one time deal, after that your set.

[prabhu.str1]

I'm definitely a self proclaimed advanced user

Cannot wait to see that GUI working on my PC. I think I'd rather use a web based version of course, cause this whole blockchain reindex is insane. I tried 3 times already

Its really simple actually.

Set bitcoin.conf properly
Reindex
Download counterparty prereq's
Build counterparty database

On a virtual machine, reindexing takes about 6 hours, and rebuilding takes about 3.

But its a one time deal, after that your set.

Patel bhai, not everyone out here are geeks. Buying and selling should be very easier like fill the order, click payment and receive coins.

[Patel]

Patel bhai, not everyone out here are geeks. Buying and selling should be very easier like fill the order, click payment and receive coins.

yes, I agree. It will be soon.

[halfcab123]

Hey so Patel can you explain just a little more what's the bitcoin.conf settings supposed to be.

I understand the reindex I tried it twice took over two days so I cut it off

Bitcoind -reindex

I'm assuming I can just use the counterparty
Exe installer and that's all I need ?

And then rebuild counterpartyd database ?
How ? Ha.

If you could just explain that I think it might click for me

[Patel]

Hey so Patel can you explain just a little more what's the bitcoin.conf settings supposed to be.

I understand the reindex I tried it twice took over two days so I cut it off

Bitcoind -reindex

I'm assuming I can just use the counterparty
Exe installer and that's all I need ?

And then rebuild counterpartyd database ?
How ? Ha.

If you could just explain that I think it might click for me

Bitcoin.conf located in C:\Users\Owner\AppData\Roaming\Bitcoin should be set to:

rpcuser=rpc
rpcpassword=rpcpw1234
server=1
daemon=1
txindex=1

Save the file.

Click start, type cmd, press enter.

type: cd C:\Program Files (x86)\Bitcoin

press enter

type: bitcoin.exe -reindex

press enter

And wait like 6 hours for it to finish.

[PhantomPhreak]

Does the transaction malleability issue affect Counterparty?

http://www.reddit.com/r/Bitcoin/comments/1xmnt3/bitstamp_bitcoin_withdrawal_processing_suspended/

Is this scenario possible?

Attacker creates a sell order. It has TxID=1xx. Renegade node duplicates this transaction by modifying TxID=2xx. There are now 2 identical sell orders.

Both get matched by buyers.

Buyers send BTC only to find out later that the transaction was duplicated.

I don't think so, because counterpartyd doesn't recognise unconfirmed transactions.

[jimhsu]

Does the transaction malleability issue affect Counterparty?

http://www.reddit.com/r/Bitcoin/comments/1xmnt3/bitstamp_bitcoin_withdrawal_processing_suspended/

Is this scenario possible?

Attacker creates a sell order. It has TxID=1xx. Renegade node duplicates this transaction by modifying TxID=2xx. There are now 2 identical sell orders.

Both get matched by buyers.

Buyers send BTC only to find out later that the transaction was duplicated.

I don't think so, because counterpartyd doesn't recognise unconfirmed transactions.

Crossposted from the XCP forums. I'm no bitcoin dev, so I'm not 100% sure, but:

---

Well, I'll chime in. Because malleability only affects the txid and not pubkeys (which we use for multisig) nor OP-RETURN (which hasn't even been implemented yet), I don't see how that affectx XCP. You might say it could affect BTCpay, but then again no unconfirmed transactions appear in the DEX anyways, so I don't see that as an issue.

[gacrux]

The thing I don't like about XCP escrow is the added complexity to what should really be a very simple function.

Agree. Having more than one mechanism to penalise BTCpay defaulters adds unnecessary complexity. Plus it damages order fungibility (the idea that any order can be matched against any other without the user having to jump through hoops.)

On the otherhand I don't see how to make large BTC Sell / XCP Buy orders reliable (troll prohibitive) but not fee inefficient without the escrow mechanism.

This is exactly what I'm attempting to address here:
https://forums.counterparty.co/index.php/topic,69.msg340.html#msg340

* the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order, providing the required fee as any combination of XCP and BTC he prefers
* the automatic refund of XCP fees upon BTCpay settlement

If implemented, this would result in:
* the vast majority of fees being paid in XCP (any sensible client would do this automatically where ever possible,) massively improving fee efficiency.
* serious troll deterrence, as matching any appreciably large sum of XCP and failing to BTCpay would cost you heavily (but it'd be free if you utilised the XCP fee and did BTCpay.)
* retained simplicity of the fee mechanism. XCP sellers just specify a single fee. XCP buyers can match any order on the book, paying the fee with whatever they have available. Software could automatically default optimal values very easily so that the user need never even think about fees.

[Anotheranonlol]

good proposal gacrux. agree with enforcement on client level rather than hardcoded protocol

[porqupine]

The thing I don't like about XCP escrow is the added complexity to what should really be a very simple function.

Agree. Having more than one mechanism to penalise BTCpay defaulters adds unnecessary complexity. Plus it damages order fungibility (the idea that any order can be matched against any other without the user having to jump through hoops.)

On the otherhand I don't see how to make large BTC Sell / XCP Buy orders reliable (troll prohibitive) but not fee inefficient without the escrow mechanism.

This is exactly what I'm attempting to address here:
https://forums.counterparty.co/index.php/topic,69.msg340.html#msg340

* the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order, providing the required fee as any combination of XCP and BTC he prefers
* the automatic refund of XCP fees upon BTCpay settlement

If implemented, this would result in:
* the vast majority of fees being paid in XCP (any sensible client would do this automatically where ever possible,) massively improving fee efficiency.
* serious troll deterrence, as matching any appreciably large sum of XCP and failing to BTCpay would cost you heavily (but it'd be free if you utilised the XCP fee and did BTCpay.)
* retained simplicity of the fee mechanism. XCP sellers just specify a single fee. XCP buyers can match any order on the book, paying the fee with whatever they have available. Software could automatically default optimal values very easily so that the user need never even think about fees.

I was thinking something similar - but a few questions.

* the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order, providing the required fee as any combination of XCP and BTC he prefers

Why do you think the fee should be specified as a number and not a percentage?  It already seems somewhat annoying that one has to think of how to set Give/Get Asset to try and get a certain proportion; plus this the pick a number would lead to greater incongruity in order matching (as opposed to everyone using say .5%).

I was going to suggest the protocol checking if the Sell BTC Address has a positive XCP balance > the required fee, and automatically escrowing the fee in XCP, unless they do not have enough, otherwise BTC. And then a minor prompt for the GUI to inform users i.e.
<To deter DEX trolling Orders to sell Counterparty Assets (Including XCP) for BTC have an optional required Fee (that is generally set to {default percentage}, this fee maybe paid in BTC or temporarily escrowed in XCP and returned to upon a successful completion or expiration of the order; it is strongly recommended that a user looking to sell a large amount of BTC, first acquire a positive XCP balance to avoid incurring high unreturnable fees>

One more thing - if such a solution were to be implemented - the percentage of XCP returned / debited from the escrow based on insolvency should be matched order size based; for example if a user is matched for a 1000 XCP buy, and has .5% - 5 XCP in escrow, and he is insolvent, those 5XCP are burned/used as miners fees, but if he has an order for 1000 XCP matched and is matched for 10 XCP which he fails to resolve, it should only debit him for the 10/1000 proportion *5XCP in escrow and the rest should be returned on expiration. Otherwise it will be possible for unresolved dust or near-dust sized transactions to eat away at his escrow balance.

[ginko-B]

A few years ago I did a study of the history of the stock exchanges. My emphasis was on the shift that occurred in the 1980s from member-based systems to fully electronic systems provided as a market-based service by a third party such as NASDAQ.  Although it was not my focus, I vaguely recall from my research reading about the problem of "backing away" as a long-standing and difficult problem faced by the stock exchange developers. Just as the name implies, "backing away" is the problem of a buyer placing an order and then not settling it within the settlement period, which is the same problem being discussed now amongst ourselves in the context of Counterparty.

While purpose of this post is not to offer a solution, I thought it was worthwhile to flag the fact that this "backing away" problem is not new in the world of exchanges and that it has a name and a history. While offhand I do not recall solutions that were ultimately tried and / or adopted, I shall try to dig thru my archives later today to see if I can uncover any insights from the early systems such as Instinet, Archipelago, etc

Ok, I just did a few quick searches, see page 32 and 42 of this report:
http://www.sec.gov/litigation/investreport/nd21a-report.txt

Looks like the term "firm order" is the antonym of "backing away" and is another keyword for community members to search in an effort to find historical solutions to this problem.

See: http://www.investopedia.com/terms/b/backingaway.asp

Definition of 'Backing Away'

Failure by a market maker in a security to honor the quoted bid and ask prices for a minimum quantity. Backing away constitutes a serious violation of industry regulations. NASD Regulation Inc uses an automated market surveillance system to enable the resolution of backing-away complaints in real time.
   
Investopedia explains 'Backing Away'

Backing away constitutes a breach of SEC Rule 11Ac1-1 or the firm quote rule, which requires a market maker to execute an order presented to it at a price at least as favorable as its published quotation, up to its published quotation size. A potential backing-away complaint has to be brought to the attention of the Market Regulation Department within five minutes of the alleged offense. Otherwise, it may be difficult for department staff to obtain a contemporaneous trade execution from the market maker.

NASD Regulation does not pursue immediate disciplinary action for an individual backing-away complaint where a contemporaneous trade execution from the market maker is obtained or offered. However, department staff keep a record of such transgressions, and repeated non-compliance with the firm quote rule could result in disciplinary action.

[JahPowerBit]

Following the excellent kanzure, xnova and phantomphreak suggestions, I separated GUI into two repositories:

The Webserver serving GUI: https://github.com/JahPowerBit/counterpartyws
The GUI: https://github.com/JahPowerBit/counterpartygui

Dependencies are exactly the same as counterpartyd, it should be easy to install if counterpartyd is already installed.

Code:

counterpartyws [-h] [--data-dir DATA_DIR]
               [--counterpartyd-dir COUNTERPARTYD_DIR]
               [--counterpartygui-dir COUNTERPARTYGUI_DIR]
               [--gui-host GUI_HOST] [--gui-port GUI_PORT]
               [--gui-user GUI_USER] [--gui-password GUI_PASSWORD]

Web server for Counterparty GUI

optional arguments:
  -h, --help            show this help message and exit
  --data-dir DATA_DIR   the directory in which to keep the config file
  --counterpartyd-dir COUNTERPARTYD_DIR
                        the directory in which counterpartyd is installed
  --counterpartygui-dir COUNTERPARTYGUI_DIR
                        the directory in which counterpartygui is installed
  --gui-host GUI_HOST   the host to provide the counterpartyd GUI
  --gui-port GUI_PORT   port on which to provide the counterpartyd GUI
  --gui-user GUI_USER   required username to use the counterpartyd GUI (via
                        HTTP basic auth)
  --gui-password GUI_PASSWORD
                        required password (for gui-user) to use the
                        counterpartyd GUI (via HTTP basic auth)

[cityglut]

A few years ago I did a study of the history of the stock exchanges. My emphasis was on the shift that occurred in the 1980s from member-based systems to fully electronic systems provided as a market-based service by a third party such as NASDAQ.  Although it was not my focus, I vaguely recall from my research reading about the problem of "backing away" as a long-standing and difficult problem faced by the stock exchange developers. Just as the name implies, "backing away" is the problem of a buyer placing an order and then not settling it within the settlement period, which is the same problem being discussed now amongst ourselves in the context of Counterparty.

While purpose of this post is not to offer a solution, I thought it was worthwhile to flag the fact that this "backing away" problem is not new in the world of exchanges and that it has a name and a history. While offhand I do not recall solutions that were ultimately tried and / or adopted, I shall try to dig thru my archives later today to see if I can uncover any insights from the early systems such as Instinet, Archipelago, etc

Ok, I just did a few quick searches, see page 32 and 42 of this report:
http://www.sec.gov/litigation/investreport/nd21a-report.txt

Looks like the term "firm order" is the antonym of "backing away" and is another keyword for community members to search in an effort to find historical solutions to this problem.

See: http://www.investopedia.com/terms/b/backingaway.asp

Definition of 'Backing Away'

Failure by a market maker in a security to honor the quoted bid and ask prices for a minimum quantity. Backing away constitutes a serious violation of industry regulations. NASD Regulation Inc uses an automated market surveillance system to enable the resolution of backing-away complaints in real time.
   
Investopedia explains 'Backing Away'

Backing away constitutes a breach of SEC Rule 11Ac1-1 or the firm quote rule, which requires a market maker to execute an order presented to it at a price at least as favorable as its published quotation, up to its published quotation size. A potential backing-away complaint has to be brought to the attention of the Market Regulation Department within five minutes of the alleged offense. Otherwise, it may be difficult for department staff to obtain a contemporaneous trade execution from the market maker.

NASD Regulation does not pursue immediate disciplinary action for an individual backing-away complaint where a contemporaneous trade execution from the market maker is obtained or offered. However, department staff keep a record of such transgressions, and repeated non-compliance with the firm quote rule could result in disciplinary action.

This definition of "Backing Away" is inapplicable to Counterparty's distributed exchange: The distributed exchange consists of peer-to-peer buying and selling assets, there is no market maker.

[jl777]

A few years ago I did a study of the history of the stock exchanges. My emphasis was on the shift that occurred in the 1980s from member-based systems to fully electronic systems provided as a market-based service by a third party such as NASDAQ.  Although it was not my focus, I vaguely recall from my research reading about the problem of "backing away" as a long-standing and difficult problem faced by the stock exchange developers. Just as the name implies, "backing away" is the problem of a buyer placing an order and then not settling it within the settlement period, which is the same problem being discussed now amongst ourselves in the context of Counterparty.

While purpose of this post is not to offer a solution, I thought it was worthwhile to flag the fact that this "backing away" problem is not new in the world of exchanges and that it has a name and a history. While offhand I do not recall solutions that were ultimately tried and / or adopted, I shall try to dig thru my archives later today to see if I can uncover any insights from the early systems such as Instinet, Archipelago, etc

Ok, I just did a few quick searches, see page 32 and 42 of this report:
http://www.sec.gov/litigation/investreport/nd21a-report.txt

Looks like the term "firm order" is the antonym of "backing away" and is another keyword for community members to search in an effort to find historical solutions to this problem.

See: http://www.investopedia.com/terms/b/backingaway.asp

Definition of 'Backing Away'

Failure by a market maker in a security to honor the quoted bid and ask prices for a minimum quantity. Backing away constitutes a serious violation of industry regulations. NASD Regulation Inc uses an automated market surveillance system to enable the resolution of backing-away complaints in real time.
   
Investopedia explains 'Backing Away'

Backing away constitutes a breach of SEC Rule 11Ac1-1 or the firm quote rule, which requires a market maker to execute an order presented to it at a price at least as favorable as its published quotation, up to its published quotation size. A potential backing-away complaint has to be brought to the attention of the Market Regulation Department within five minutes of the alleged offense. Otherwise, it may be difficult for department staff to obtain a contemporaneous trade execution from the market maker.

NASD Regulation does not pursue immediate disciplinary action for an individual backing-away complaint where a contemporaneous trade execution from the market maker is obtained or offered. However, department staff keep a record of such transgressions, and repeated non-compliance with the firm quote rule could result in disciplinary action.

This definition of "Backing Away" is inapplicable to Counterparty's distributed exchange: The distributed exchange consists of peer-to-peer buying and selling assets, there is no market maker.

While there is no market maker, it sure has the same effect. Somebody says they will trade at a price and then they back away. I think we need some solution that doesnt increase the trading friction, but also doesnt let one side of the trade get such a large advantage. It is basically giving a free call option to one side, isn't it?

[led_lcd]

I received a reply from btc-e about my inquiry regarding Counterparty.

Code:

Hello

no planed

As Counterparty gets more traction I hope they will reconsider.