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

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?

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.

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://bitcointalksearch.org/topic/m.5053391 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)


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.

 

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

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

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

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

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.

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

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

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?

Any news on the GUI client?

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

An implementation based on porqupine's suggestion to terminate the troll order which failed to btcpay has been suggested in the dev board.

https://forums.counterparty.co/index.php/topic,69.15.html

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

Try a listunspent on bitcoind and see if your 0.001 is there.

if not, start bitcoind or bitcoin-qt with rescan, for me it solved the problem with newly imported addresses that showed a 0 balance while having enough BTC

No.


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.

PhantomPhreak,

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



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?

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

Good, when will you bump us by adding XCP to your platform? You know XCP is an amazing project, right?