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

[mtbitcoin]

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  

I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.006% of the value of your order (ie. very small.)

Example:
If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.)

This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?

(Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.)

ok. I saw the post replies on the counterparty forums and it does look like the figure is now a percentage.. I understand that its still alpha, but it still catches you off guard when it works one way and then the other the next day ;-)

Cheers

[1715459137]

1715459137

[1715459137]

1715459137

[1715459137]

1715459137

[TheMightyX]

Any news on the GUI client?

[porqupine]

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  

I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.006% of the value of your order (ie. very small.)

Example:
If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.)

This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?

(Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.)

ok. I saw the post replies on the counterparty forums and it does look like the figure is now a percentage.. I understand that its still alpha, but it still catches you off guard when it works one way and then the other the next day ;-)

Cheers

It looks like it's a percentage now - so troll buy walls should be quite expensive at this point - albeit this will make large BTC Orders expensive as well.

What's with the talk of a default fee? Is it simply the fee set in the Order examples in the readme?

[OOO]

After some help please.  I have the below error when trying to send XCP

c:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 486, i
n <module>
    util.database_check(db)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 83, in data
base_check
    block_index = last_block(db)['block_index']
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 190, in las
t_block
    cursor.execute('''SELECT * FROM blocks WHERE block_index = (SELECT MAX(block
_index) from blocks)''')
  File "c:\apsw\src\cursor.c", line 990, in APSWCursor_execute.sqlite3_prepare
  File "c:\apsw\src\statementcache.c", line 386, in sqlite3_prepare
apsw.BusyError: BusyError: database is locked

Any suggestions?

[520Bit]

I've also noticed a nuisance bug - Insufficient bitcoins at address, when making an order, 0.0003172 BTC is needed, but there is 0.001 in the wallet.

counterpartyd balances xxxxxxxxxxxxxxxxxx    reports 0.0 BTC.
Shouldn't it be more precise in reporting and calculating balance?

You can use counterpartyd wallet to check all of your assets in individual address - XCP, BTC and other assets.

[PhantomPhreak]

Hi PhantomPhreak

I am not sure if this is an issue/bug/change with the required-fee option running the latest develop branch

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  and subsequently matched the "troll" order ??  same thing for the next test order http://blockscan.com/tx.aspx?q=3694. Used a 0.001 required fee, but when parsed it was 0.00007 BTC ?

Something looks messed up again... sigh...

Note to self: Need to quit running develop branch

There was a change in the command-line interface. Now the fees are a fraction (.01 = 1%) of the BTC to be transacted. See this discussion.

EDIT: It seems that this question was answered already.

[PhantomPhreak]

PhantomPhreak,

can a matched order in 'awaiting payment' status be canceled without waiting for payment to be released?

No.

I've also noticed a nuisance bug - Insufficient bitcoins at address, when making an order, 0.0003172 BTC is needed, but there is 0.001 in the wallet.

counterpartyd balances xxxxxxxxxxxxxxxxxx    reports 0.0 BTC.
Shouldn't it be more precise in reporting and calculating balance?

It isn't a lack of precision, counterpartyd doesn't keep track of BTC balances. You have to keep track of the amount of BTC at each address in your wallet, yourself, as Bitcoin-QT creates new addresses and sends BTC to them without telling you. If you PM me the address you are checking the balance of, I can look it up on blockchain.info.

counterpartyd does report BTC balances correctly now (in fact using Blockchain.info). Mostly likely the problem was unconfirmed coins.

[PhantomPhreak]

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  

I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.006% of the value of your order (ie. very small.)

Example:
If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.)

This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?

(Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.)

ok. I saw the post replies on the counterparty forums and it does look like the figure is now a percentage.. I understand that its still alpha, but it still catches you off guard when it works one way and then the other the next day ;-)

Cheers

It looks like it's a percentage now - so troll buy walls should be quite expensive at this point - albeit this will make large BTC Orders expensive as well.

What's with the talk of a default fee? Is it simply the fee set in the Order examples in the readme?

If you leave out the CLI arguments, then order fee required and provided default to 1% of the BTC to be transacted.

[porqupine]

Don't know if this is a new bug?
Pretty table in Windows CMD is cutting of Price at 4 decimal points when running counterpartyd Market

[SkillRoad]

Let's say Alice is selling BTC for XCP with a 5 block expiration on her order and Sally is selling XCP for BTC with a 3 block expiration on her order, and their orders get matched. Upon the matching, the protocol debits the XCP from Sally's account, and then Alice has 3 blocks to send Sally her BTC using the btc-pay command. If Alice fails to send Sally BTC within 3 blocks, the deal is cancelled and Sally's account gets re-credited with the XCP.

Thanks for this answer (and subsequent clarifications), its much more clearer now.

Just one thing - the assets shares selling will work in same way? Meaning the asset holder will post a sale offer, and whoever matches it, will have to transfer BTC within set amount of blocks time?

Yes. Since Counterparty cannot debit BTC from an address, all trades involving BTC require an extra step (namely, <tt>btcpay</tt>) to be completed. All transactions involving any asset other than BTC, however, require no second step to be completed.

[gacrux]

What the dev's have to say about the problems/fees being burned to miners:

Please take a look at my suggestion [...]
I'm advocating much higher fees [...] in proportion to the size of the order matched.

I agree, you advocate burning more per transaction. . .

I must correct you on two points:

1. I'm not a counterparty dev.
I can't take credit for a single line of code in counterpartyd. I actually only heard about counterparty in the last week I'm just some random guy with an interest in trustless protocol design. But then, this is the internet right? It doesn't matter who you are, only what you have to say. Good ideas should stand on their own, regardless of who advances them.

2. I don't advocate burning more per transation.
If you were going to selectively quote me from https://bitcointalk.org/index.php?topic=395761.msg5053391#msg5053391 then you could at least select this bit: "XCP fees are fully refunded upon BTCpay". It was even in bold. How did you not see it?

(to be clear, I want to see the bare minimum BTC burned per transaction; I don't anticipate my proposal would see anybody ever "burning" much more than the minimum miner fee)

The BTCpay mechanism isn't intended to be an "option" for people to have the luxuary of locking in a price and deciding later whether to exercise it. It has worked that way so far only by an unfortunate accident in the protocol design - one that can be corrected.

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

You're aware you're not buying XCP from the developers or something, right? The DEX is an open market where anybody can buy or sell.  "More options" can be given to BTC sellers only at the expense of BTC buyers.

A BTC buyer (ie. "XCP offer") will very obviously always prefer prompt settlement. What possible reason could anyone have to want their BTC buy order to be matched and locked for 150 blocks while they wait for BTCpay (which may never come.) During that 150 blocks the market price may fluctuate. The BTC buyer has no mechanism to back out if the price fluctuates against him. But the BTC seller does have such a mechanism, unfortunately - he can just default on the BTCpay. This gives him a massive advantage, and makes the market essentially unusable.

 

[porqupine]

The thing I don't like about XCP escrow is the added complexity to what should really be a very simple function. 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.

[mtbitcoin]

Hi PhantomPhreak


Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.

Anything changes related to assets?

[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

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

[PhantomPhreak]

Hi PhantomPhreak


Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.

Anything changes related to assets?

Can you give me an example?

[mtbitcoin]

Hi PhantomPhreak


Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.

Anything changes related to assets?

Can you give me an example?

there were close to 180 ++ assets before the upgrading. Blockscan is one of the assets

[JahPowerBit]

I talked with a friend (much better than me) yesterday and he convinced me that:

1) there was no need to use CFE, and the vast majority of users had no problem using web wallet as BCI (or the upcoming "Counterwallet"). The paranoid could always use CFE standalone as a "browser safe". So there is no reason that this is not the same for a GUI. And this will leave me much time to improve the GUI.

2) That the easiest way for the user to use the GUI, is to integrate it into counterpartyd. In this way, the user does not need to install multiple software and GUI can be automatically accessed when counterpartyd works.

So despite my huge backlog in my real job (much less funny), I took the time to changed my code to use CherryPy instead of Bottle and it is fully integrated in counterpartyd.
I tried to respect the style of code:

https://github.com/JahPowerBit/counterpartyd

Here are the new arguments of counterpartyd:

--activate-gui : run GUI web server
--gui-host : the host to provide the counterpartyd GUI
--gui-port : port on which to provide the counterpartyd GUI
--gui-user : required username to use the counterpartyd GUI (via HTTP basic auth)
--gui-password : required password (for gui-user) to use the counterpartyd GUI (via HTTP basic auth)

And the corresponding keys in config file:

gui-host
gui-port
gui-user
gui-password

Default values are:

gui-host = rpc-host
gui-port = 8080
gui-user = rpc-user
gui-password = rpc-password

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.

[SyRenity]

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?

[PhantomPhreak]

Hi PhantomPhreak


Running the latest develop branch and I noticed that the asset list has been reduced. A lot of previously valid assets are now invalid.

Anything changes related to assets?

Can you give me an example?

there were close to 180 ++ assets before the upgrading. Blockscan is one of the assets

I found the bug and will fix it post-haste. Thanks.

I just wrote a pre-commit hook that will check credits and debits of new and old databases, so regressions like this won't happen again.